通过AWR报告处理故障一次心得

故障现象
5:00-5:05期间，负载突然上升，随机查询进程发现来自192.168.30.69服务器
 
 
     
5:05-5:10期间，把192.168.130.69应用重启后，负载在5分钟之内恢复正常 
 




AWR报告信息如下
1．并发有增加


2．硬解析很多
 

3．整个15分钟期间的CPU使用率并不高（因为负载一上来就马上去关闭应用了，所以负载满核的时候大概就3分钟左右，CPU核数16 *4*60=2880秒左右，比DB TIME小一点）


4．两个SQL的CPU和其他SQL的CPU不是一个数量级的，差距10倍以上（195秒不到2880秒的十分之一） 


5．某表的逻辑读的占用比特别突出
 




分析
1． 通过以上AWR的信息，第一印象就是感觉硬解析引起的大量等待引起的CPU暴涨，查询下来也确实发现太多没有绑定变量的SQL，而且还发现逻辑读高的表UF_KQ_HRANALYZE_DT2没有绑定变量的SQL就达500多条。自以为找到了原因，通知开发去绑定变量（从DBA的角度看，一般不建议改参数cursor_sharing值，怕引发其他问题）。
2． 谁知第二天负载又开始上来，不过不是5分钟内暴涨，而是爬升（30分钟内从30%达到100%状态），期间数据库连上去可以抓取耗CPU百分百进程SPID对应的SQL了（昨天暴涨，数据库都连不上），发现SQL就是昨天AWR报告里面的那段insert的SQL，细查下来发现insert那段就是share_fordoc存储过程里面的一部分。再抓取几分钟内的AWR报告（显示insert居然78分钟都没有跑完），AWR报告中TOP SQL和抓取CPU百分百进程SPID对应的SQL一致。就是insert那段SQL慢导致整个存储过程慢，insert慢要么是insert的数据量太大或IO太慢，要么是insert后面的select太慢，具体查下来发现insert后面的select有死循环，至此找到原因，通知开发修改程序，彻底搞定。
 
抓取SPID对应的SQL的语句如下
select s.sid,s.serial#,p.spid,s.terminal,s.LOGON_TIME,s.status,s.PROGRAM,s.CLIENT_IDENTIFIER,s.machine,s.action,s.PROCESS "客户端机器进程号",s.osuser from v$session s,v$process p where  s.paddr=p.addr and p.spid=XX

select username,sid,SERIAL#,LOGON_TIME,status,PROGRAM,CLIENT_IDENTIFIER,machine,action,PROCESS "客户端机器进程号",osuser,sql_text from v$session a,v$sqltext_with_newlines b

  where DECODE(a.sql_hash_value, 0, prev_hash_value, sql_hash_value)=b.hash_value and a.sid=&sid order by piece;



总结
1． 数据库出现性能问题，一般都在三个地方，io，内存，cpu，这三个又是息息相关的，当io负载增大时，肯定需要更多的内存来存放，同时也需要cpu花费更多的时间来过滤这些数据，相反，cpu时间花费多的话，有可能 是解析sql语句，也可能是大量逻辑读过滤太多的数据，到不一定是和io或内存有关系
2． 有的时候等待事件是最好的入手点，但是引发等待事件的原因有很多，遇到突然异常的情况下，最简单粗暴的方法还是去看TOP SQL，看哪些SQL特别突出
3． 出现异常苗头时，一定要及时去创建快照，抓取短暂的5分钟或10分钟都可以，查看这几分钟内的AWR基本都可以定位到故障。一旦数据库hang住了，1小时的默认自动创建快照动作都不会执行的，这样后续故障现象的一手资料都会拿不到
exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

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

转载于:http://blog.itpub.net/30126024/viewspace-2136914/