教你熟练使用hanganalyze来分析数据库

1.为什么要使用hanganalyze?

Oracle数据库“真的”hang住了，可以理解为数据库内部发生死锁。因为普通的DML死锁，oracle服务器会自动监测他们的依赖关系，并回滚其中一个操作，终止这种相互等待的局面。而当这种死锁发生在争夺内核级别的资源（比如说是pins或latches）时，Oracle并不能自动的监测并处理这种死锁。

其实很多时候数据库并没有hang住，而只是由于数据库的性能问题，处理的时间比较长而已。

Hanganalyze工具使用内核调用检测会话在等待什么资源，报告出占有者和等待者的相互关系。另外，它还会将一些比较”interesting”的进程状态dump出来，这个取决于我们使用hanganalyze的分析级别。

使用hanganalyze

hanganalyze工具从oracle8i第二版开始提供，到9i增强了诊断RAC环境下的“集群范围”的信息，这意味着它将会报告出整个集群下的所有会话的信息。

目前有三种使用hanganalyze的方法:

一种是会话级别的：


ALTER SESSION SET EVENTS 'immediate
trace name HANGANALYZE level <level>';

一种是实例级别:


ORADEBUG hanganalyze <level>

一种是集群范围的：


ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze <level>

先解释下各个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的信息略有不同：


Oracle 8.x chain header:
<sid/sess_srno/proc_ptr/ospid/wait_event>
Oracle9i chain header:
<cnode/sid/sess_srno/proc_ptr/ospidd/wait_event> :

先把在trace file中看到的一些缩略语解释一下：


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:


生成跟踪文件
SQL> oradebug setmypid
已处理的语句
SQL> oradebug hanganalyze 3

查看跟踪文件


==============
HANG ANALYSIS:
==============
Open chains found:
Chain 1 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<5/1/0x843630f8/2531/No Wait>
Chain 2 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<12/1/0x84364e48/2521/instance state change>

有一个等待事件，操作系统进程是2521，经检查，是smon，占用了一个CPU的98％的资源


Other chains found:
Extra information that will be dumped at higher levels:
[level 4] : 2 node dumps -- [LEAF] [LEAF_NW] [IGN_DMP]
[level 10] : 6 node dumps -- [IGN]
State of nodes
([nodenum]/sid/sess_srno/session/state/
start/finish/[adjlist]/predecessor):
[0]/1/1/0x84405460/IGN/1/2//none
[1]/2/1/0x84405de0/IGN/3/4//none
[2]/3/1/0x84406760/IGN/5/6//none
[3]/4/1/0x844070e0/IGN/7/8//none
[4]/5/1/0x84407a60/LEAF_NW/9/10//none
[5]/6/1/0x844083e0/IGN/11/12//none
[10]/11/1/0x8440b360/IGN/13/14//none
[11]/12/1/0x8440bce0/LEAF/15/16//none
Dumping System_State and
Fixed_SGA in process with ospid 2521
Dumping Process information
for process with ospid 2531
Dumping Process information
for process with ospid 2521
*** 2004-12-09 00:07:49.680
====================
END OF HANG ANALYSIS
====================

我们看到，并没有发生死锁，Smon进程忙，说明在正确释放资源。