checkpoint和checkpoint最佳化的參數

在metalink也看到了這個錯誤,剛好今天也碰到,簡單翻譯了一下

Checkpoint Tuning and Troubleshooting Guide

這個主題使DBA能對checkpoint和checkpoint最佳化的參數有一個較好的理解:
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT

它也解釋了怎樣解釋和處理出現在ALERT.LOG file中的
checkpoint的錯誤"'Checkpoint not Complete' and 'Cannot Allocate New Log"

什麼是checkpoint?

checkpoint是為了記憶體中已經被修改的資料區塊與磁碟資料檔案同步的一種資料庫事件。它提供了一種
保持事務提交以後資料一致的手段。往Oracle磁碟寫髒資料的機制與事務提交不是同步的。

checkpoint有兩個目地：1.確保資料一致性。2.使資料庫能快速地恢複。怎樣快速恢複呢?
因為資料庫會把所有的改變都在資料檔案上設定checkpoint,並一直增加，它不需要請求checkpoint
之前的重做日誌.Checkpoint能保證所有在緩衝區的資料寫到相應的資料檔案，防止因為意外的執行個體
失敗導致的資料丟失。

Oracle寫這個髒資料只在一定的條件下：
後面的進程需要1/4個db_block_buffer參數的大小
每三秒
當一個checkpoint產生

一個checkpoint有5中事件類型：
每次重做日誌的切換
LOG_CHECKPOINT_TIMEOUT 這個延遲參數的到達。
相應位元組(LOG_CHECKPOINT_INTERVAL* size of IO OS blocks)被寫到當前的重做日誌

IO OS blocks: 在UNIX下可以 # fstyp -v /dev/vg00/lvol1
vxfs
version: 5
f_bsize: 8192

ALTER SYSTEM SWITCH LOGFILE 這個命令會直接導致checkpoint發生
ALTER SYSTEM CHECKPOINT

Checkpoint期間會有下面進程發生:
DBWR寫所有髒資料到資料檔案
LGWR更新控制檔案和資料檔案的SCN

Checkpoints和最佳化
Checkpoints是一個資料庫最佳化的痛點。頻繁的Checkpoints可以實現快速的恢複，但也會使效能
下降。DBA怎樣處理這個問題呢？

依賴於資料庫資料檔案的數量，一個Checkpoint可能是高速的運行。因為所有的資料檔案在Checkpoint
期間都會被凍結。更頻繁的Checkpoints可以快速恢複資料庫。這也客戶對不按規定系統宕機的容忍的原因。
然而，在一些特殊情況下，頻繁的Checkpoints也不能保證可以快速恢複。我們假設資料庫在95%的時間
內是正常運行，5%由於執行個體失敗導致不可用，要求恢複。對大多數客戶而言，他們更希望調整95%
的效能而不是5%的宕機時間。

這個假設表明，效能是擺在第一位的，所以我門的目標就是在最佳化期間減少Checkpoints的頻繁度。

最佳化Checkpoints包括4個關鍵的初始化參數：
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT

詳細介紹每個參數:
FAST_START_MTTR_TARGET

Oracle9i以來FAST_START_MTTR_TARGET 參數是調整checkpoint的首選的方法。
FAST_START_MTTR_TARGET 可以指定單一實例恢複需要的秒數。基於內部的統計，增長的
checkpoint會自動調整的checkpint的目標以滿足FAST_START_MTTR_TARGET 的需求。
V$INSTANCE_RECOVERY.ESTIMATED_MTTR 顯示當前估計需要恢複的秒數。這個值會被顯示
即使FAST_START_MTTR_TARGET 沒有被指定。
V$INSTANCE_RECOVERY.TARGET_MTTR 表明在短時間內MTTR的目標。
V$MTTR_TARGET_ADVICE 顯示這個當前MTTR設定的工作量產生的I/O數量和其他I/O。
這個視圖協助使用者評定這個在最佳化和恢複之前的平衡。

LOG_CHECKPOINT_INTERVAL

LOG_CHECKPOINT_INTERVAL 參數指定這個最大的重做塊的間隔數目。
如果FAST_START_MTTR_TARGET被指定，LOG_CHECKPOINT_INTERVAL不能被設定為0.

在大多數Unix系統的OS塊大小是512位元組。設定LOG_CHECKPOINT_INTERVAL=10000意味著
這個增長的checkpoint不能追加到當前日誌因為多於5M。如果你的重做日誌是20M，你將
發出4個checkpoint對每個重做日誌。

LOG_CHECKPOINT_INTERVAL 會發生影響當一個checkpoint發生時，小心設定這個參數，
保持它隨著重做記錄檔大小變化而變化。checkpoint頻繁是這個影響資料庫恢複的原因之一。
短的checkpoint間隔意味資料庫將快速恢複，也增加了資源的利用。

這個參數也影響資料庫向前復原的時間。實際的恢復是基於這個時間，當然還有失敗的類型和
需要歸檔日誌的數量。

LOG_CHECKPOINT_TIMEOUT
這個參數指定checkpoint發出的時間間隔。換句話說，它指定一次髒資料多少時間寫出一次。

checkpoint頻率會影響這個資料庫恢複的時間。長時間的間隔會要求資料庫恢複要求更久。
Oracle建議用LOG_CHECKPOINT_interval去控制checkpoint而不用LOG_CHECKPOINT_TIMEOUT
,LOG_CHECKPOINT_TIMEOUT每n秒發一次checkpoint,不顧事務提交的頻率。這可能會導致一些
沒有必要的checkpoint在事務已經變化的情況下。不必要的checkpoint必須被避免。

還有一個容易誤解的地方：LOG_CHECKPOINT_TIMEOUT 會間隔性地發出log switch。
而Log switch會觸發一個checkpoint,但checkpoint不會導致一個log switch.唯一手工方式
alter system switch logfile或者重新設定redo logs大小 可以導致頻繁switch.

線上重做日誌的大小是關鍵的對於最佳化和恢複。