如何在数据库hang住时收集诊断信息

当数据库看起来hang住时，从数据库收集信息以确定hang住的根本原因很有用。 hang住的根本原因通常可以使用收集的诊断信息进行隔离和解决。

诊断“数据库hang住”问题需要什么？

数据库hang住的特点是有许多进程在等待其他一些活动完成。 通常情况下，有一个或多个阻挡器被卡住或者可能正在努力工作并且不能足够快地释放资源。 为了诊断这一点，需要以下诊断：

1. Hanganalyze 和 Systemstate Dumps
2. AWR/Statspack snapshots 报告
3. 最新的 RDA

如果是CDB环境，要确认是CDB级别的hang还是PDB级别的hang。如果是PDB级别的hang，只需要收集PDB的信息。如果无法确认，建议收集一下CDB的信息。

Dumps 和Traces文件

Hanganalyze 和 Systemstate Dumps

Hanganalyze和Systemstate dump在指定时间点提供有关数据库中进程的信息。

Hanganalyze提供有关hang住涉及的所有进程的信息，而systemstate提供有关数据库中所有进程的信息。

收集Hanganalyze 和 Systemstate Dumps

登陆系统
使用SQL*Plus 以 SYSDBA 连接数据库:

sqlplus '/ as sysdba'

如果在10gR2及更高版本中进行此连接时出现问题，则可以使用sqlplus "preliminary connection"：

sqlplus -prelim '/ as sysdba'

从11.2.0.2起，使用"sqlplus -prelim"登陆后，hanganalyze不再有内容输出，因为需要一个进程状态对象和一个会话状态对象。所以执行hanganalyze分析后，只是显示执行成功。如下示例：

SQL>  oradebug hanganalyze 3
Statement processed.

并且trace文件中会包含以下内容：

HANG ANALYSIS:

ERROR: Can not perform hang analysis dump without a process state object and a session state object.
( process=(nil), sess=(nil) )

非RAC下的Hanganalyze 和 Systemstate收集命令

有时，数据库实际上可能只是非常慢而且实际上并没有hang住。 因此，建议在获得2个hanganalyze和2个systemstate dump，以确定进程是否正在运行或是否“僵死”。

Hanganalyze

sqlplus '/ as sysdba'
oradebug setmypid
oradebug unlimit
oradebug hanganalyze 3
-- 等一分钟后再次执行hanganalyze分析
oradebug hanganalyze 3
oradebug tracefile_name
exit

Systemstate

sqlplus '/ as sysdba'
oradebug setmypid
oradebug unlimit
oradebug dump systemstate 266
oradebug dump systemstate 266
oradebug tracefile_name
exit

通常是hanganalyze和systemstate dump一起做：

sqlplus '/as sysdba'
oradebug setmypid
oradebug unlimt
oradebug hanganalyze 3
--等一分钟后再次执行hanganalyze分析
oradebug hanganalyze 3
oradebug dump systemstate 266
oradebug dump systemstate 266
oradebug tracefile_name

RAC下的Hanganalyze 和 Systemstate收集命令

在RAC环境，会在每个实例的diag trace目录下创建dump文件

RAC10G,使用setmypid

sqlplus '/as sysdba'
oradebug setmypid
oradebug unlimit
oradebug -g all hanganalyze 3
oradebug -g all hanganalyze 3
oradebug -g all dump systemstate 258
oradebug -g all dump systemstate 258

在RAC11G环境，因为有两个bug(bug 11800959 、bug 11827088)，导致执行hanganalyze和systemstate dump时，使用266、267级别时成本很高。所以在没有安装这两个补丁前，建议慎用。在11.2.0.3中补丁已被修复。

RAC11G,如果已经安装了上面的两个补丁：

sqlplus '/as sysdba'
oradebug setorapname reco
oradebug unlimit
oradebug -g all hanganalyze 3
oradebug -g all hanganalyze 3
oradebug -g all dump systemstate 266
oradebug -g all dump systemstate 266

RAC11G,如果没有安装了上面的两个补丁：

sqlplus '/ as sysdba'
oradebug setorapname reco
oradebug unlimit
oradebug -g all hanganalyze 3
oradebug -g all hanganalyze 3
oradebug -g all dump systemstate 258
oradebug -g all dump systemstate 258
exit

Hanganalyze和Systemstate级别的说明

Hanganalyze levels:

• Level 3:在11g以后，级别3还为hang chain中的相关进程收集一个短堆栈

Systemstate levels:

• Level 258 is a fast alternative but we’d lose some lock element data
• Level 267 can be used if additional buffer cache / lock element data is needed with an understanding of the cost

参考文档

MOS 452358.1