这篇文章给大家介绍hanganalyze的示例分析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
ORACLE 的HANGANALYZE是在数据库出现了异常状况，因为hang住而产生严重的性能问题，而通过HANGANALYZE 功能产生的日志可以帮助我们快速的定位是否是2个或者多个进程死锁了，有多少进程收到影响。 从而帮助我们诊断出数据库的问题。
关于HANGANALYZE：
HANGANALYZE uses internal kernel calls to determine if a session is waiting for a resource, and reports the relationships between blockers and waiters。oracle在8i的时候推出了HANGANALYZE(8.1.6),并在9i中扩展了该功能，添加了集群范围内的HANGANALYZE分析。这种分析是针对内核级别的资源争用，由于oracle无法检测并回滚其中一个操作，需要人为干预，而当大量的该操作发生后，数据库就有可能被完全HANG住。
应用场景：
1、数据库被完全HANG住无法打开，sqlplus 回话无法连接操作，此时就需要我们使用hanganalyze分析并找到最根源占用回话进程杀掉。
2、某对象被无数回话占用，尝试kill掉所有的锁后回话仍然存在，只能找到根源会话并杀掉该会话。
使用方法：
3 Syntax Examples:
ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level <level>'; —–（回话级别的hanganalyze）
ORADEBUG hanganalyze <level> —–实例级别的hanganalyze
（集群范围内的）
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze <level>
The <level> sets the amount of additional information that will be extracted from the processes found by HANGANALYZE (ERROSTACK dump) based on the "STATE" of the node.
The levels are defined as follows:
10 Dump all processes (IGN state)
5 Level 4 + Dump all processes involved in wait chains (NLEAF state) –Level4+Dump出所有在等待链中的进程（状态为NLEAF）
4 Level 3 + Dump leaf nodes (blockers) in wait chains (LEAF,LEAF_NW,IGN_DMP state) —Level3+Dump出在等待链里面的blockers(状态为LEAF/LEAF_NW/IGN_DMP)
3 Level 2 + Dump only processes thought to be in a hang (IN_HANG state) —（LEVEL2+IN_HANG状态的进程）
1-2 Only HANGANALYZE output, no process dump at all
IN_HANG：如果Session处于这种状态，表示Session遇到deadlock或者处于hung状态。
LEAF/LEAF_NW：LEAF/LEAF_NW：这些Session通常是“blocker”或者是等待某些资源的“slow” node，通过字段“predecessor” 可以很容易标识出这些node。
NLEAF：通常可以看作这些会话是被阻塞的资源。意味着这些Session在等待某些Session的资源。通过字段“adjlist”可以很容易的定义该进程的blocker。
IGN/IGN_DMP：这类会话通常被认为是空闲会话，除非其adjlist列里存在node。如果是非空闲会话则说明其adjlist里的node正在等待其他node释放资源。
SINGLE_NODE/SINGLE_NODE_NW：近似于空闲会话
我们需要关注的重点也就是处于IN_HANG状态的回话，而且，一般oracleOracle建议不要采用3级以上的跟踪，如果Level过大的话会产生大量的跟踪文件并影响系统的I/O性能
测试（本机测试环境单机10g环境）：
我们先使数据库产生一些enq锁：
SQL> select s.sid,s.serial#,s.username,s.logon_time from v$session s,v$locked_object l where s.sid=l.session_id;
SID SERIAL# USERNAME LOGON_TIM
———- ———- —————————— ———
152 20 TEST 07-DEC-11
158 38 TEST 07-DEC-11
140 27 TEST 07-DEC-11
142 18 TEST 07-DEC-11
SQL> select addr,sid,type,lmode,request,block from v$lock where sid in (152,142,158,140)
ADDR SID TY LMODE REQUEST BLOCK
——– ———- — ———- ———- ———-
2CFB9BC0 140 TX 0 4 0
2CFB9C1C 158 TX 0 4 0
2CFB9C78 142 TX 0 4 0
2B8F3A90 152 TM 3 0 0
2B8F3B3C 140 TM 3 0 0
2B8F3BE8 158 TM 3 0 0
2B8F3C94 142 TM 3 0 0
2B92BC60 152 TX 6 0 1
2B954A00 158 TX 6 0 0
2B954F1C 140 TX 6 0 0
2B966C68 142 TX 6 0 0
接下来做一个hanganalyze分析：
SQL> oradebug hanganalyze 3;
Hang Analysis in /oracle/app/admin/orcl/udump/orcl_ora_8153.trc
打开跟踪文件查看：
该跟踪文件分成3部分：
基本信息：
ORACLE_HOME = /oracle/app/product/10.2.0/db_1
System name: Linux
Node name: product
Release: 2.6.9-78.ELsmp
Version: #1 SMP Wed Jul 9 15:39:47 EDT 2008
Machine: i686
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 8153, image: oracle@product (TNS V1-V3)
第二部分：HANG ANALYSIS:
Open chains found:
Chain 1 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/152/20/0x2ce2022c/7362/SQL*Net message from client>
— <0/140/27/0x2ce1da40/7991/enq: TX – row lock contention>
Other chains found:
Chain 2 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/136/1/0x2ce1f6c4/7235/Streams AQ: waiting for time man>
Chain 3 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/137/1/0x2ce1f110/7233/Streams AQ: qmn slave idle wait>
Chain 4 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/142/18/0x2ce1dff4/8052/enq: TX – row lock contention>
Chain 5 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/144/301/0x2ce1b254/8157/jobq slave wait>
Chain 6 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/146/334/0x2ce1d48c/8153/No Wait>
Chain 7 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/150/1/0x2ce1c924/7219/Streams AQ: qmn coordinator idle>
Chain 8 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/158/38/0x2ce1c370/7528/enq: TX – row lock contention>
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> :
首先了解下每个字段相关意思：
sid是 Session ID
sess_srno是serial#
proc_ptr是Process Pointer 理解为进程指针地址
ospid 是OS Process ID
cnode是Node Id，Oracle9i才用
wait 是表示是等待的参数
在此处我们可以清楚的看到，回话140被hang住，而回话152 是阻塞者，也就是阻塞的源头，这也正符合从enq锁中查出的信息。
第三部分：state of node
State of nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor):
[135]/0/136/1/0x2cef0e14/7235/SINGLE_NODE/1/2//none
[136]/0/137/1/0x2cef20c8/7233/SINGLE_NODE/3/4//none
[139]/0/140/27/0x2cef58e4/7991/NLEAF/5/8/[151]/none
[140]/0/141/15/0x2cef6b98/8199/SINGLE_NODE_NW/9/10//none
[141]/0/142/18/0x2cef7e4c/8052/NLEAF/11/12/[151]/none
[143]/0/144/357/0x2cefa3b4/8201/SINGLE_NODE/13/14//none
[149]/0/150/1/0x2cf013ec/7219/SINGLE_NODE/15/16//none
[151]/0/152/20/0x2cf03954/7362/LEAF/6/7//139
[154]/0/155/1/0x2cf07170/7215/IGN/17/18//none
[155]/0/156/1/0x2cf08424/7213/IGN/19/20//none
[157]/0/158/38/0x2cf0a98c/7528/NLEAF/21/22/[151]/none
[158]/0/159/26/0x2cf0bc40/7986/IGN/23/24//none
[159]/0/160/1/0x2cf0cef4/7203/IGN/25/26//none
[160]/0/161/1/0x2cf0e1a8/7205/IGN/27/28//none
[161]/0/162/1/0x2cf0f45c/7201/IGN/29/30//none
[162]/0/163/1/0x2cf10710/7197/IGN/31/32//none
[163]/0/164/1/0x2cf119c4/7199/IGN/33/34//none
[164]/0/165/1/0x2cf12c78/7195/IGN/35/36//none
[165]/0/166/1/0x2cf13f2c/7193/IGN/37/38//none
[166]/0/167/1/0x2cf151e0/7191/IGN/39/40//none
[167]/0/168/1/0x2cf16494/7189/IGN/41/42//none
[168]/0/169/1/0x2cf17748/7187/IGN/43/44//none
[169]/0/170/1/0x2cf189fc/7185/IGN/45/46//none
这部分也是用来描述个回话进程所处的状态。
Nodenum是hanganalyze
自己为了记录这些会话而定制的编号，从0开始排起。
State 是node的状态
Adjlist是临近的node(通常代表一个blocker node)
Predecessor是Predecessor node ,通常代表一个 waiter node
关于hanganalyze的示例分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
