如何進行oradebug診斷系統問題的分析

如何進行oradebug診斷系統問題的分析，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

oracle hanganalyze
hanganalyze有如下幾種level：
  10    Dump all processes (IGN state)
   5     Level 4 + Dump all processes involved inwait chains (NLEAF state)
   4     Level3 + Dump leaf nodes (blockers) in wait chains(LEAF,LEAF_NW,IGN_DMP state)
   3     Level2 + Dump only processes thought to be in a hang (IN_HANG state)
   1-2   Only HANGANALYZE output, no process dump at all
從上面的信息看,在進行hanganalyzedump時有多種級別的level可以選擇，那么如何選擇level？
一般來講,不建議使用level 3以上的操作,因為產生的trace可能會很大,尤其是大型的OLTP系統;
另外一般數據庫hang住時可能系統壓力都巨大,所以再產生很大的trace可能導致問題更加嚴重。
systemstate


    systemstate dump級別簡介：
    1. 級別2:dump(不包括lock element)
    2. 級別10:dump
    3. 級別11:dump+global cache of rac
    4. 級別256:short stack（函數堆棧）
    5. 級別258:級別256+級別2
    6. 級別266:級別256+級別10
    7. 級別267:級別256+級別11
processstate

1. 級別11和級別267會dump global cache,會產生較大的trace 文件，一般不推薦。
2.  一般情況下，如果進程不是太多，建議用256，因為這樣可以dump出來進程的函數堆棧，可以用來分析進程在執行什么操作，但是生成short stack比較耗時，如果進程非常多，比如2000個進程，那么可能耗時30分鐘以上。這種情況下，可以生成level 10 或者 level 258， level 258  比 level 10會多收集short short stack, 但比level 10少收集一些lock element data。
3. 對于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 25


使用oradebug命令

       ORADEBUG setmypid
       ORADEBUG setinst all
       ORADEBUG -g def hanganalyze <level>       —針對rac的用法
     對于單實例，我們通常進行如下操作即可:
       oradebug setmypid
       oradebug hanganalyze 3
   其次在做hang分析的時候,建議同時做一個systemstatedump或針對個別的process進行processstatedump,如下：

     ---systemstate dump

        oradebug  setmypid

        oradebug  unlimit

        oradebug  dump systemstate  level 2;

        oradebug  close_trace

        oradebug  tracefile_name

    ---processstatedump

         oradebug  setospid xxxx

         oradebug  dump processstate level 3;

         oradebug  close_trace

         oradebug  tracefile_name

我們知道當一個數據庫hang住時,最頭痛的問題是無法登陸數據，也就無法進行故障的處理,因此很多人只能通過重啟
操作系統來講解決問題，其實從Oracle 10g開始,Oracle提供了prelim的登陸方式，如下:

    sqlplus -prelim / as sysdba 

       oradebug setospid <process ID>  

       oradebug unlimit

       oradebug dump systemstate 10

關于如何進行oradebug診斷系統問題的分析問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。