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 <level>';
2) 使用oradebug 命令
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze <level> ---针对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 <process ID>
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 <cnode/sid/sess_srno/proc_ptr/ospid/wait_event>
<0/5210/10419/0x99d0a88/11215038/No Wait> --从这里看 session 5210 阻塞了54个对象
Open chains found:
Chain 1 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> : --从这里开始 以下的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 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/4001/31548/0xf9f3ab0/4980956/enq: DX - contention>
Chain 3 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/4014/30717/0xaa27b48/7446746/gc buffer busy>
Chain 4 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/4039/42115/0xd9f5710/5595180/PX Deq: Table Q Normal>
Cycle 1 : <sid/sess_srno/proc_ptr/ospid/wait_event> : -- 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 <ospid> Set OS pid of process to debug
SETORAPID <orapid> ['force'] Set Oracle pid of process to debug
SHORT_STACK Dump abridged OS stack
DUMP <dump_name> <lvl> [addr] Invoke named dump
DUMPSGA [bytes] Dump fixed SGA
DUMPLIST Print a list of available dumps
EVENT <text> Set trace event in process
SESSION_EVENT <text> Set trace event in session
DUMPVAR <p|s|uga> <name> [level] Print/dump a fixed PGA/SGA/UGA variable
DUMPTYPE <address> <type> <count> Print/dump an address with type info
SETVAR <p|s|uga> <name> <value> Modify a fixed PGA/SGA/UGA variable
PEEK <addr> <len> [level] Print/Dump memory
POKE <addr> <len> <value> Modify memory
WAKEUP <orapid> Wake up Oracle process
SUSPEND Suspend execution
RESUME Resume execution
FLUSH Flush pending writes to trace file
CLOSE_TRACE Close trace file
TRACEFILE_NAME Get name of trace file
LKDEBUG Invoke global enqueue service debugger
NSDBX Invoke CGS name-service debugger
-G <Inst-List | def | all> Parallel oradebug command prefix
-R <Inst-List | def | all> Parallel oradebug prefix (return output
SETINST <instance# .. | all> Set instance list in double quotes
SGATOFILE <SGA dump dir> Dump SGA to file; dirname in double quotes
DMPCOWSGA <SGA dump dir> Dump & map SGA as COW; dirname in double quotes
MAPCOWSGA <SGA dump dir> Map SGA as COW; dirname in double quotes
HANGANALYZE [level] [syslevel] Analyze system hang
FFBEGIN Flash Freeze the Instance
FFDEREGISTER FF deregister instance from cluster
FFTERMINST Call exit and terminate instance
FFRESUMEINST Resume the flash frozen instance
FFSTATUS Flash freeze status of instance
SKDSTTPCS <ifname> <ofname> Helps translate PCs to names
WATCH <address> <len> <self|exist|all|target> Watch a region of memory
DELETE <local|global|target> watchpoint <id> Delete a watchpoint
SHOW <local|global|target> watchpoints Show watchpoints
CORE Dump core without crashing process
IPC Dump ipc information
UNLIMIT Unlimit the size of the trace file
PROCSTAT Dump process statistics
CALL <func> [arg1] ... [argn] Invoke function with arguments
SQL> oradebug hanganalyze 3;
Hang Analysis in /oracle/admin/orcl/udump/orcl_ora_2622.trc
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
-bash-3.2$ more /oracle/admin/orcl/udump/orcl_ora_2622.trc
/oracle/admin/orcl/udump/orcl_ora_2622.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: truerhel5
Release: 2.6.18-164.el5
Version: #1 SMP Tue Aug 18 15:51:48 EDT 2009
Machine: x86_64
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 2622, image:oracle@truerhel5(TNS V1-V3)
*** SERVICE NAME:(SYS$USERS) 2010-08-07 21:11:10.818
*** SESSION ID:(145.36) 2010-08-07 21:11:10.818
*** 2010-08-07 21:11:10.818
==============
HANG ANALYSIS:
==============
Open chains found:
Chain 1 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> : --每列的注解：分为cnode sid sess_srno proc_ptr ospid wait_event
<0/148/27/0x70e5e4a8/2543/SQL*Net message from client> --会话148(持锁会话）
-- <0/146/84/0x70e5f478/2607/enq: TX - row lock contention> --会话146(等待锁会话），竞争事件为：row lock contention
Other chains found:
Chain 2 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/144/108/0x70e5ccf0/2614/jobq slave wait>
Chain 3 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/145/36/0x70e5fc60/2622/No Wait>
Chain 4 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/150/2/0x70e623e8/2338/Streams AQ: waiting for time man>
Chain 5 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/151/1/0x70e5ec90/2319/Streams AQ: qmn coordinator idle>
Chain 6 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/158/7/0x70e61c00/2336/Streams AQ: qmn slave idle wait>
Extra information that will be dumped at higher levels:
[level 4] : 1 node dumps -- [REMOTE_WT] [LEAF] [LEAF_NW]
[level 5] : 5 node dumps -- [SINGLE_NODE] [SINGLE_NODE_NW] [IGN_DMP]
[level 6] : 1 node dumps -- [NLEAF]
[level 10] : 13 node dumps -- [IGN]
State of nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor):
[143]/0/144/108/0x70f5dcf8/2614/SINGLE_NODE/1/2//none
[144]/0/145/36/0x70f5f130/2622/SINGLE_NODE_NW/3/4//none
[145]/0/146/84/0x70f60568/2607/NLEAF/5/8/[147]/none
[147]/0/148/27/0x70f62dd8/2543/LEAF/6/7//145
[149]/0/150/2/0x70f65648/2338/SINGLE_NODE/9/10//none
[150]/0/151/1/0x70f66a80/2319/SINGLE_NODE/11/12//none
[154]/0/155/1/0x70f6bb60/2315/IGN/13/14//none
[155]/0/156/1/0x70f6cf98/2313/IGN/15/16//none
[157]/0/158/7/0x70f6f808/2336/SINGLE_NODE/17/18//none
[159]/0/160/1/0x70f72078/2305/IGN/19/20//none
[160]/0/161/1/0x70f734b0/2303/IGN/21/22//none
[161]/0/162/1/0x70f748e8/2301/IGN/23/24//none
[162]/0/163/1/0x70f75d20/2299/IGN/25/26//none
[163]/0/164/1/0x70f77158/2297/IGN/27/28//none
[164]/0/165/1/0x70f78590/2295/IGN/29/30//none
[165]/0/166/1/0x70f799c8/2293/IGN/31/32//none
[166]/0/167/1/0x70f7ae00/2291/IGN/33/34//none
[167]/0/168/1/0x70f7c238/2289/IGN/35/36//none
[168]/0/169/1/0x70f7d670/2287/IGN/37/38//none
[169]/0/170/1/0x70f7eaa8/2285/IGN/39/40//none
====================
END OF HANG ANALYSIS
====================
其内容意思大概如下
cnode--节点代号,如果为rac,其值就存在,单节点的值为0
sid---session的sid
sess_srno---session的serial#
proc_ptr--系统进程指向的address
ospid ----进程号
wait_event---session的等待事件
转摘白大师部分节选
Hanganalyze是从Oracle 8i r2(8.1.6)开始提供的，其用法十分简单：
ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level <level>';
或者
ORADEBUG hanganalyze <level>
比如：
sql>oradebug setmypid;
sql>oradebug hanganalyze 3;
对于<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
-bash-3.2$ sqlplus -prelim '/as sysdba' --通过prelim选项进入已经hang住（正常方式进不了sqlplus)的数据库
SQL*Plus: Release 10.2.0.1.0 - Production on Sat Aug 7 21:17:42 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> show parameter sga
ORA-01012: not logged on
SQL> conn /as sysdba
Prelim connection established
SQL>
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 <level>';
2) 使用oradebug 命令
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze <level> ---针对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 <process ID>
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 <cnode/sid/sess_srno/proc_ptr/ospid/wait_event>
<0/5210/10419/0x99d0a88/11215038/No Wait> --从这里看 session 5210 阻塞了54个对象
Open chains found:
Chain 1 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> : --从这里开始 以下的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 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/4001/31548/0xf9f3ab0/4980956/enq: DX - contention>
Chain 3 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/4014/30717/0xaa27b48/7446746/gc buffer busy>
Chain 4 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/4039/42115/0xd9f5710/5595180/PX Deq: Table Q Normal>
Cycle 1 : <sid/sess_srno/proc_ptr/ospid/wait_event> : -- 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 <ospid> Set OS pid of process to debug
SETORAPID <orapid> ['force'] Set Oracle pid of process to debug
SHORT_STACK Dump abridged OS stack
DUMP <dump_name> <lvl> [addr] Invoke named dump
DUMPSGA [bytes] Dump fixed SGA
DUMPLIST Print a list of available dumps
EVENT <text> Set trace event in process
SESSION_EVENT <text> Set trace event in session
DUMPVAR <p|s|uga> <name> [level] Print/dump a fixed PGA/SGA/UGA variable
DUMPTYPE <address> <type> <count> Print/dump an address with type info
SETVAR <p|s|uga> <name> <value> Modify a fixed PGA/SGA/UGA variable
PEEK <addr> <len> [level] Print/Dump memory
POKE <addr> <len> <value> Modify memory
WAKEUP <orapid> Wake up Oracle process
SUSPEND Suspend execution
RESUME Resume execution
FLUSH Flush pending writes to trace file
CLOSE_TRACE Close trace file
TRACEFILE_NAME Get name of trace file
LKDEBUG Invoke global enqueue service debugger
NSDBX Invoke CGS name-service debugger
-G <Inst-List | def | all> Parallel oradebug command prefix
-R <Inst-List | def | all> Parallel oradebug prefix (return output
SETINST <instance# .. | all> Set instance list in double quotes
SGATOFILE <SGA dump dir> Dump SGA to file; dirname in double quotes
DMPCOWSGA <SGA dump dir> Dump & map SGA as COW; dirname in double quotes
MAPCOWSGA <SGA dump dir> Map SGA as COW; dirname in double quotes
HANGANALYZE [level] [syslevel] Analyze system hang
FFBEGIN Flash Freeze the Instance
FFDEREGISTER FF deregister instance from cluster
FFTERMINST Call exit and terminate instance
FFRESUMEINST Resume the flash frozen instance
FFSTATUS Flash freeze status of instance
SKDSTTPCS <ifname> <ofname> Helps translate PCs to names
WATCH <address> <len> <self|exist|all|target> Watch a region of memory
DELETE <local|global|target> watchpoint <id> Delete a watchpoint
SHOW <local|global|target> watchpoints Show watchpoints
CORE Dump core without crashing process
IPC Dump ipc information
UNLIMIT Unlimit the size of the trace file
PROCSTAT Dump process statistics
CALL <func> [arg1] ... [argn] Invoke function with arguments
SQL> oradebug hanganalyze 3;
Hang Analysis in /oracle/admin/orcl/udump/orcl_ora_2622.trc
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
-bash-3.2$ more /oracle/admin/orcl/udump/orcl_ora_2622.trc
/oracle/admin/orcl/udump/orcl_ora_2622.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /oracle/product/10.2.0/db_1
System name: Linux
Node name: truerhel5
Release: 2.6.18-164.el5
Version: #1 SMP Tue Aug 18 15:51:48 EDT 2009
Machine: x86_64
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 2622, image:oracle@truerhel5(TNS V1-V3)
*** SERVICE NAME:(SYS$USERS) 2010-08-07 21:11:10.818
*** SESSION ID:(145.36) 2010-08-07 21:11:10.818
*** 2010-08-07 21:11:10.818
==============
HANG ANALYSIS:
==============
Open chains found:
Chain 1 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> : --每列的注解：分为cnode sid sess_srno proc_ptr ospid wait_event
<0/148/27/0x70e5e4a8/2543/SQL*Net message from client> --会话148(持锁会话）
-- <0/146/84/0x70e5f478/2607/enq: TX - row lock contention> --会话146(等待锁会话），竞争事件为：row lock contention
Other chains found:
Chain 2 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/144/108/0x70e5ccf0/2614/jobq slave wait>
Chain 3 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/145/36/0x70e5fc60/2622/No Wait>
Chain 4 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/150/2/0x70e623e8/2338/Streams AQ: waiting for time man>
Chain 5 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/151/1/0x70e5ec90/2319/Streams AQ: qmn coordinator idle>
Chain 6 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<0/158/7/0x70e61c00/2336/Streams AQ: qmn slave idle wait>
Extra information that will be dumped at higher levels:
[level 4] : 1 node dumps -- [REMOTE_WT] [LEAF] [LEAF_NW]
[level 5] : 5 node dumps -- [SINGLE_NODE] [SINGLE_NODE_NW] [IGN_DMP]
[level 6] : 1 node dumps -- [NLEAF]
[level 10] : 13 node dumps -- [IGN]
State of nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/start/finish/[adjlist]/predecessor):
[143]/0/144/108/0x70f5dcf8/2614/SINGLE_NODE/1/2//none
[144]/0/145/36/0x70f5f130/2622/SINGLE_NODE_NW/3/4//none
[145]/0/146/84/0x70f60568/2607/NLEAF/5/8/[147]/none
[147]/0/148/27/0x70f62dd8/2543/LEAF/6/7//145
[149]/0/150/2/0x70f65648/2338/SINGLE_NODE/9/10//none
[150]/0/151/1/0x70f66a80/2319/SINGLE_NODE/11/12//none
[154]/0/155/1/0x70f6bb60/2315/IGN/13/14//none
[155]/0/156/1/0x70f6cf98/2313/IGN/15/16//none
[157]/0/158/7/0x70f6f808/2336/SINGLE_NODE/17/18//none
[159]/0/160/1/0x70f72078/2305/IGN/19/20//none
[160]/0/161/1/0x70f734b0/2303/IGN/21/22//none
[161]/0/162/1/0x70f748e8/2301/IGN/23/24//none
[162]/0/163/1/0x70f75d20/2299/IGN/25/26//none
[163]/0/164/1/0x70f77158/2297/IGN/27/28//none
[164]/0/165/1/0x70f78590/2295/IGN/29/30//none
[165]/0/166/1/0x70f799c8/2293/IGN/31/32//none
[166]/0/167/1/0x70f7ae00/2291/IGN/33/34//none
[167]/0/168/1/0x70f7c238/2289/IGN/35/36//none
[168]/0/169/1/0x70f7d670/2287/IGN/37/38//none
[169]/0/170/1/0x70f7eaa8/2285/IGN/39/40//none
====================
END OF HANG ANALYSIS
====================
其内容意思大概如下
cnode--节点代号,如果为rac,其值就存在,单节点的值为0
sid---session的sid
sess_srno---session的serial#
proc_ptr--系统进程指向的address
ospid ----进程号
wait_event---session的等待事件
转摘白大师部分节选
Hanganalyze是从Oracle 8i r2(8.1.6)开始提供的，其用法十分简单：
ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level <level>';
或者
ORADEBUG hanganalyze <level>
比如：
sql>oradebug setmypid;
sql>oradebug hanganalyze 3;
对于<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
-bash-3.2$ sqlplus -prelim '/as sysdba' --通过prelim选项进入已经hang住（正常方式进不了sqlplus)的数据库
SQL*Plus: Release 10.2.0.1.0 - Production on Sat Aug 7 21:17:42 2010
Copyright (c) 1982, 2005, Oracle. All rights reserved.
SQL> show parameter sga
ORA-01012: not logged on
SQL> conn /as sysdba
Prelim connection established
SQL>