hanganalyze的示例分析
这篇文章给大家介绍hanganalyze的示例分析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。
我们提供的服务有：网站设计、网站制作、微信公众号开发、网站优化、网站认证、通州ssl等。为上千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的通州网站制作公司
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
ORADEBUG hanganalyze
（集群范围内的）
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze
The
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 :
<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 :
<0/136/1/0x2ce1f6c4/7235/Streams AQ: waiting for time man>
Chain 3 :
<0/137/1/0x2ce1f110/7233/Streams AQ: qmn slave idle wait>
Chain 4 :
<0/142/18/0x2ce1dff4/8052/enq: TX - row lock contention>
Chain 5 :
<0/144/301/0x2ce1b254/8157/jobq slave wait>
Chain 6 :
<0/146/334/0x2ce1d48c/8153/No Wait>
Chain 7 :
<0/150/1/0x2ce1c924/7219/Streams AQ: qmn coordinator idle>
Chain 8 :
<0/158/38/0x2ce1c370/7528/enq: TX - row lock contention>
hanganalyze报告会分作许多片断，会话片断信息总是由一个header详尽描述被提取的的会话信息。Oracle8i和9i的信息略有不同：
Oracle 8.x chain header:
Oracle9i chain header:
首先了解下每个字段相关意思：
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的示例分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
本文名称：hanganalyze的示例分析
标题路径：http://ybzwz.com/article/poisji.html
