這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)systemstate dump是什么意思,文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
當(dāng)數(shù)據(jù)庫出現(xiàn)嚴重的性能問題或者hang了的時候,我們非常需要通過systemstate dump來知道進程在做什么,在等待什么,誰是資源的持有者,誰阻塞了別人。在出現(xiàn)上述問題時,及時收集systemstate dump非常有助于問題原因的分析。
在一些情況下,數(shù)據(jù)庫會自動生成systemstate dump, 比如出現(xiàn)了“WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK”。
systemstate dump大部分時候需要手工生成,具體的命令為:
如果連接很多,比如幾千個連接,那么生成dump可能需要幾十分鐘,而且會占用幾百M磁盤空間)
1. 用sysdba登錄到數(shù)據(jù)庫上:
$sqlplus / as sysdba
或者
$sqlplus -prelim / as sysdba <==當(dāng)數(shù)據(jù)庫已經(jīng)很慢或者hang到無法連接
SQL>oradebug setmypid
SQL>oradebug unlimit;
SQL>oradebug dump systemstate 266;
等1~2分鐘
SQL>oradebug dump systemstate 266;
等1~2分鐘
SQL>oradebug dump systemstate 266;
SQL>oradebug tracefile_name;==>這是生成的文件名
2. 通常除了systemstate dump,最好同時生成hang analyze來直觀地了解數(shù)據(jù)庫進程間的等待關(guān)系。
$sqlplus / as sysdba
或者
$sqlplus -prelim / as sysdba <==當(dāng)數(shù)據(jù)庫已經(jīng)很慢或者hang到無法連接
SQL>oradebug setmypid
SQL>oradebug unlimit;
SQL>oradebug dump hanganalyze 3
等1~2分鐘
SQL>oradebug dump hanganalyze 3
等1~2分鐘
SQL>oradebug dump hanganalyze 3
SQL>oradebug tracefile_name;==>這是生成的文件名
對于RAC數(shù)據(jù)庫,需要各個實例在同一時間的systemstate dump,那么登錄到任意一個實例(無需在所有實例執(zhí)行):
$sqlplus / as sysdba
或者
$sqlplus -prelim / as sysdba <==當(dāng)數(shù)據(jù)庫已經(jīng)很慢或者hang到無法連接
SQL>oradebug setmypid
SQL>oradebug unlimit
SQL>oradebug -g all dump systemstate 266 <==-g all 表示針對所有實例生成dump
等1~2分鐘
SQL>oradebug -g all dump systemstate 266
等1~2分鐘
SQL>oradebug -g all dump systemstate 266
在RAC上生成hang analyze:
SQL>oradebug setmypid
SQL>oradebug unlimit
SQL>oradebug -g all hanganalyze 3
等1~2分鐘
SQL>oradebug -g all hanganalyze 3
等1~2分鐘
SQL>oradebug -g all hanganalyze 3
上面的命令執(zhí)行后會在每個實例都生成systemstate dump,生成的信息放到了每個實例的backgroud_dump_dest下的diag trace文件中。
上面的這些命令執(zhí)行三次是為了比較進程的變化情況,查看是真的hang了,還是很慢。
systemstate dump有多個級別:
2: dump (不包括lock element)
10: dump
11: dump + global cache of RAC
256: short stack (函數(shù)堆棧)
258: 256+2 -->short stack +dump(不包括lock element)
266: 256+10 -->short stack+ dump
267: 256+11 -->short stack+ dump + global cache of RAC
level 11和 267會 dump global cache, 會生成較大的trace 文件,一般情況下不推薦。
一般情況下,如果進程不是太多,推薦用266,因為這樣可以dump出來進程的函數(shù)堆棧,可以用來分析進程在執(zhí)行什么操作。
但是生成short stack比較耗時,如果進程非常多,比如2000個進程,那么可能耗時30分鐘以上。這種情況下,可以生成level 10 或者 level 258, level 258 比 level 10會多收集short short stack, 但比level 10少收集一些lock element data.
另外對于RAC系統(tǒng),請關(guān)注Bug 11800959 - A SYSTEMSTATE dump with level >= 10 in RAC dumps huge BUSY GLOBAL CACHE ELEMENTS - can hang/crash instances (Doc ID 11800959.8)。這個Bug在11.2.0.3上被修復(fù),對于<=11.2.0.2的RAC,當(dāng)系統(tǒng)中的lock element 很多的時候,如果執(zhí)行l(wèi)evel 10、266或者 267的systemstate dump時,可能會導(dǎo)致數(shù)據(jù)庫hang或者crash,這種情況下可以采用level 258。
下面是生成systemstate dump的測試,用來查看每個level占用的空間:
這個例子中有37個進程:
-rw-r----- 1 oracle oinstall 72721 Aug 31 21:50 rac10g2_ora_31092.trc==>256 (short stack, 每個進程2K)
-rw-r----- 1 oracle oinstall 2724863 Aug 31 21:52 rac10g2_ora_31654.trc==>10 (dump,每個進程72K )
-rw-r----- 1 oracle oinstall 2731935 Aug 31 21:53 rac10g2_ora_32214.trc==>266 (dump + short stack ,每個進程72K)
RAC:
-rw-r----- 1 oracle oinstall 55873057 Aug 31 21:49 rac10g2_ora_30658.trc ==>11 (dump+global cache,每個進程1.4M)
-rw-r----- 1 oracle oinstall 55879249 Aug 31 21:48 rac10g2_ora_28615.trc ==>267 (dump+global cache+short stack,每個進程1.4M)
所以,可以看出如果dump global cache(level 11和267,那么占用的空間比其他級別大很多)。
上述就是小編為大家分享的systemstate dump是什么意思了,如果剛好有類似的疑惑,不妨參照上述分析進行理解。如果想知道更多相關(guān)知識,歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道。
網(wǎng)頁題目:systemstatedump是什么意思-創(chuàng)新互聯(lián)
鏈接URL:http://m.newbst.com/article24/ccjije.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供Google、微信公眾號、企業(yè)網(wǎng)站制作、網(wǎng)站營銷、品牌網(wǎng)站制作、定制開發(fā)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容