systemstate dump是什么意思

這期內容當中小編將會給大家帶來有關systemstate dump是什么意思，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

        當數據庫出現嚴重的性能問題或者hang了的時候，我們非常需要通過systemstate dump來知道進程在做什么，在等待什么，誰是資源的持有者，誰阻塞了別人。在出現上述問題時，及時收集systemstate dump非常有助于問題原因的分析。

       在一些情況下，數據庫會自動生成systemstate dump, 比如出現了“WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK”。
        systemstate dump大部分時候需要手工生成，具體的命令為：

如果連接很多，比如幾千個連接，那么生成dump可能需要幾十分鐘，而且會占用幾百M磁盤空間）
1. 用sysdba登錄到數據庫上：
$sqlplus / as sysdba
或者
$sqlplus -prelim / as sysdba <==當數據庫已經很慢或者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來直觀地了解數據庫進程間的等待關系。

$sqlplus / as sysdba
或者
$sqlplus -prelim / as sysdba <==當數據庫已經很慢或者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數據庫，需要各個實例在同一時間的systemstate dump,那么登錄到任意一個實例（無需在所有實例執行）：

$sqlplus / as sysdba
或者
$sqlplus -prelim / as sysdba <==當數據庫已經很慢或者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

上面的命令執行后會在每個實例都生成systemstate dump，生成的信息放到了每個實例的backgroud_dump_dest下的diag trace文件中。

上面的這些命令執行三次是為了比較進程的變化情況，查看是真的hang了，還是很慢。

systemstate dump有多個級別：

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。

下面是生成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是什么意思了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。