--前记
前俩天客户有个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和关闭数据库。
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分钟
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)
前俩天客户有个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
- 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 setmypid
- SQL>oradebug unlimit;
- SQL>oradebug dump hanganalyze 3==>执行完毕后等1~2分钟
- SQL>oradebug dump hanganalyze 3
- SQL>oradebug tracefile_name;==>这是生成的文件名
下面的截图来自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 级别含义
- 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
一般情况下，如果进程不是太多，推荐用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)
