说明
在很多情况下,当数据库发生性能问题的时候,我们不可能长时间的在生产系统上进行问题分析,毕竟第一时间恢复业务才是最重要的。而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
其他操作系统操作步骤类似。