当数据库出现严重的性能问题或者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，那么占用的空间比其他级别大很多）。


oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html