Waiting Too Frequently for 'db file sequential read'

昨天有篇“db file sequential read”的介紹，還有一篇類似的：Resolving Issues Where Application Queries are Waiting Too Frequently for 'db file sequential read' Operations (文件 ID 1475825.1)

診斷“db file sequential read”的步驟：

簡述：

低效的SQL會引起不同節點間非常多的塊讀。

問題確認：

花費在本地資料庫的active時間非常明顯。

僅一些session，查詢或job變慢(不是整個資料庫)。

“db file sequential read”等待是整個DB time中佔比最大的元件。

“db file sequential read”等待操作不慢(IO的平均時間沒超過標準IO效能(例如少於20毫秒))。

等待“db file sequential read”操作太頻繁的應用查詢

等待“db file sequential read”事件指的是一個session正在等待一次從磁碟讀到記憶體的單塊讀以滿足查詢的要求。

假設完成一次IO操作的平均時間是正常的(例如單次IO花費時間少於20毫秒)，那麼相比於單次IO操作的時間，花費在“db file sequential read”的總時間必須降到與IO次數相匹配。

如果“db file sequential read”等待次數太多，單條SQL又極消耗資源，那麼這些查詢的確可能需要調優以選擇一種更能接受的執行路徑，減少資源消耗。

為了確定哪些查詢等待“db file sequential read”最多，需要採集與AWR報告相同時間段的ASH報告。在報告中，查詢等待次數最多的查詢。可以與AWR報告關聯起來，根據CPU，IO和SQL統計節中的buffer gets的標準測量，判斷查詢的總體效能。

一旦有問題的語句已經確認，可以參考Document 223117.1 Troubleshooting I/O-related waits的“Reduce the I/O requirements of the database by tuning SQL”節中的方法，使用其中的方法提高這些語句的效能。

如果相比於太多這種等待事件，IO確實存在問題，那麼可以參考下面的細節：

Document 1476092.1 Troubleshooting IO Performance Problems Impacting Scattered Reads

Document 262687.1 How to use the Sql Tuning Advisor

Document 1195363.1 Database Performance and SQL

衡量正確性：

一旦已經嘗試如上方法，對比最新的AWR與標準AWR(AWR是基線)。查詢這種等待事件總體時間減少的百分比。如果仍有問題，需要重新分析這些問題，根據他們具體的現象定位具體的問題。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7192724/viewspace-774697/，如需轉載，請註明出處，否則將追究法律責任。