- 当数据库出现严重的性能问题或者hang了的时候，我们非常需要通过systemstate dump来知道进程在做什么，在等待什么，谁是资源的持有者，谁阻塞了别人。
在出现上述问题时，及时收集systemstate dump非常有助于问题原因的分析。
在一些情况下，数据库会自动生成systemstate dump, 比如出现了“WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK”。
systemstate dump大部分时候需要手工生成，具体的命令为：
1 systemstate dump
1.1 如果连接很多，比如几千个连接，那么生成dump可能需要几十分钟，而且会占用几百M磁盘空间）
a. 用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;==>这是生成的文件名b. 通常除了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;==>这是生成的文件名c. 对于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了，还是很慢。
1.2 在我们使用prelim参数仍然无法登录数据库时，可以使用gdb调试后台进程方式生成systemstate dump，例子如下：
$ ps -ef|grep pmon
oracle 28288 10 04:42 ?00:00:00 ora_pmon_R11202
$ gdb $ORACLE_HOME/bin/oracle 28288
然后查看这个进程的trace文件：
$ more R11202_pmon_28288.trc1.3 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 RAClevel 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.4 下面是生成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，那么占用的空间比其他级别大很多）。
2 hanganalyze
2.1为什么要使用hanganalyze
- Oracle 数据库“真的”hang住了，可以理解为数据库内部发生死锁。因为普通的DML死锁，oracle服务器会自动监测他们的依赖关系，并回滚其中一个操作，终止这种相互等待的局面。而当这种死锁发生在争夺内核级别的资源（比如说是pins或latches）时，Oracle并不能自动的监测并处理这种死锁。
- 其实很多时候数据库并没有hang住，而只是由于数据库的性能问题，处理的时间比较长而已。
- Hanganalyze工具使用内核调用检测会话在等待什么资源，报告出占有者和等待者的相互关系。另外，它还会将一些比较”interesting”的进程状态dump出来，这个取决于我们使用hanganalyze的分析级别。
- hanganalyze工具从oracle8i第二版开始提供，到9i增强了诊断RAC环境下的“集群范围”的信息，这意味着它将会报告出整个集群下的所有会话的信息。
2.2目前有三种使用hanganalyze的方法:
- 一种是会话级别的：
SQL>ALTER SESSION SET EVENTS 'immediate trace name HANGANALYZE level ';
- 一种是实例级别:
SQL>ORADEBUG hanganalyze
- 一种是集群范围的：
SQL>ORADEBUG setmypid
SQL>ORADEBUG setinst all
SQL>ORADEBUG -g def hanganalyze
2.3各个level的含义如下：
1-2:只有hanganalyze输出，不dump任何进程
3：Level2+Dump出在IN_HANG状态的进程
4：Level3+Dump出在等待链里面的blockers(状态为LEAF/LEAF_NW/IGN_DMP)
5：Level4+Dump出所有在等待链中的进程（状态为NLEAF）
Oracle官方建议不要超过level 3，一般level 3也能够解决问题，超过level 3会给系统带来额外负担。
3 借助ass109.awk工具分析dump：
[root@dgvxl6632 ~]# cd /tmp
[root@dgvxl6632 tmp]# ls
ass109.awk disk hsperfdata_oracle iostat.log iostat.tmp systemd-private-4719ef2d627448c294fda57b7b1768ad-chronyd.service-WFCoLs
[root@dgvxl6632 tmp]# awk -f ass109.awk /data01/u01/app/oracle/diag/rdbms/orcls1/orcl/trace/orcl_ora_8556.trc
Starting Systemstate 1
.............................................
Ass.Awk Version 1.0.9 - Processing /data01/u01/app/oracle/diag/rdbms/orcls1/orcl/trace/orcl_ora_8556.trc
System State 1
--~~~~~~~~~~~~~~~~
1:
2: 0: waiting for 'pmon timer'
3: 0: waiting for 'rdbms ipc message'
4: 0: waiting for 'VKTM Logical Idle Wait'
5: 0: waiting for 'rdbms ipc message'
6: 0: waiting for 'DIAG idle wait'
7: 0: waiting for 'rdbms ipc message'
8: 0: waiting for 'DIAG idle wait'
9: 0: waiting for 'rdbms ipc message'
10: 0: waiting for 'rdbms ipc message'
11: 0: waiting for 'rdbms ipc message'
12: 0: waiting for 'rdbms ipc message'
13: 0: waiting for 'smon timer'
14: 0: waiting for 'rdbms ipc message'
15: 0: waiting for 'rdbms ipc message'
16: 0: waiting for 'rdbms ipc message'
17:
18: 0: waiting for 'EMON slave idle wait'
19: 0: waiting for 'SQL*Net message from client'
20: 0: waiting for 'LNS ASYNC end of log'
21:
22: 0: waiting for 'rdbms ipc message'
23: 0: waiting for 'Streams AQ: qmn coordinator idle wait'
24: 0: waiting for 'PL/SQL lock timer'
25: 0: waiting for 'rdbms ipc message'
26: 0: waiting for 'SQL*Net message from client'
27: 0: waiting for 'SQL*Net message from client'
28: 0: waiting for 'Streams AQ: qmn slave idle wait'
29: 0: waiting for 'SQL*Net message from client'
30: 9: waited for 'Streams AQ: waiting for time management or cleanup tasks'
31: 0: waiting for 'Space Manager: slave idle wait'
33: 0: waiting for 'JOX Jit Process Sleep'
34: 0: waiting for 'enq: TX - row lock contention'[Enqueue TX-00090004-0001A348]
35:
36: 0: waiting for 'SQL*Net message from client'
37: 0: waiting for 'Streams AQ: emn coordinator idle wait'
40: 0: waiting for 'rdbms ipc message'
41: 0: waiting for 'rdbms ipc message'
42: 0: waiting for 'rdbms ipc message'
43: 0: waiting for 'rdbms ipc message'
49: 0: waiting for 'EMON slave idle wait'
50: 0: waiting for 'EMON slave idle wait'
51: 0: waiting for 'EMON slave idle wait'
52: 0: waiting for 'EMON slave idle wait'
58: 0: waiting for 'SQL*Net message from client'
Blockers
--~~~~~~~~
Above is a list of all the processes. If they are waiting for a resource
then it will be given in square brackets. Below is a summary of the
waited upon resources, together with the holder of that resource.
Notes:
--~~~~~
o A process id of '???' implies that the holder was not found in the
systemstate.
Resource Holder State
Enqueue TX-00090004-0001A348 19: 0: waiting for 'SQL*Net message from client'
Object Names
--~~~~~~~~~~~~
Enqueue TX-00090004-0001A348
36278 Lines Processed.
[root@dgvxl6632 tmp]#
** (Enqueue TX-00090004-0001A348 19: 0)是v$process里的pid号，根据pid可查Session信息：**
select s.sid,s.serial#,s.username,s.machine,s.type,s.status,s.event,P.SPID,p.pid from v$session s,v$process p where s.paddr=P.addr and pid=19;
4 参考：
systemstate-dump：https://blogs.oracle.com/database4cn/post/systemstate-dump
