systemstat dump學習整理

路途中的人2012發表於2016-08-04
      --前記 
      前倆天客戶有個oracle測試庫hang住的問題，任誰也無法登陸進資料庫，trace日誌又一直不停的重新整理錯誤，因為登不進去，做不了任何的操作和庫內查詢，最終依靠強制重啟了事。事後查資料，覺得當時應該透過systemstate dump獲取相關資訊以便於進行分析，使得定位問題能夠得到更強有力的資料支撐，可惜自己處理棘手問題經驗尚淺，沒有及時想到這些。
       透過這件事發現自己有幾點沒有做好：
                 1、重啟前應該先收集AWR報告；
                  2、trace日誌沒有做備份到其他地方就清理掉了（空間目錄100%了）;
                  3、在無法正常透過sqlplus訪問的情況下，應該採用oradebug;
       為了以後的得心應手，唯有繼續努力學習、試驗、實戰提升自己。
      --正文
       轉回來說systemstat dump, 當資料庫出現嚴重的效能問題或者hang了的時候，我們非常需要透過systemstate dump來知道程式在做什麼，在等待什麼，誰是資源的持有者，誰阻塞了別人。在出現上述問題時，及時收集systemstate dump非常有助於問題原因的分析。
       正常情況下我們都是透過sqlplus / as sysdba的方式登陸資料庫，但當系統已經很慢或 hang到無法連線時，透過這種方式不一定能登進去，這個時候需要用 sqlplus  -prelim / as sysdba  登入-prelim能夠在資料庫hang住的情況下連線，但只能說是連線，並不代表能夠做很多操作（比如執行SQL查詢）。這種情況下，可能最有用的就是使用oradebug和關閉資料庫。

    一、執行oradebug

     1.1、非rac結構
  • 獲取systeminfo
  1. SQL>oradebug setmypid
  2. SQL>oradebug unlimit;
  3. SQL>oradebug dump systemstate 266;==>執行完畢後等1~2分鐘
  4. SQL>oradebug dump systemstate 266;
  5. SQL>oradebug tracefile_name;==>這是生成的檔名
  • 獲取hang analye            --通常除了systemstate dump，最好同時生成hang analyze來直觀地瞭解資料庫程式間的等待關係
  1. SQL>oradebug setmypid
  2. SQL>oradebug unlimit;
  3. SQL>oradebug dump hanganalyze 3==>執行完畢後等1~2分鐘
  4. SQL>oradebug dump hanganalyze 3
  5. SQL>oradebug tracefile_name;==>這是生成的檔名
    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分鐘

   二、systemstat dump 級別含義

  1. 2: dump (不包括lock element)
  2. 10: dump
  3. 11: dump + global cache of RAC
  4. 256: short stack （函式堆疊）
  5. 258: 256+2 -->short stack +dump(不包括lock element)
  6. 266: 256+10 -->short stack+ dump
  7. 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。


參考文件：1、https://blogs.oracle.com/Database4CN/entry/systemstate_dump_%E4%BB%8B%E7%BB%8D
                  2、How to Collect Diagnostics for Database Hanging Issues (文件 ID 452358.1)

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29067253/viewspace-2122958/，如需轉載，請註明出處，否則將追究法律責任。

相關文章