一则 Oracle 等待事件 “direct path read" 排查思路

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对应的监控项。