共計 2868 個字符，預計需要花費 8 分鐘才能閱讀完成。
這期內容當中丸趣 TV 小編將會給大家帶來有關 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，那么占用的空間比其他級別大很多）。
上述就是丸趣 TV 小編為大家分享的 systemstate dump 是什么意思了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注丸趣 TV 行業資訊頻道。
