control file sequential read等待事件

urgel_babay發表於2016-02-29
事件
2015.06.03
    
    在看AWR時，經常看到control file sequential read等待事件，這些天也經常收集學習等待事件，剛剛在生產庫中做了一個我認為空閒時段的報告，可還是有control file sequential read等待事件，所以不得不承認系統磁碟的I/O瓶頸嚴重。
當資料庫需要讀取控制檔案上的資訊時到I/O等待，會出現這個等待事件，因為控制檔案的資訊是順序寫的，所以讀取的時候也是順序的，因此稱為控制檔案順序讀，它經常發生在以下情況。
（1）備份控制檔案。
（2）RAC環境下不同例項之間控制檔案的資訊共享。
（3）讀取控制檔案的檔案BLOCK頭部資訊。
（4）讀取控制檔案的其他資訊。
等待的時間就是消耗在讀取控制檔案上的時間。
在V$SESSION_WAIT這個檢視裡面，這個等待事件有三個引數P1、P2、P3，其中P1代表正在讀取的控制檔案號，
select event,p1,p2,p3 from v$session_wait where event like '%control%';
透過下面的SQL語句可以知道究竟是具體是哪個控制文被讀取：
SELECT * FROM X$KCCCF WHERE INDX = <file#>；

P2代表開始讀取的控制檔案BLOCK號，它的BLOCK大小和作業系統的BLOCK大小一樣，通常來說是512K，也有些UNIX的是1M或者2M，P3代表會話要讀取BLOCK的數量。
一般來說使用引數P1、P2來查詢BLOCK,當然也可以包括引數P3，但是那樣最終就變成了一個多BLOCK讀取，因此我們一般都忽略引數P3。
如果這個等待事件等待的時間比較長，則需要檢查控制檔案所在的磁碟是否很繁忙，如果是，將控制檔案移動到負載比較低，速度比較快的磁碟上去。如果系統支援非同步I/O，
則啟用非同步I/O。對於並行伺服器來說，如果這種等待比較多，會造成整個資料庫效能下降，因為並行伺服器之間的一些同步是透過控制檔案來實現的。

總結相關的解決辦法：
1、將控制檔案移動到負載比較低，速度比較快的磁碟上去。
2、適當減少控制檔案的數量，但是要保證控制檔案的冗餘符合你的需求
3、系統支援非同步I/O，則啟用非同步I/O。







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

相關文章