systemstat dump学习整理

      --前记 
       前俩天客户有个oracle 测试库hang住的问题，任谁也无法登陆进数据库，trace日志又一直不停的刷新错误，因为登不进去，做不了任何的操作和库内查询，最终依靠强制重启了事。事后查资料，觉得当时应该通过 systemstate dump获取相关信息以便于进行分析，使得定位问题能够得到更强有力的数据支撑，可惜自己处理棘手问题经验尚浅，没有及时想到这些。
       通过这件事发现自己有几点没有做好：
                 1、重启前应该先收集AWR报告；
                  2、trace日志没有做备份到其他地方就清理掉了（空间目录100%了）;
                  3、在无法正常通过sqlplus访问的情况下，应该采用oradebug;
       为了以后的得心应手，唯有继续努力学习、试验、实战提升自己。
      --正文
       转回来说systemstat dump,  当数据库出现严重的性能问题或者hang了的时候，我们非常需要通过systemstate dump来知道进程在做什么，在等待什么，谁是资源的持有者，谁阻塞了别人。在出现上述问题时，及时收集systemstate dump非常有助于问题原因的分析。
       正常情况下我们都是通过sqlplus / as sysdba的方式登陆数据库，但当系统已经很慢或 hang到无法连接时，通过这种方式不一定能登进去，这个时候需要用 sqlplus  -prelim / as sysdba  登录 -prelim能够在数据库hang住的情况下连接 数据库 ，但只能说是连接，并不代表能够做很多操作（比如执行SQL查询）。这种情况下，可能最有用的就是使用oradebug和关闭数据库。

    一、执行oradebug

     1.1、非rac结构

• 获取systeminfo

1. SQL>oradebug setmypid
2. SQL>oradebug unlimit;
   
3. SQL>oradebug dump systemstate 266;==>执行完毕后等1~2分钟
4. SQL>oradebug dump systemstate 266;
   
5. SQL>oradebug tracefile_name;==>这是生成的文件名

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

1. SQL>oradebug setmypid
   
2. SQL>oradebug unlimit;
   
3. SQL>oradebug dump hanganalyze 3==>执行完毕后等1~2分钟
4. SQL>oradebug dump hanganalyze 3
   
5. SQL>oradebug tracefile_name;==>这是生成的文件名

    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分钟

   二、systemstat dump 级别含义

1. 2: dump (不包括lock element)
   
2. 10: dump
   
3. 11: dump + global cache of RAC
   
4. 256: short stack （函数堆栈）
   
5. 258: 256+2 -->short stack +dump(不包括lock element)
   
6. 266: 256+10 -->short stack+ dump
   
7. 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。

参考文档：1、https://blogs.oracle.com/Database4CN/entry/systemstate_dump_%E4%BB%8B%E7%BB%8D
                   2、How to Collect Diagnostics for Database Hanging Issues (文档 ID 452358.1)

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29319055/viewspace-2077769/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29319055/viewspace-2077769/