使用oradebug dump hanganalyze 分析oracle hang系列二
背景
基於上文:使用oradebug dump hanganalyze分析oracle hang系列一,http://blog.itpub.net/9240380/viewspace-1823479/,繼續熟悉TRACE FILE內容。結論
1,DUMP FILE第三部分的構成State of ALL nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[9]/1/10/1/0xdcba9740/10574/NLEAF/[31]
2,state列暫時共發現如下3個值
NLEAF
SINGLE_NODE
LEAF_NW
3,state列3個值的含義
NLEAF表明等待會話,而LEAF_NW表明持鎖會話
SINGLE_NODE它不等待任何會話也不阻塞任何會話
而且如果state值為NLEAF,adjlist列會有值,這個值到底是什麼含義呢?
4,如果state值為NLEAF,adjlist列會有值,這個值到底是什麼含義呢?
我們隨機挑出相關匹配記錄,找出它們的規律,分析adjlist的含義,可見NLEAF後面的adjlist等於持鎖會話sid+1,也就是說用adjlist-1就是持鎖會話的sid,直接可以找到持鎖會話的SID
5,
經過分析第1列即nodenum不是對應chain的編號,那麼它是什麼呢
經過對比分析,第一列nodenum其實就是一個順序編號,不過它是和第3列sid對應起來,就是說下面的記錄基於sid列的值進行升序排序,每行產生一個順序編號,就是第一列nodenum的值
6,關於第一部分的構成含義,將在下文進行學習
測試
1,瞭解下state列不同值的含義
State of ALL nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[9]/1/10/1/0xdcba9740/10574/NLEAF/[31]
2,state列從目前的TRACE FILE共有
NLEAF
SINGLE_NODE
LEAF_NW
3,下面我們依次來看,先看NLEAF
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[9]/1/10/1/0xdcba9740/10574/NLEAF/[31]
其上對應的chain
由上定位到如下
[31]/1/32/9465/0xdcb699a0/6664/LEAF_NW/
另啟一路分析
[41]/1/42/10233/0xdcb4c940/6724/NLEAF/[204]
[204]/1/205/9696/0xdc9737f0/6439/LEAF_NW/
經過分析第1列即nodenum不是對應chain的編號,那麼它是什麼呢
經過對比分析,第一列nodenum其實就是一個順序編號,不過它是和第3列sid對應起來,就是說下面的記錄基於sid列的值進行升序排序,每行產生一個順序編號,就是第一列nodenum的值
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[9]/1/10/1/0xdcba9740/10574/NLEAF/[31]
[11]/1/12/1/0xdcba3a60/10578/SINGLE_NODE/
[28]/1/29/10069/0xdcb724f0/6728/NLEAF/[204]
[31]/1/32/9465/0xdcb699a0/6664/LEAF_NW/
[32]/1/33/11792/0xdcb66b30/6612/NLEAF/[204]
[33]/1/34/3/0xdcb63cc0/10707/SINGLE_NODE/
[38]/1/39/9453/0xdcb55490/6754/NLEAF/[204]
[39]/1/40/8844/0xdcb52620/6789/NLEAF/[204]
[41]/1/42/10233/0xdcb4c940/6724/NLEAF/[204]
[43]/1/44/11098/0xdcb46c60/6785/NLEAF/[204]
[45]/1/46/10603/0xdcb40f80/6716/NLEAF/[204]
[48]/1/49/10605/0xdcb38430/6387/NLEAF/[195]
[50]/1/51/10173/0xdcb32750/6584/NLEAF/[204]
[53]/1/54/10303/0xdcb29c00/6626/NLEAF/[204]
[55]/1/56/11968/0xdcb23f20/6722/NLEAF/[204]
[57]/1/58/10957/0xdcb1e240/6668/NLEAF/[124]
[60]/1/61/10526/0xdcb156f0/6421/NLEAF/[204]
[66]/1/67/9091/0xdcb04050/6656/NLEAF/[124]
[67]/1/68/10357/0xdcb011e0/6445/NLEAF/[204]
[68]/1/69/11059/0xdcafe370/6602/NLEAF/[31]
[71]/1/72/10284/0xdcaf5820/6777/NLEAF/[204]
[73]/1/74/10061/0xdcaefb40/6349/NLEAF/[31]
[75]/1/76/9182/0xdcae9e60/6604/NLEAF/[204]
[76]/1/77/9500/0xdcae6ff0/6742/NLEAF/[204]
[77]/1/78/11564/0xdcae4180/6797/NLEAF/[204]
[78]/1/79/10481/0xdcae1310/6326/NLEAF/[204]
NLEAF表明等待會話,而LEAF_NW表明持鎖會話
SINGLE_NODE它不等待任何會話也不阻塞任何會話
而且如果state值為NLEAF,adjlist列會有值,這個值到底是什麼含義呢?
我們隨機挑出幾條相關記錄,找相它們的規律,分析adjlist的含義,可見NLEAF後面的adjlist等於持鎖會話sid+1,也就是說用adjlist-1就是持鎖會話的sid,直接可以找到持鎖會話的SID
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[9]/1/10/1/0xdcba9740/10574/NLEAF/[31]
Chain 1:
-------------------------------------------------------------------------------
Oracle session identified by:
{
instance: 1 (guowang.guowang)
os id: 10574
process id: 10, oracle@seconary (DBW0)
session id: 10
session serial #: 1
}
中間略
and is blocked by
=> Oracle session identified by:
{
instance: 1 (guowang.guowang)
os id: 6664
process id: 91, oracle@seconary (J063)
session id: 32 --即為adjlist+1
session serial #: 9465
[43]/1/44/11098/0xdcb46c60/6785/NLEAF/[204]
Chain 16:
-------------------------------------------------------------------------------
Oracle session identified by:
{
instance: 1 (guowang.guowang)
os id: 6785
process id: 174, oracle@seconary (J144)
session id: 44
session serial #: 11098
}
is waiting for 'buffer busy waits' with wait info:
{
p1: 'file#'=0x1
p2: 'block#'=0x15ab9
p3: 'class#'=0x1
time in wait: 0.013613 sec
timeout after: never
wait id: 56
blocking: 0 sessions
current sql: <none>
中間略
and is blocked by 'instance: 1, os id: 6439, session id: 205', --即為adjlist+1
[57]/1/58/10957/0xdcb1e240/6668/NLEAF/[124]
Chain 4:
-------------------------------------------------------------------------------
Oracle session identified by:
{
instance: 1 (guowang.guowang)
os id: 6668
process id: 98, oracle@seconary (J070)
session id: 58
session serial #: 10957
}
中間略
and is blocked by
=> Oracle session identified by:
{
instance: 1 (guowang.guowang)
os id: 6648
process id: 80, oracle@seconary (J052)
session id: 125 ----即為adjlist+1
session serial #: 10219
}
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9240380/viewspace-1824654/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 使用oradebug dump hanganalyze分析oracle hang系列一Oracle
- 使用oradebug dump hanganalyze 分析oracle hang系列三Oracle
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列四Oracle
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列五Oracle
- 基於oracle 10.2.0.1 rac使用oradebug dump hanganalyze 分析oracle hang系列六Oracle
- oradebug分析oracle hangOracle
- Oracle使用hanganalyze 命令分析資料庫hang【轉】Oracle資料庫
- 【Oracle】使用hanganalyze 命令分析資料庫hang【轉】Oracle資料庫
- oracle資料庫hang住分析工具Hanganalyze使用總結Oracle資料庫
- 在oracle10g及oracle11g使用oradebug生成systemstate dump檔案系列二Oracle
- oradebug分析oracle hang或慢_sqlplus_prelimOracleSQL
- 轉貼_Oradebug hanganalyze分析library cache等待
- Oracle Hang分析Oracle
- 使用HangFG進行Oracle Hang分析Oracle
- [oradebug命令學習4]HANGANALYZE
- Oradebug使用淺談--生成Hang或Locking問題分析檔案
- oracledebug hanganalyze分析會話等待及儲存過程hangOracle會話儲存過程
- 使用HANGANALYZE跟蹤檔案診例項hang問題
- 資料庫Hang住怎麼辦 - HANGANALYZE資料庫
- oradebug工具使用系列一
- oradebug處理DB hang情況
- zt_使用oradebug dump errorstack 3分析cursor遊標各狀態Error
- Oracle hanganalyzeOracle
- 使用AWK分析Oracle系統鎖定、Hang狀態Oracle
- 資料庫Hang住怎麼辦 - HANGANALYZE[final]資料庫
- oracle oradebug使用詳解Oracle
- 使用Oradebug修改Oracle SCNOracle
- About Oracle HanganalyzeOracle
- 常用的DUMP語句ORADEBUG語法
- 使用oradebug dump processstate 來診斷enq: TX - row lock contentionENQ
- Oracle oradebug 命令 使用說明Oracle
- Oracle oradebug命令使用說明Oracle
- hanganalyze分析會話阻塞會話
- 使用Visual Studio分析dump
- 由研究oracle rac lms程式引發10708 event及oradebug dump bufferOracle
- Oracle Hang AnalysisOracle
- 利用hanganalyz/systemstate dump診斷資料庫hang資料庫
- ORACLE EVENT && ORADEBUGOracle