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指令，不過生産中很難記的這麼細，記個大版本就可以了）。

    上面的指令執行後會在每個執行個體都生成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)