说明
在很多情况下，当数据库发生性能问题的时候，我们不可能长时间的在生产系统上进行问题分析，毕竟第一时间恢复业务才是最重要的。而system state dump和hang analyze给我们提供了事后分析问题所需的所有信息。也可以通过dba_hist_active_sess_history的数据来分析数据库历史性能问题。
收集信息
一：systemstate hang analyze
当数据库出现严重的性能问题或者hang住的时候，及时收集systemstate dump非常有助于问题原因的分析。通过systemstate dump可以知道进程在做什么，在等待什么，谁是资源的持有者，谁阻塞了别人等详细信息。
1：非RAC：
1：登陆数据库
2：收集systemstate
3：收集hang analyze
2：RAC:
1：登陆数据库
2：收集systemstate
3：收集hang analyze
上面的命令执行后会在每个实例都生成systemstate dump。
说明
level 11和 267会 dump global cache, 会生成较大的trace 文件，一般情况下不推荐，一般情况下，如果进程不是太多，推荐用266。
二：dba_hist_active_sess_history
在Oracle 10G中，我们引入了AWR和ASH采样机制，有一个视图gv$active_session_history会每秒钟将数据库所有节点的Active Session采样一次，而dba_hist_active_sess_history则会将gv$active_session_history里的数据每10秒采样一次并持久化保存。基于这个特征，我们可以通过分析dba_hist_active_sess_history的Session采样情况，来定位问题发生的准确时间范围，并且可以观察每个采样点的top event和top holder。
1：Dump出问题期间的ASH数据：
为了不影响生产系统，我们可以将出现问题期间的ASH数据导出来在测试机上分析。基于dba_hist_active_sess_history创建一个新表problem_ash。代码如下：
导出数据
导入数据
2：验证导出的ASH时间范围
3：确认问题发生的精确时间范围
4：常用语句：
附录：
利用操作系统调试工具收集信息
当数据库无法连接的时候，我们可以通过操作系统的调试工具进行systemstate等信息的收集。说明如下：
1：找到oracle程序的操作系统进程号
2：运行gdb调试工具
3：打印信息
说明：其中10代表运行级别，级别详细说明见上文。
4：找到trace文件在user_dump_dest参数指向的目录下.
格式为_ora_ .trc
例如：orcl_ora_3846.trc
其他操作系统操作步骤类似。
