Oracle 等待事件 “direct path read" 排查思路
下午接到客户通知,说监控发现一套RAC双节点以及standby 节点CPU使用率异常高,截图一看,双节点均大致在60-80%左右。赶紧排查,具体思路如下:
- 看到监控截图,第一时间抽取了两节点的AWR报告
直接查看了TOP5 发现 是 “direct path read” 占用51%的DB time
紧接着查看了 Segments by Direct Physical Reads,发现竟然是AUD$,这个审计视图,感觉不对劲,继续往下看。
select username "username", to_char(timestamp, 'DD-MON-YYYY HH24:MI:SS') "time_stamp",
action_name "statement", os_username "os_username", userhost "userhost", returncode||decode(returncode,
'1004', '-Wrong Connection', '1005', '-NULL Password', '1017', '-Wrong Password', '1045',
'-Insufficient Priviledge', '0', '-Login Accepted', '--') "returncode"
from sys.dba_audit_session where (sysdate - timestamp)*24 < 1 and returncode <> 0 order by timestamp
查看了物理读,发现了其中的SQL语句,是对dba_audit_session基表做的查询操作,很疑惑什么应用会用到审计视图的基表。
发现AUD$审计视图,达到1500w+数据,而此sql使用了运算符及“<>”等符号,导致索引失效,进行全表扫,从监控视图看,约每5分钟cpu飙高一次,第一反应怀疑是监控,继续往下进行排查。
根据AWR视图中的sql id查找v$session中的相关信息,并没有查到,继续查找了
dba_hist_sqlstat视图,一眼找到了问题所在,原来真是ZABBIX每五分钟进行数据抽取用到了
dbs_audit_session等审计视图。查到问题,告知了监控负责人。
解决后CPU使用率大幅下降。
结论:因为ZABBIX监控每5分钟会抽取数据库中的数据,从而使用到了AUD、dba_audit_session等审计视图基表,然而ZABBIX抽取数据的源SQL中使用了“<>”,“*”等符号及运算,造成索引失效,导致查询使用全表扫描,以致发生了间歇性CPU飙高的事件。
解决方法:
- 告知监控负责人,看能否优化监控抽取SQL
- 将AUD$,清空,使用truncate
- 停止ZABBIX对应的监控项。