這篇文章給大家介紹hanganalyze的示例分析，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

我們提供的服務(wù)有：網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、微信公眾號(hào)開(kāi)發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、通州ssl等。為上千家企事業(yè)單位解決了網(wǎng)站和推廣的問(wèn)題。提供周到的售前咨詢(xún)和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的通州網(wǎng)站制作公司

ORACLE 的HANGANALYZE是在數(shù)據(jù)庫(kù)出現(xiàn)了異常狀況，因?yàn)閔ang住而產(chǎn)生嚴(yán)重的性能問(wèn)題，而通過(guò)HANGANALYZE  功能產(chǎn)生的日志可以幫助我們快速的定位是否是2個(gè)或者多個(gè)進(jìn)程死鎖了，有多少進(jìn)程收到影響。 從而幫助我們?cè)\斷出數(shù)據(jù)庫(kù)的問(wèn)題。
關(guān)于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的時(shí)候推出了HANGANALYZE(8.1.6),并在9i中擴(kuò)展了該功能，添加了集群范圍內(nèi)的HANGANALYZE分析。這種分析是針對(duì)內(nèi)核級(jí)別的資源爭(zhēng)用，由于oracle無(wú)法檢測(cè)并回滾其中一個(gè)操作，需要人為干預(yù)，而當(dāng)大量的該操作發(fā)生后，數(shù)據(jù)庫(kù)就有可能被完全HANG住。
應(yīng)用場(chǎng)景：
1、數(shù)據(jù)庫(kù)被完全HANG住無(wú)法打開(kāi)，sqlplus 回話無(wú)法連接操作，此時(shí)就需要我們使用hanganalyze分析并找到最根源占用回話進(jìn)程殺掉。
2、某對(duì)象被無(wú)數(shù)回話占用，嘗試kill掉所有的鎖后回話仍然存在，只能找到根源會(huì)話并殺掉該會(huì)話。

使用方法：
3 Syntax Examples:
ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level '; -----（回話級(jí)別的hanganalyze）
ORADEBUG hanganalyze     -----實(shí)例級(jí)別的hanganalyze
（集群范圍內(nèi)的）
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出所有在等待鏈中的進(jìn)程（狀態(tài)為NLEAF）
4   Level 3 + Dump leaf nodes (blockers) in wait chains (LEAF,LEAF_NW,IGN_DMP state) ---Level3+Dump出在等待鏈里面的blockers(狀態(tài)為L(zhǎng)EAF/LEAF_NW/IGN_DMP) 
3   Level 2 + Dump only processes thought to be in a hang (IN_HANG state) ---（LEVEL2+IN_HANG狀態(tài)的進(jìn)程）
1-2   Only HANGANALYZE output, no process dump at all
IN_HANG：如果Session處于這種狀態(tài)，表示Session遇到deadlock或者處于hung狀態(tài)。
LEAF/LEAF_NW：LEAF/LEAF_NW：這些Session通常是“blocker”或者是等待某些資源的“slow” node，通過(guò)字段“predecessor” 可以很容易標(biāo)識(shí)出這些node。
NLEAF：通?？梢钥醋鬟@些會(huì)話是被阻塞的資源。意味著這些Session在等待某些Session的資源。通過(guò)字段“adjlist”可以很容易的定義該進(jìn)程的blocker。
IGN/IGN_DMP：這類(lèi)會(huì)話通常被認(rèn)為是空閑會(huì)話，除非其adjlist列里存在node。如果是非空閑會(huì)話則說(shuō)明其adjlist里的node正在等待其他node釋放資源。
SINGLE_NODE/SINGLE_NODE_NW：近似于空閑會(huì)話
我們需要關(guān)注的重點(diǎn)也就是處于IN_HANG狀態(tài)的回話，而且，一般oracleOracle建議不要采用3級(jí)以上的跟蹤，如果Level過(guò)大的話會(huì)產(chǎn)生大量的跟蹤文件并影響系統(tǒng)的I/O性能

測(cè)試（本機(jī)測(cè)試環(huán)境單機(jī)10g環(huán)境）：
我們先使數(shù)據(jù)庫(kù)產(chǎn)生一些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
接下來(lái)做一個(gè)hanganalyze分析：
SQL> oradebug hanganalyze 3;
Hang Analysis in /oracle/app/admin/orcl/udump/orcl_ora_8153.trc

打開(kāi)跟蹤文件查看：
該跟蹤文件分成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 : :
    <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報(bào)告會(huì)分作許多片斷，會(huì)話片斷信息總是由一個(gè)header詳盡描述被提取的的會(huì)話信息。Oracle8i和9i的信息略有不同：
Oracle 8.x chain header:

Oracle9i chain header:
:

首先了解下每個(gè)字段相關(guān)意思：
sid是 Session ID
sess_srno是serial#
proc_ptr是Process Pointer 理解為進(jìn)程指針地址
ospid 是OS Process ID
cnode是Node Id，Oracle9i才用
wait 是表示是等待的參數(shù)
在此處我們可以清楚的看到，回話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
這部分也是用來(lái)描述個(gè)回話進(jìn)程所處的狀態(tài)。
Nodenum是hanganalyze
自己為了記錄這些會(huì)話而定制的編號(hào)，從0開(kāi)始排起。
State 是node的狀態(tài)
Adjlist是臨近的node(通常代表一個(gè)blocker node)
Predecessor是Predecessor node ,通常代表一個(gè) waiter node

關(guān)于hanganalyze的示例分析就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。