hanganalyze 3 分析总结
一种是会话级别的：
ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level ';
一种是实例级别:
ORADEBUG hanganalyze
一种是集群范围的：
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze
先解释下各个level的含义：
1-2:只有hanganalyze输出，不dump任何进程
3：Level2+Dump出在IN_HANG状态的进程 【最简单，最容易判断问题】
4：Level3+Dump出在等待链里面的blockers(状态为LEAF/LEAF_NW/IGN_DMP)
5：Level4+Dump出所有在等待链中的进程（状态为NLEAF）
hanganalyze报告会分作许多片断，会话片断信息总是由一个header详尽描述被提取的的会话信息。Oracle8i和9i的信息略有不同：
sid是 Session ID
sess_srno是serial#
proc_ptr是Process Pointer
ospid 是OS Process ID
cnode是Node Id，Oracle9i才用
Nodenum是hanganalyze
自己为了记录这些会话而定制的编号，从0开始排起。
State 是node的状态
Adjlist是临近的node(通常代表一个blocker node)
Predecessor是Predecessor node ,通常代表一个 waiter node
接着解释一下比较重要的一些node state:
IN_HANG：这表示该node处于死锁状态，通常还有其他node（blocker）也处于该状态
LEAF/LEAF_NW：该node通常是blocker。通过条目的”predecessor”列可以判断这个node是否是blocker。
LEAF说明该NODE没有等待其他资源，而
LEAF_NW则可能是没有等待其他资源或者是在使用CPU.
如下的实例说明了node16阻塞了node19的资源：
nodenum]/cnode/sid/sess_srno/session/
ospid/state/start/finish/[adjlist]/predecessor
[16]/0/17/154/0x24617be0/26800/LEAF/29/30//19
[19]/0/20/13/0x24619830/26791/NLEAF/33/34/[16]/186
NLEAF：通常可以看作这些会话是被阻塞的资源。发生这种情况一般说明
数据库发生性能问题而不是数据库hang
IGN/IGN_DMP：这类会话通常被认为是空闲会话，除非其adjlist列里存在node。
如果是非空闲会话则说明其adjlist里的node正在等待其他node释放资源。
SINGLE_NODE/SINGLE_NODE_NW：近似于空闲会话
实战hanganalyze:
测试案例
C:\Users\Administrator>SQLPLUS / AS SYSDBA
SQL*Plus: Release 10.2.0.4.0 - Production on Sat May 28 15:30:03 2011
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
数据库已经hang 了登录失败下面来做个 systemdump 吧 看看是什么原因
C:\Users\Administrator>sqlplus -prelim '/ as sysdba'
SQL*Plus: Release 10.2.0.4.0 - Production on Sat May 28 15:31:13 2011
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Enter password:
SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit;
Statement processed.
SQL> oradebug dump systemstate 10
Statement processed.
SQL> oradebug tracefile_name
c:\oracle\product\10.2.0\admin\systex\udump\systex_ora_4636.trc
SQL> oradebug hanganalyze 3
Hang Analysis in c:\oracle\product\10.2.0\admin\systex\udump\systex_ora_6824.trc
先来看看 hanganalyze 的trace
Chain 1 : :
<0/139/105/0x18263170/2932/latch: shared pool> //// 看来是 139 阻塞了一下的会话了.
-- <0/164/1/0x1825f030/4592/latch: library cache>
Other chains found:
Chain 2 : :
<0/135/1/0x18269350/3956/Streams AQ: waiting for time man>
Chain 3 : :
<0/142/2/0x18266260/3816/Streams AQ: qmn slave idle wait>
Chain 4 : :
<0/146/90/0x182641c0/5944/latch: shared pool>
Chain 5 : :
<0/151/9/0x18265a38/6060/Streams AQ: qmn coordinator idle>
Chain 6 : :
<0/159/1138/0x18262948/6100/latch: shared pool>
Chain 7 : :
<0/161/1/0x182608a8/4856/latch: shared pool>
Chain 8 : :
<0/162/1/0x18260080/5904/latch: shared pool>
OK ,我们在 systemdump 里面搜索 2932
O/S info: user: SYSTEM, term: WILLSON-LI, ospid: 2932
OSD pid info: Windows threadid: 2932, image: ORACLE.EXE (SHAD)
Dump of memory from 0x000007FF18249EC0 to 0x000007FF1824A0C8
7FF18249EC0 00000006 00000000 17615728 000007FF [........(Wa.....]
7FF18249ED0 00000010 000313A7 183ADF60 000007FF [........`.:.....]
7FF18249EE0 00000003 000313A7 1798B0E8 000007FF [................]
7FF18249EF0 0000000B 000313A7 1836A1C0 000007FF [..........6.....]
7FF18249F00 00000004 0003129B 16835088 000007FF [.........P......]
7FF18249F10 00000007 000313A7 16836020 000007FF [........ `......]
7FF18249F20 00000007 000313A7 00000000 00000000 [................]
7FF18249F30 00000000 00000000 00000000 00000000 [................]
Repeat 24 times
7FF1824A0C0 00000000 00000000 [........]
(FOB) flags=2 fib=000007FF169BB290 incno=0 pending i/o cnt=0
fname=C:\ORACLE\PRODUCT\10.2.0\ORADATA\SYSTEX\CONTROL04.CTL
fno=0 lblksz=16384 fsiz=430
(FOB) flags=2 fib=000007FF169BB630 incno=0 pending i/o cnt=0
fname=C:\ORACLE |