Oracle如何使用hanganalyze命令分析数据库hang

小编给大家分享一下Oracle如何使用hanganalyze命令分析数据库hang，希望大家阅读完这篇文章之后都有所收获，下面让我们一起去探讨吧！

1. 数据库hang的几种可能性
oracle 死锁或者系统负载非常高比如cpu使用或其他一些锁等待很高都可能导致系统hang住，比如大量的DX锁。
通常来说，我们所指的系统hang住，是指应用无响应，普通的sqlplus几乎无法操作等等。
2. 如何进行hang分析？hang分析有哪些level？如何选择level？
hanganalyze有如下几种level：
10 Dump all processes (IGN state)
5 Level 4 + Dump all processes involved in wait chains (NLEAF state)
4 Level 3 + Dump leaf nodes (blockers) in wait chains (LEAF,LEAF_NW,IGN_DMP state)
3 Level 2 + Dump only processes thought to be in a hang (IN_HANG state)
1-2 Only HANGANALYZE output, no process dump at all
如何选择level？
一般来说，不建议使用3以上级别的hang分析，因为可能会产生非常大的trace，还可能对系统的IO有一定影响。
从oracle 9i开始 hanganalyze提供给了对rac的支持。
有如下2种方式：
1) ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level ';
2) 使用oradebug 命令
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze ---针对rac的用法
oradebug setmypid
oradebug hanganalyze 3 ---非rac环境
通常在做hang分析的时候，oracle建议同时做一个systemstate的dump
oradebug SYSTEMSTATE dump level 2 level 2即可， 包含了所有session的信息。
sqlplus -prelim / as sysdba ---10g可以使用此方式登录
oradebug setospid
oradebug unlimit
oradebug dump systemstate 10
补充：有时候我们可能还需要对某个进程进行trace aix环境，我们可以使用dbx命令
如下例子：
dbx -a PID (where PID = any oracle shadow process) ---通过ps -ef|grep xxx查看
dbx() print ksudss(10)
dbx() detach
3. 如何解读hang分析的trace文件，获取有用信息?
*** ACTION NAME:() 2010-03-12 00:04:01.497
*** MODULE NAME:(sqlplus@S7_C_YZ_YZSJK(TNS V1-V3)) 2010-03-12 00:04:01.497 ---模块名 跟v$session.module_name一样
*** SERVICE NAME:(SYS$USERS) 2010-03-12 00:04:01.497
*** SESSION ID:(5184.45287) 2010-03-12 00:04:01.497 --sid (5184) serial# (35287)
*** 2010-03-12 00:04:01.497
==============
HANG ANALYSIS:
==============
Found 54 objects waiting for
<0/5210/10419/0x99d0a88/11215038/No Wait> --从这里看 session 5210 阻塞了54个对象
Open chains found:
Chain 1 : : --从这里开始 以下的session都是被前面的5210阻塞 通常来说是一个阻塞另一个！
<0/5210/10419/0x99d0a88/11215038/No Wait>
-- <0/3994/15494/0xd9ac1b0/6574102/enq: TM - contention>
-- <0/4962/58962/0xca03618/5710044/enq: DX - contention>
Other chains found: --下面的session也是被前面所阻塞 不过不是直接阻塞（by Open chains） 间接阻塞！
Chain 2 : :
<0/4001/31548/0xf9f3ab0/4980956/enq: DX - contention>
Chain 3 : :
<0/4014/30717/0xaa27b48/7446746/gc buffer busy>
Chain 4 : :
<0/4039/42115/0xd9f5710/5595180/PX Deq: Table Q Normal>
Cycle 1 : : -- cycle 通常是死锁 一般来说很有可能就是hang的根源
<980/3887/0xe4214964/24065/latch free>
-- <2518/352/0xe4216560/24574/latch free>
-- <55/10/0xe41236a8/13751/latch free>

4. 不同版本hang分析的差异？trace有何异同？
如下是oracle8~10g的 hanganalyze trace信息格式：
Oracle 8.x : [nodenum]/sid/sess_srno/session/state/start/finish/[adjlist]/predecessor
Oracle 9i: [nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor
Oracle 10g： [nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor
Nodenum --》 每个session做hanganalyze生成的一个序列号
sid --》 Session ID
sess_srno --》 Serial#
ospid --》 OS Process Id (v$process spid)
state --》 State of the node
adjlist --》 adjacent node (Usually represents a blocker node) --通常是阻塞者
predecessor --》 predecessor node (Usually represents a waiter node) --通常是被阻塞者
cnode --》 节点号 从9i开始才有
关于state 有如下几种值:
IN_HANG --》 该状态是一个非常危险的状态，通常表现为一个节点陷入了死循环或是hung。 一般来说出现这种情况，该节点的临辟节点也是一样的状态 即adjlist
如下例子：
[16]/0/17/154/0x24617be0/26800/IN_HANG/29/32/[185]/19 ---从IN_HANG 我们可以看出 185是16的邻居节点，185被16阻塞
[185]/1/16/4966/0x24617270//IN_HANG/30/31/[16]/16 ---从这里看 185阻塞了16（16是waiter）
LEAF --》通常是被认为blockers的重点对象。那么如何去确定呢？ 一般来说，根据后面的predecesor来判断该session是不是blocker或者是waiter。
如下例子：
[ nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor
[16]/0/17/154/0x24617be0/26800/LEAF/29/30//19 --从这里看19是waiter 因此我们认为17阻塞了20
[19]/0/20/13/0x24619830/26791/NLEAF/33/34/[16]/186
LEAF_NW --》 跟leaf类似 不过可能会占用cpu
NLEAF --》该状态的session通常被认为 "stuck" session。即其他session所需要的资源正被其holding。
IGN --》该状态的session通常是处理IDLE状态，除非其adjlist存在，如果是，那么该session正在等待其他session。
IGN_DMP --》跟 IGN 类似。
如下例子：
[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
[189]/1/20/36/0x24619830//IGN/95/96/[19]/none
[176]/1/7/1/0x24611d80//IGN/75/76//none
----从上面看，189在等待19,19在等待16，而176是一个idle session。
SINGLE_NODE，SINGLE_NODE_NW 可以认为跟LEAF，LEAF_NW一样，除非没有依赖对象。
本节我基于scott用户产生两个会话，模拟死锁会话(一个update,一个delete)
SQL> oradebug help
HELP [command] Describe one or all commands
SETMYPID Debug current process
SETOSPID Set OS pid of process to debug
SETORAPID ['force'] Set Oracle pid of process to debug
SHORT_STACK Dump abridged OS stack
DUMP [addr] Invoke named dump
DUMPSGA [bytes] Dump fixed SGA
DUMPLIST Print a list of available dumps
EVENT Set trace event in process
SESSION_EVENT Set trace event in session
DUMPVAR [level] Print/dump a fixed PGA/SGA/UGA variable
DUMPTYPE