天天看點

systemstat dump學習整理     一、執行oradebug    二、systemstat dump 級别含義

      --前記 

      前倆天客戶有個oracle測試庫hang住的問題,任誰也無法登陸進資料庫,trace日志又一直不停的重新整理錯誤,因為登不進去,做不了任何的操作和庫内查詢,最終依靠強制重新開機了事。事後查資料,覺得當時應該通過systemstate dump擷取相關資訊以便于進行分析,使得定位問題能夠得到更強有力的資料支撐,可惜自己處理棘手問題經驗尚淺,沒有及時想到這些。

       通過這件事發現自己有幾點沒有做好:

                 1、重新開機前應該先收集AWR報告;

                  2、trace日志沒有做備份到其他地方就清理掉了(空間目錄100%了);

                  3、在無法正常通過sqlplus通路的情況下,應該采用oradebug;

       為了以後的得心應手,唯有繼續努力學習、試驗、實戰提升自己。

      --正文

       轉回來說systemstat dump, 當資料庫出現嚴重的性能問題或者hang了的時候,我們非常需要通過systemstate dump來知道程序在做什麼,在等待什麼,誰是資源的持有者,誰阻塞了别人。在出現上述問題時,及時收集systemstate dump非常有助于問題原因的分析。

     1.1、非rac結構

擷取systeminfo

SQL>oradebug setmypid

SQL>oradebug unlimit;

SQL>oradebug dump systemstate 266;==>執行完畢後等1~2分鐘

SQL>oradebug dump systemstate 266;

SQL>oradebug tracefile_name;==>這是生成的檔案名

擷取hang analye            --通常除了systemstate dump,最好同時生成hang analyze來直覺地了解資料庫程序間的等待關系

SQL>oradebug dump hanganalyze 3==>執行完畢後等1~2分鐘

SQL>oradebug dump hanganalyze 3

    1.2、rac結構

       下面的截圖來自mos文檔,10g和11g稍稍有些不同,11g中有bug和無bug也有點小差別,在實際的生産環境中,其實dba很難記住每個庫都修複了哪些bug,是以在實際操作中11.2.0.3及其以上的版本中,可以執行rac with fixes的指令,因為這倆個bug都在11.2.0.3中修複。(有在11.2.0.2.4的psu中修複的,也就是說打了這個psu的就可以執行rac with fixes指令,不過生産中很難記的這麼細,記個大版本就可以了)。

systemstat dump學習整理     一、執行oradebug    二、systemstat dump 級别含義

    上面的指令執行後會在每個執行個體都生成systemstate dump,生成的資訊放到了每個執行個體的diag trace檔案中,記的每執行完一個oradebug指令後等待1-2分鐘

2: dump (不包括lock element)

10: dump

11: dump + global cache of RAC

256: short stack (函數堆棧)

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出來程序的函數堆棧,可以用來分析程序在執行什麼操作。但是生成short stack比較耗時,如果程序非常多,比如2000個程序,那麼可能耗時30分鐘以上。這種情況下,可以生成level 10 或者 level 258, level 258 比 level 10會多收集short short stack, 但比level 10少收集一些lock element data.

        另外對于RAC系統,請關注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上被修複,對于<=11.2.0.2的RAC,當系統中的lock element 很多的時候,如果執行level 10、266或者 267的systemstate dump時,可能會導緻資料庫hang或者crash,這種情況下可以采用level 258。

                  2、How to Collect Diagnostics for Database Hanging Issues (文檔 ID 452358.1)