共計 1506 個字符，預計需要花費 4 分鐘才能閱讀完成。

這篇文章主要講解了“數據庫 I / O 上的等待事件怎么理解”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“數據庫 I / O 上的等待事件怎么理解”吧！

SQL select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = control file sequential read  

當數據庫需要讀取控制文件上的信息時，會出現這個等待事件，因為控制文件的信息是順序寫的，所以讀取的時候也是順序的，因此稱為控制文件順序讀，它經常發生在以下情況。

（1）備份控制文件。
（2）RAC 環境下不同實例之間控制文件的信息共享。
（3）讀取控制文件的文件頭信息。
（4）讀取控制文件的其他信息。

這個等到事件的包含以下三個參數：
file#：要讀取信息的控制文件的文件號。
block#：讀取控制文件信息的起始數據塊號。
blocks：需要讀取的控制文件數據塊數目。   

====================================================================
請求控制文件的更新的進程直到更新結束為止，其間等待 control file parallel write 事件
SQL select event#,name,parameter1,parameter2,parameter3 from v$event_name where name = control file parallel write  
 
這個等待事件包含三個參數：
files：Oracle 要寫入的控制文件個數。
block#：寫入控制文件的數據塊數目。
requests：寫入控制文件請求的 I / O 次數。

一般環境下，因為更新控制文件的次數不多，因此不怎么發生 control file parallel write 等待現象。但如下情況下可能發生與控制文件相關的爭用。
日志文件切換經常發生時：
日志文件過小時，將經常發生日志文件的切換。每當發生日志文件切換時，需要對控制文件進行更新，所以 LGWR 進程等待 control file parallel write 事件的時間將延長。

檢查點經常發生時：
MTTR 設定得過短或頻繁發生人為的檢查點時，CKPT 進程等待 control file parallel write 事件的時間將延長。

nologging 引起頻繁的數據文件修改時：
對數據文件在 nologging 選項下執行修改工作時，為了修改 unrecoverable SCN 需要更新控制文件。這時，服務器進程將等待 control file parallel write 事件。

I/ O 系統的性能緩慢時：

最好是將控制文件位于獨立的磁盤空間上，使用裸設備或 direct I/O。

control file parallel write 等待，通常與 control file sequential read 等待或 enq: CF – contention 等待一同出現的情況較多。enq: CF – contention 等待是在多個會話為了同時更新控制文件獲得 CF 鎖的過程中發生的。control file parallel write、control file sequential read、CF – contention 等待，全是因為過多的控制文件更新或 I / O 系統的性能問題引發的。

感謝各位的閱讀，以上就是“數據庫 I / O 上的等待事件怎么理解”的內容了，經過本文的學習后，相信大家對數據庫 I / O 上的等待事件怎么理解這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！