systemstat dump学习整理 一、执行oradebug 二、systemstat dump 级别含义

      --前记 

      前俩天客户有个oracle测试库hang住的问题，任谁也无法登陆进数据库，trace日志又一直不停的刷新错误，因为登不进去，做不了任何的操作和库内查询，最终依靠强制重启了事。事后查资料，觉得当时应该通过systemstate dump获取相关信息以便于进行分析，使得定位问题能够得到更强有力的数据支撑，可惜自己处理棘手问题经验尚浅，没有及时想到这些。

       通过这件事发现自己有几点没有做好：

                 1、重启前应该先收集AWR报告；

                  2、trace日志没有做备份到其他地方就清理掉了（空间目录100%了）;

                  3、在无法正常通过sqlplus访问的情况下，应该采用oradebug;

       为了以后的得心应手，唯有继续努力学习、试验、实战提升自己。

      --正文

       转回来说systemstat dump, 当数据库出现严重的性能问题或者hang了的时候，我们非常需要通过systemstate dump来知道进程在做什么，在等待什么，谁是资源的持有者，谁阻塞了别人。在出现上述问题时，及时收集systemstate dump非常有助于问题原因的分析。

     1.1、非rac结构

获取systeminfo

SQL>oradebug setmypid

SQL>oradebug unlimit;

SQL>oradebug dump systemstate 266;==>执行完毕后等1~2分钟

SQL>oradebug dump systemstate 266;

SQL>oradebug tracefile_name;==>这是生成的文件名

获取hang analye            --通常除了systemstate dump，最好同时生成hang analyze来直观地了解数据库进程间的等待关系

SQL>oradebug dump hanganalyze 3==>执行完毕后等1~2分钟

SQL>oradebug dump hanganalyze 3

    1.2、rac结构

       下面的截图来自mos文档，10g和11g稍稍有些不同，11g中有bug和无bug也有点小区别，在实际的生产环境中，其实dba很难记住每个库都修复了哪些bug，所以在实际操作中11.2.0.3及其以上的版本中，可以执行rac with fixes的命令，因为这俩个bug都在11.2.0.3中修复。（有在11.2.0.2.4的psu中修复的，也就是说打了这个psu的就可以执行rac with fixes命令，不过生产中很难记的这么细，记个大版本就可以了）。

    上面的命令执行后会在每个实例都生成systemstate dump，生成的信息放到了每个实例的diag trace文件中，记的每执行完一个oradebug命令后等待1-2分钟

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。

                  2、How to Collect Diagnostics for Database Hanging Issues (文档 ID 452358.1)