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.

線上重做日志的大小是關鍵的對于優化和恢複。