【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 <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>
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29067253/viewspace-2145575/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Oracle使用hanganalyze 命令分析資料庫hang【轉】Oracle資料庫
- oracle資料庫hang住分析工具Hanganalyze使用總結Oracle資料庫
- 資料庫Hang住怎麼辦 - HANGANALYZE資料庫
- 使用oradebug dump hanganalyze分析oracle hang系列一Oracle
- 使用oradebug dump hanganalyze 分析oracle hang系列二Oracle
- 使用oradebug dump hanganalyze 分析oracle hang系列三Oracle
- 資料庫Hang住怎麼辦 - HANGANALYZE[final]資料庫
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列四Oracle
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列五Oracle
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列六Oracle
- 【Oracle】資料庫hang 診斷Oracle資料庫
- 資料庫hang分析（sql*plus不能登陸）[轉載]資料庫SQL
- 資料庫hang住，分析處理資料庫
- 導數時資料庫hang住分析資料庫
- Oracle資料庫資料物件分析(轉)Oracle資料庫物件
- Oracle Hang分析Oracle
- 使用HangFG進行Oracle Hang分析Oracle
- 資料庫HANG著資料庫
- 9i資料庫hang死分析處理資料庫
- oracledebug hanganalyze分析會話等待及儲存過程hangOracle會話儲存過程
- 資料庫突然hang了資料庫
- oracle資料庫使用sqlldr命令匯入txt資料Oracle資料庫SQL
- oracle資料庫 exp/imp命令詳解(轉)Oracle資料庫
- 使用HANGANALYZE跟蹤檔案診例項hang問題
- oracle 10gR2 用emca命令線上重建em會導致資料庫hangOracle 10g資料庫
- oracle資料庫連線後，hang機一例Oracle資料庫
- 【轉載】[效能分析]Oracle資料庫效能模型Oracle資料庫模型
- Oracle資料庫遊標使用大全(轉)Oracle資料庫
- Oracle 19.3資料庫impdp匯入view時hang住Oracle資料庫View
- Oracle 28.6資料庫impdp匯入view時hang@11Oracle資料庫View
- 分析Oracle資料庫日誌檔案(1)（轉）Oracle資料庫
- 分析Oracle資料庫日誌檔案(1) [轉]Oracle資料庫
- 入侵oracle資料庫時常用的操作命令整理(轉)Oracle資料庫
- oradebug分析oracle hangOracle
- 在ASP中使用Oracle資料庫(2)（轉）Oracle資料庫
- oracle僵死會話鎖住buffer，導致資料庫hang住Oracle會話資料庫
- Oracle hanganalyzeOracle
- Oracle資料庫資料物件分析（上）Oracle資料庫物件