生產環境 direct path read 與log file sync等待事件問題處理
1. 2018-09-26 前7天awr報告(此期間 oracle 使用率為 4,022.34/6,179.76/24=2.71%)
由此看出最顯著問題是 log file sync 等待事件，查看後臺等待事件伴隨著 log file parallel write 等待事件也相對較高，初步判斷此數據庫操作系統I/O使用率較高，通過windows 任務管理器 查看 此時 IO 為100k/s-2M/s之間 性能監視器中 oracle 進程平均讀字節為4M/s（包含網絡）寫字節僅10-30K/s 磁盤利用率在50%以上
Wait Event "log file sync"
2.2018-10-09 23:00 進行數據庫服務器重啟操作
3.2018-10-10 9:00 獲取2018-10-10 00:00 2018-10-10 07:00 awr報告(此期間oracle使用率為 866.78/480.61/24=7.51%）
此時：
此時top5 等待事件中依然是 log file sync 占據較高，但是出現了direct path read 等待事件 通過windows 任務管理器 查看 此時 IO 為80M/s-120M/s之間 性能監視器中 oracle 進程平均讀字節為4M/s（包含網絡）寫字節僅10-30K/s 磁盤利用率在100%
傳送門：Wait Event "direct path read "
1>問題分析
1.1) 一般來說，數據塊BLOCK(即ORACLE的最小存儲單元)總是先由後臺服務器進程緩沖至buffer cache，而後才被服務器進程獲取。但對於一些大表，將其緩沖至buffer cache勢必會將buffer cache中的許多其它對象擠出，即ageing out。為了避免這一情況，oracle產生了direct path read,即不需要緩沖到緩存區，而是直接由服務器進程從磁盤獲取。
1.2)通過查看segment by direct physical reads獲取哪些對象direct path read等待高
1.3）查出發現AUD$對象物理讀占了整個物理I/O的98.84%的資源，我們再數據庫中查看 table 對象AUD$ (查找資料發現此對象是oracle 審計功能的底層視圖,記錄了所有用戶對oracle操作的信息)
1.4）那麽我們再研究下在AUD$對象上進行了什麽操作導致此嚴重等待（查看sql order by reads）
1.5）分析發現邏輯讀與物理讀占比異常的均為 d15cdr0zt3vtp 獲取此sql的詳細信息，不難發現此sql就是AUD$對象
SELECT TO_CHAR(current_timestamp AT TIME ZONE ‘GMT‘,
‘YYYY-MM-DD HH24:MI:SS TZD‘) AS curr_timestamp,
COUNT(username) AS failed_count
FROM sys.dba_audit_session
WHERE returncode != 0
AND TO_CHAR(timestamp, ‘YYYY-MM-DD HH24:MI:SS‘) >=
TO_CHAR(current_timestamp - TO_DSINTERVAL(‘0 0:30:00‘),
‘YYYY-MM-DD HH24:MI:SS‘)
1.6）在此sql的wehere條件中有 “!=”、“>=”等限制條件，很可能引起全表掃描，再查詢一下AUD$對象的數據量，此對象共計342812M/1024=334G (此表中有3億+條數據)
SELECT *
FROM (SELECT SEGMENT_NAME, SUM(BYTES) / 1024 / 1024 MB
FROM DBA_SEGMENTS
GROUP BY SEGMENT_NAME
ORDER BY 2 DESC)
WHERE SEGMENT_NAME=‘AUD$‘
1.7)確認此審計數據沒用後可定期進行清理 （ truncate table sys.aud$ ） （操作時間 2018-10-11 10：21） truncate 後 磁盤I/O從100M+/s 降至1M-/s
1. oracle 11gr2的審計功能默認是打開的，但是由於默認狀況下是會審計所有賬號的登入和登出的，這就使得審計日誌的數據量非常大.
2.可以取消登陸與登出審計來使審計日誌數據增長變慢
SQL> noaudit connect;
1.8）
獲取2018-10-11 11點到13點之間的awr報告Top 5等待事件，我們發現direct path read 等待事件已經消失了，並且 log file sync 等待事件顯著下降 說明log file sync等待事件是由之前的全表掃描導致I/O緊張引起的
此圖等待較高的還有 Disk file operations I/O 等待事件，那麽我們來了解一下此等待事件
傳送門：Wait Event "Disk file operations I/O"
至此，log file sync 等待事件是由於硬件性能保持在9ms等待；同時再此記錄該庫log file sync、Disk file operations I/O 、log file parallel write等待事件時間分布表，便於後期對比觀察性能是否提升
log file sync
select event, wait_time_milli,wait_count, wait_count/(select sum (wait_count) from v$event_histogram where event = ‘log file sync‘ ) from v$event_histogram where event = ‘log file sync‘;
log file parallel write
select event, wait_time_milli,wait_count, wait_count/(select sum (wait_count) from v$event_histogram where event = ‘log file parallel write‘ ) from v$event_histogram where event = ‘log file parallel write‘;
Disk file operations I/O
select event, wait_time_milli,wait_count, wait_count/(select sum (wait_count) from v$event_histogram where event = ‘Disk file operations I/O‘ ) from v$event_histogram where event = ‘Disk file operations I/O‘;
Direct Path Read
select event, wait_time_milli,wait_count, wait_count/(select sum (wait_count) from v$event_histogram where event = ‘direct path read‘ ) from v$event_histogram where event = ‘direct path read‘;
via:
https://blog.csdn.net/haojiubujian920416/article/details/81222523
https://blog.csdn.net/mjj291268154/article/details/49935205
https://www.linuxidc.com/Linux/2015-09/122732.htm
https://www.cnblogs.com/6yuhang/p/5923914.html
https://blog.csdn.net/ljunjie82/article/details/52051066
生產環境 direct path read 與log file sync等待事件問題處理