教你熟練使用hanganalyze來分析數據庫

1.爲什麼要使用hanganalyze?

Oracle數據庫“真的”hang住了，可以理解爲數據庫內部發生死鎖。因爲普通的DML死鎖，oracle服務器會自動監測他們的依賴關係，並回滾其中一個操作，終止這種相互等待的局面。而當這種死鎖發生在爭奪內核級別的資源（比如說是pins或latches）時，Oracle並不能自動的監測並處理這種死鎖。

其實很多時候數據庫並沒有hang住，而只是由於數據庫的性能問題，處理的時間比較長而已。

Hanganalyze工具使用內核調用檢測會話在等待什麼資源，報告出佔有者和等待者的相互關係。另外，它還會將一些比較”interesting”的進程狀態dump出來，這個取決於我們使用hanganalyze的分析級別。

使用hanganalyze

hanganalyze工具從oracle8i第二版開始提供，到9i增強了診斷RAC環境下的“集羣範圍”的信息，這意味着它將會報告出整個集羣下的所有會話的信息。

目前有三種使用hanganalyze的方法:

一種是會話級別的：


ALTER SESSION SET EVENTS 'immediate
trace name HANGANALYZE level <level>';

一種是實例級別:


ORADEBUG hanganalyze <level>

一種是集羣範圍的：


ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze <level>

先解釋下各個level的含義：

1-2:只有hanganalyze輸出，不dump任何進程

3：Level2+Dump出在IN_HANG狀態的進程

4：Level3+Dump出在等待鏈裏面的blockers(狀態爲LEAF/LEAF_NW/IGN_DMP)

5：Level4+Dump出所有在等待鏈中的進程（狀態爲NLEAF）

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> :

先把在trace file中看到的一些縮略語解釋一下：


sid是 Session ID
sess_srno是serial#
proc_ptr是Process Pointer
ospid 是OS Process ID
cnode是Node Id，Oracle9i才用
Nodenum是hanganalyze
自己爲了記錄這些會話而定製的編號，從0開始排起。
State 是node的狀態
Adjlist是臨近的node(通常代表一個blocker node)
Predecessor是Predecessor node ,通常代表一個 waiter node


接着解釋一下比較重要的一些node state:

IN_HANG：這表示該node處於死鎖狀態，通常還有其他node（blocker）也處於該狀態

LEAF/LEAF_NW：該node通常是blocker。通過條目的”predecessor”列可以判斷這個node是否是blocker。LEAF說明該NODE沒有等待其他資源，而LEAF_NW則可能是沒有等待其他資源或者是在使用CPU.

如下的實例說明了node16阻塞了node19的資源：


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

NLEAF：通常可以看作這些會話是被阻塞的資源。發生這種情況一般說明數據庫發生性能問題而不是數據庫hang

IGN/IGN_DMP：這類會話通常被認爲是空閒會話，除非其adjlist列裏存在node。如果是非空閒會話則說明其adjlist裏的node正在等待其他node釋放資源。

SINGLE_NODE/SINGLE_NODE_NW：近似於空閒會話

實戰hanganalyze:


生成跟蹤文件
SQL> oradebug setmypid
已處理的語句
SQL> oradebug hanganalyze 3

查看跟蹤文件


==============
HANG ANALYSIS:
==============
Open chains found:
Chain 1 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<5/1/0x843630f8/2531/No Wait>
Chain 2 : <sid/sess_srno/proc_ptr/ospid/wait_event> :
<12/1/0x84364e48/2521/instance state change>

有一個等待事件，操作系統進程是2521，經檢查，是smon，佔用了一個CPU的98％的資源


Other chains found:
Extra information that will be dumped at higher levels:
[level 4] : 2 node dumps -- [LEAF] [LEAF_NW] [IGN_DMP]
[level 10] : 6 node dumps -- [IGN]
State of nodes
([nodenum]/sid/sess_srno/session/state/
start/finish/[adjlist]/predecessor):
[0]/1/1/0x84405460/IGN/1/2//none
[1]/2/1/0x84405de0/IGN/3/4//none
[2]/3/1/0x84406760/IGN/5/6//none
[3]/4/1/0x844070e0/IGN/7/8//none
[4]/5/1/0x84407a60/LEAF_NW/9/10//none
[5]/6/1/0x844083e0/IGN/11/12//none
[10]/11/1/0x8440b360/IGN/13/14//none
[11]/12/1/0x8440bce0/LEAF/15/16//none
Dumping System_State and
Fixed_SGA in process with ospid 2521
Dumping Process information
for process with ospid 2531
Dumping Process information
for process with ospid 2521
*** 2004-12-09 00:07:49.680
====================
END OF HANG ANALYSIS
====================

我們看到，並沒有發生死鎖，Smon進程忙，說明在正確釋放資源。