Author: mac

有同学问是否可以用SQL语句直接查询告警日志的内容，即创建一张包含Alert.log内容的表或视图。 实际上之前已经有人这样做了(http://t.cn/SwGvq9)，只需要运行一个存储过程即可达到目的， 这里我对原有的语句做了一些改良， 直接执行PL/SQL块即可无需创建存储过程了，而且现在支持RAC了。   –drop table alert_log_view; –drop directory bdump; declare path_bdump varchar2(4000); name_alert varchar2(4000); ins_name varchar2(200); begin select value into path_bdump from sys.v_$parameter where name = ‘background_dump_dest’; select ‘alert_’ || value || ‘.log’ into name_alert from sys.v_$parameter where name = ‘instance_name’; select value into ins_name from sys.v_$parameter where name = ‘instance_number’; if ins_name…

有同学问Oracle 的package、Procedure、Function 这些PL/SQL程序单元分别存放在哪里？ 针对这个问题我们可以通过对create package、Procedure、Function 做trace分析来了解其细节，如:   SQL> select * from v$version; BANNER —————————————————————- Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – 64bi PL/SQL Release 10.2.0.1.0 – Production CORE    10.2.0.1.0      Production TNS for Linux: Version 10.2.0.1.0 – Production NLSRTL Version 10.2.0.1.0 – Production SQL> select * from global_name; GLOBAL_NAME ———————————————– www.askmac.cn & www.askmac.cn SQL> oradebug…

今天打开邮箱发现一封来自Independent Oracle User Group(IOUG)的 技术期刊<Oracle Technology Tips & Best Practices>，看了下封皮是第六期， 68页的小册子包括不少专题文章，准备晚上看。      

dbms_stats收集统计信息包的默认粒度为AUTO，对于AUTO没有非常明确的解释，一般认为它会收集分区的统计信息，但不包含子分区subpartition。对于这种说明我们加以核实：   SQL> select * from v$version; BANNER —————————————————————- Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bi PL/SQL Release 10.2.0.5.0 – Production CORE 10.2.0.5.0 Production TNS for Linux: Version 10.2.0.5.0 – Production NLSRTL Version 10.2.0.5.0 – Production SQL> select dbms_stats.get_param(‘cascade’) from dual; select dbms_stats.get_param(‘degree’) from dual; DBMS_STATS.GET_PARAM(‘CASCADE’) ——————————————————————————– DBMS_STATS.AUTO_CASCADE SQL> DBMS_STATS.GET_PARAM(‘DEGREE’) ——————————————————————————– NULL SQL>…

常见的分区表DDL如 split partition、add partition都会生成没有统计信息的表分区table partition，长期以来我对dbms_stats.lock_table_stats有一个错误的认识，即对于没有统计信息的分区，LOCK_STATS并不生效。 实际测试发现锁表统计信息对没有统计信息的分区同样有效，结果就是自动收集统计信息的作业不会收集这些实际没有统计信息的分区：   CREATE TABLE MacleanV nologging partition by range(object_id) (partition p1 values less than (99999) tablespace users, partition p2 values less than (maxvalue) tablespace users) as select * from dba_objects where rownum=0; SQL> insert into macleanV select * from dba_objects; 51029 rows created. SQL> commit; Commit complete. SQL> exec dbms_stats.gather_table_stats(‘SYS’,’MACLEANV’);…

11g新特性RMAN语法recover corruption list是为了简化数据坏块的修复，在11g中recover corruption块时不需要一一指定数据文件名字了，只要是在v$database_block_corruption视图中记录的坏块，只要使用了 corruption list语法，都会试图修复。   下面我们使用recover .. clear命令手动造成个别数据块坏块，之后使用 recover corruption list;修复：   RMAN> recover datafile 8 block 100 clear; Starting recover at 25-NOV-09 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=16 device type=DISK Finished recover at 25-NOV-09 RMAN> RMAN> validate datafile 8 block 100; Starting validate at 25-NOV-09 using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of datafile…

ORA-01578错误是Oracle中常见的物理坏块讹误(Corruption)错误，从10g以后在拥有完整备份和归档日志的情况下可以通过blockrecover/recover命令在线恢复该坏块，前提是数据块所在磁道在物理上仍可用。 以下是一个在没有充分备份情况下的ORA-01578错误的解决，前提是能够容忍坏块所在数据的丢失： 如果不能自行解决该问题，那么也可以联系MACLEAN专业数据库修复团队。   SQL> exec DBMS_STATS.GATHER_DATABASE_STATS; BEGIN DBMS_STATS.GATHER_DATABASE_STATS; END; * ERROR at line 1: ORA-01578: ORACLE data block corrupted (file # 4, block # 870212) ORA-01110: data file 4: ‘/s01/oradata/G10R25/datafile/o1_mf_users_7ch7d4nx_.dbf’ ORA-06512: at “SYS.DBMS_STATS”, line 15188 ORA-06512: at “SYS.DBMS_STATS”, line 15530 ORA-06512: at “SYS.DBMS_STATS”, line 15674 ORA-06512: at “SYS.DBMS_STATS”, line 15638 ORA-06512: at line 1…

一般情况下 稳定系统中突然出现的Enq:US 是因为并发事务数突然变多导致的，而实际引发并发事务数变多的可能是某些DML语句遇到了性能问题，导致事务处理速度变慢，或者是commit变慢所致。 针对上述问题，enq:US本身只是性能问题所导致的“果”，而不是原因，一般解决了上述问题，enq:US的这个果也就消失了。 对于那些短期内无法解决根本原因的环境，可以通过如下手段调优Undo Segment的管理来减少US争用。   ALTER SYSTEM SET “_rollback_segment_count”= 2000; –副作用是可能的数据库startup变慢 ALTER SYSTEM SET “_undo_autotune” = false; –最好重建undo tabelspace ALTER SYSTEM SET “_highthreshold_undoretention”=3600; –1小时     有多少Undo enqueue resource? 每一个rollback segment对应一个 US enqueue 资源   有多少US enqueue lock？ 当进程要求访问一个rollback segment RBS时对应一个US enqueue lock   谁使用该enqueue lock? 所有的前台进程，SMON和PMON   何时使用该US enqueue ? US,Undo Segment…

IV,Library Cache Invalidation Enqueue Lock   相关资源： 在Library cache中当前被缓存的有效或已存数据库对象，例如 表TABLE、视图View、存储过程procedure、package、package body、trigger、index、cluster、synonym；或cursor (SQL or PL/SQL)、pipe、等多种多样的库缓存资源类型   相关用户: 所有的可能的Oracle前台或后台进程   锁的原因: LCK后台进程及其他进程视图在集群中的所有实例上使相关的library cache object失效(invalidate)   何时使用该队列锁？ 当一个有效或现存的数据库对象被加载到library cache库缓存中，LCK RAC后台进程将针对该resource要求一个S共享模式的IV队列锁。直到该对象或者失效或者不再存在或者被age out出library cache，该IV lock才会被释放。 该IV lock存在的目的是在所有实例间使library cache中缓存的对象失效。 若一个进程想要使library cache object失效则首先请求以X mode锁定该对象资源，这将导致所有实例中均使该缓存对象失效以响应BAST并释放他们在该对象上的IV lock，之后发起invalidate进程将释放该X lock。   ID1、ID2的组合： Object Number， Timestamp   Lock Value Block: Not Used. Init.ora Parameters: None.   Scope:…

对存有LOB大对象的表的并发插入、更新引起的LOB Segment High Water Mark是常见的LOb并发争用； 特别是在ASSM(Auto Segment Space Management)的表空间上这种LOB的HWM可能比MSSM(Manual Segment Space Management)更为严重，其原因是在MSSM下LOB的HWM bump一次会获取128个chunk， 而在ASSM下默认只获取必要的chunk(default 1) (This is worse in ASSM than MSSM because ASSM only gets the amount of space requested while MSSM gets 128 chunks at a time.)。   针对该LOB HWM高水位争用问题，常见的一种解决方法是为LOB segment预分配空间，因为预分配了空间所以出现高水位争用的机会少了，则 enq HW – contention争用出现的概率也随之降低，为LOB  allocate extent的语法如下：   ALTER TABLE <lob_table> MODIFY LOB (<column_name>)…