使用v$wait_chains来诊断ORACLE数据库HANG

                                              使用v$wait_chains来诊断ORACLE数据库HANG
   从oracle 11GR1后引入了一个新的后台进程,进程名为diag0。官方文档定义该进程是一个诊断进程，收来收集诊息的.
该进程主要用是用来收集hang的信息的，单实例每隔三秒,RAC中每隔10秒，收集数据到shared pool中的一个cache中.
SQL> select * from v$sgastat where name like '%ksdhng: %';

POOL         NAME                            BYTES
------------ -------------------------- ----------
shared pool  ksdhng: el blking cache         97600
shared pool  ksdhng: blkers cache            19520
shared pool  ksdhng: cache ctx                 144
shared pool  ksdhng: cbufs                      64
shared pool  ksdhng: blking cache             9760
shared pool  ksdhng: cbuf                    32768

6 rows selected.

主要的参数:
_diag_proc_enabled控制是否允许diag
_diag_proc_max_time_ms控制收集的时间

ksdhng相关的参数主要通过v$wait_chain来表现。如我手动模拟一下tx:row -lock contention的例子

session 1:
SQL> delete from t1;
 
70982 rows deleted

session 2:
SQL> delete from t1;   --一直处于执行状态

session 3:

SQL> select chain_signature,wait_event_text,osid,blocker_osid from v$wait_chains;
 
CHAIN_SIGNATURE                                                                  WAIT_EVENT_TEXT                                                  OSID                      BLOCKER_OSID
-------------------------------------------------------------------------------- -------------------------------------- - -------------------------
'SQL*Net message from client'<='enq: TX - row lock contention'                   enq: TX - row lock contention                                    27578                     27509
'SQL*Net message from client'<='enq: TX - row lock contention'                   SQL*Net message from client                                      27509                    
 
SQL>

可以查找出当前的会话

对于在整个库被某个会话阻止的时候，找到最先引起的block会话特别有用。低层的视图是x$ksdhng_chains.对于整个库被HANG紧急况下，sqlplus 可能也无法正常连接到实例了.

可以通过-prelim的方式连接，然后通过直接访问内存的方式来查看这个视图,然后杀掉首要会话.