hanganalyze 學習

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 '; -----（回話級別的hanganalyze）
ORADEBUG hanganalyze     -----例項級別的hanganalyze
（叢集範圍內的）
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze
The sets the amount of additional information that will be extracted from the processes found by HANGANALYZE (ERROSTACK dump) based on the "STATE" of the node. 
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: (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