Oracle如何使用hanganalyze命令分析數(shù)據(jù)庫hang

小編給大家分享一下Oracle如何使用hanganalyze命令分析數(shù)據(jù)庫hang，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！

創(chuàng)新互聯(lián)建站服務(wù)項(xiàng)目包括臺江網(wǎng)站建設(shè)、臺江網(wǎng)站制作、臺江網(wǎng)頁制作以及臺江網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，臺江網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到臺江省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

1. 數(shù)據(jù)庫hang的幾種可能性
oracle 死鎖或者系統(tǒng)負(fù)載非常高比如cpu使用或其他一些鎖等待很高都可能導(dǎo)致系統(tǒng)hang住，比如大量的DX鎖。
通常來說，我們所指的系統(tǒng)hang住，是指應(yīng)用無響應(yīng)，普通的sqlplus幾乎無法操作等等。
2. 如何進(jìn)行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分析，因?yàn)榭赡軙a(chǎn)生非常大的trace，還可能對系統(tǒng)的IO有一定影響。
從oracle 9i開始 hanganalyze提供給了對rac的支持。
有如下2種方式：
1) ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level ';
2) 使用oradebug 命令
   ORADEBUG setmypid
   ORADEBUG setinst all
   ORADEBUG -g def hanganalyze   ---針對rac的用法
   oradebug setmypid
   oradebug hanganalyze 3               ---非rac環(huán)境
通常在做hang分析的時(shí)候，oracle建議同時(shí)做一個(gè)systemstate的dump
oradebug SYSTEMSTATE dump level 2     level 2即可， 包含了所有session的信息。
      sqlplus -prelim / as sysdba       ---10g可以使用此方式登錄
      oradebug setospid
      oradebug unlimit
      oradebug dump systemstate 10
補(bǔ)充：有時(shí)候我們可能還需要對某個(gè)進(jìn)程進(jìn)行trace aix環(huán)境，我們可以使用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
    <0/5210/10419/0x99d0a88/11215038/No Wait>                 --從這里看 session 5210 阻塞了54個(gè)對象
Open chains found:
Chain 1 : :   --從這里開始 以下的session都是被前面的5210阻塞 通常來說是一個(gè)阻塞另一個(gè)！
    <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 : :
    <0/4001/31548/0xf9f3ab0/4980956/enq: DX - contention>
Chain 3 : :
    <0/4014/30717/0xaa27b48/7446746/gc buffer busy>
Chain 4 : :
    <0/4039/42115/0xd9f5710/5595180/PX Deq: Table Q Normal>
Cycle 1 : :        -- 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     --》 每個(gè)session做hanganalyze生成的一個(gè)序列號
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       --》 節(jié)點(diǎn)號 從9i開始才有
關(guān)于state 有如下幾種值:
IN_HANG      --》 該狀態(tài)是一個(gè)非常危險(xiǎn)的狀態(tài)，通常表現(xiàn)為一個(gè)節(jié)點(diǎn)陷入了死循環(huán)或是hung。 一般來說出現(xiàn)這種情況，該節(jié)點(diǎn)的臨辟節(jié)點(diǎn)也是一樣的狀態(tài) 即adjlist
            如下例子：
            [16]/0/17/154/0x24617be0/26800/IN_HANG/29/32/[185]/19      ---從IN_HANG 我們可以看出 185是16的鄰居節(jié)點(diǎn)，185被16阻塞
            [185]/1/16/4966/0x24617270//IN_HANG/30/31/[16]/16          ---從這里看 185阻塞了16（16是waiter）
LEAF         --》通常是被認(rèn)為blockers的重點(diǎn)對象。那么如何去確定呢？ 一般來說，根據(jù)后面的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 因此我們認(rèn)為17阻塞了20
             [19]/0/20/13/0x24619830/26791/NLEAF/33/34/[16]/186     
LEAF_NW     --》 跟leaf類似 不過可能會占用cpu
NLEAF       --》該狀態(tài)的session通常被認(rèn)為 “stuck” session。即其他session所需要的資源正被其holding。
IGN         --》該狀態(tài)的session通常是處理IDLE狀態(tài)，除非其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是一個(gè)idle session。
SINGLE_NODE，SINGLE_NODE_NW 可以認(rèn)為跟LEAF，LEAF_NW一樣，除非沒有依賴對象。
本節(jié)我基于scott用戶產(chǎn)生兩個(gè)會話，模擬死鎖會話(一個(gè)update,一個(gè)delete)
SQL> oradebug help
HELP           [command]                 Describe one or all commands
SETMYPID                                 Debug current process
SETOSPID                          Set OS pid of process to debug
SETORAPID      ['force']        Set Oracle pid of process to debug
SHORT_STACK                              Dump abridged OS stack
DUMP           [addr]  Invoke named dump
DUMPSGA        [bytes]                   Dump fixed SGA
DUMPLIST                                 Print a list of available dumps
EVENT                              Set trace event in process
SESSION_EVENT                      Set trace event in session
DUMPVAR        [level]  Print/dump a fixed PGA/SGA/UGA variable
DUMPTYPE