ITPub博客

首页 > 数据库 > Oracle > systemstate dump

systemstate dump

原创 Oracle 作者:qiuyb 时间:2013-01-14 11:12:23 0 删除 编辑

原文作者JaneZhang(张建英)

当数据库出现严重的性能问题或者hang了的时候,我们非常需要通过systemstate dump来知道进程在做什么,在等待什么,谁是资源的持有者,谁阻塞了别人。在出现上述问题时,及时收集systemstate dump非常有助于问题原因的分析。在一些情况下,数据库会自动生成systemstate dump, 比如出现了"WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK"

[@more@]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,那么占用的空间比其他级别大很多)

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

全部评论
  • 博文量
    75
  • 访问量
    651509