深入淺出檢查點和例項recovery

再次翻看eyle深入淺出，記錄關於檢查點和例項恢復的一些筆記

oracle 8I的增量檢查點主要是透過fast_start checkpointing特性來實現，oracle 8I開始,fast_start checkpointing特性，包含在oracle企業版本的fast_start fault recovery元件中。

該元件還包括fast_start parallel rollback和fast_start on_demand rollback。

fast_start checkpointing特性主要是透過fast_start_mttr_target(instance 恢復期望時間)引數來實現,表示instance crash恢復所需的時間

增量檢查點連續地進行，把checkpoint queue中最低的low rba寫入disk中（dbwr會根據checkpoint queue的low rba順序寫入到disk），控制檔案使用輕量級的控制檔案更新協議將最低的low rba寫入控制檔案，這樣不僅可以讓rba更接近與資料庫的最新狀態，減少instance恢復時間，也能平衡常規檢查點時的I/O衝突，checkpoint queue中的是按照low rba排序的。如果資料塊進行多次修改，此dirty塊在checkpoint queue的位置不會改變

SQL> select target_mttr,estimated_mttr,ckpt_block_writes from v$instance_recovery;

TARGET_MTTR ESTIMATED_MTTR CKPT_BLOCK_WRITES

----------- -------------- -----------------

90 50 47

v$instance_recovery檢視中的target_mttr表示的是instance恢復的期望時間，而estimated_mttr是根據redo和dirty buffer估算的instance恢復的時間，ckpt_block_writes則是檢查點已經寫出的資料塊的數量，初始化引數fast_start_mttr_target設定較大或較小時，target_mttr引數值可能並不一定等於fast_start_mttr_target引數.

在v$instance檢視中如果target_mttr<=estimated_mttr時，系統將會執行檢查點。如果在繁忙系統中，target_mttr長時間大於estimated_mttr，很可能是系統正需要執行大規模寫出，或者checkpoint incomplete.這時候進一步檢視v$log檢視checkpoint對於redolog切換檢查點是否完成，利用linux的iostat工具檢視磁碟I/O等資訊，是否因為磁碟的I/O存在瓶頸，導致dbwr寫入程式慢，而導致checkpoint沒有及時完成，進而導致根據redo和dirty buffer計算而來的estimated_mttr大於target_mttr等。

從oracle 10g開始，資料庫可以實現自動調整檢查點，oracle資料庫使用系統低I/O負載時寫出dirty buffer，提高執行效率，設定fast_start_mttr_target=0，自動調整檢查點將生效，如果希望嚴格控制crash恢復時間，可以設定fast_start_mttr_target值，控制instance恢復時間，反之則可以設定fast_start_mttr_target為0而啟動10g的自動調整的檢查點功能。

資料庫異常關閉之後，下次啟動時，oracle會自行進行instance recovery，例項恢復又可分為cache recovery和transaction recovery

Cache recovery

讀取日誌，從最後完成的檢查點開始應用redo，這個過程就是前滾rolling forward，也稱cache recovery，完成前滾後，資料庫可以被開啟訪問。

Transaction recovery

Oracle回滾未提交的事務，oracle使用兩個特性fast_start on_demand rollback和fast_start parallel rollback增加transaction recovery階段效率，這也就是上面所提的oracle 8I企業版的元件fast_start fault recovery另外兩個組成部分。

使用fast-start on-demand rollback特性，oracle允許在開啟資料庫之後開始新的事務，如果有使用者程式訪問那些未提交事務的記錄，oracle再予以回滾，需要時再予以回滾，在fast-start on-demand rollback中，後臺程式smon排程使用多個伺服器程式parallel回滾一個事務集。

Fast-start parallel rollback主要對於長時間執行的dml等操作進行事務回滾，smon自動決定何時開始並行回滾並且在多個程式之間分配工作。Fast_start parallel rollback還可以用於內部事務恢復Intra-transaction recovery,在內部事務恢復中，一個大事務可以被拆分，分配給幾個伺服器程式並行回滾。

可以Fast_start_parallel_rollback來控制並行回滾：

False 禁止fast-start parallel rollback

Low 限制恢復程式不超過2倍的cpu_count

High 限制回顧程式不能超過4被的cpu_count