hanganalyze的示例分析

這篇文章給大家介紹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 <level>'; -----（回話級別的hanganalyze）
ORADEBUG hanganalyze <level>    -----實例級別的hanganalyze
（集群范圍內的）
ORADEBUG setmypid
ORADEBUG setinst all
ORADEBUG -g def hanganalyze <level>
The <level> 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: oracle@product (TNS V1-V3)

第二部分：HANG ANALYSIS:
Open chains found:
Chain 1 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
    <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 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
    <0/136/1/0x2ce1f6c4/7235/Streams AQ: waiting for time man>
Chain 3 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
    <0/137/1/0x2ce1f110/7233/Streams AQ: qmn slave idle wait>
Chain 4 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
    <0/142/18/0x2ce1dff4/8052/enq: TX - row lock contention>
Chain 5 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
    <0/144/301/0x2ce1b254/8157/jobq slave wait>
Chain 6 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
    <0/146/334/0x2ce1d48c/8153/No Wait>
Chain 7 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
    <0/150/1/0x2ce1c924/7219/Streams AQ: qmn coordinator idle>
Chain 8 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
    <0/158/38/0x2ce1c370/7528/enq: TX - row lock contention>
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> :

首先了解下每個字段相關意思：
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

關于hanganalyze的示例分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。