檢查點（Checkpoint）優化及故障排除指南 (文件 ID 1526118.1)

適用於:

用途

本文件旨在使資料庫管理員更好地瞭解增量檢查點（Checkpoint），並對檢查點（Checkpoint）優化所用的下列四個初始化引數進行了描述：
           -  FAST_START_MTTR_TARGET
           -  LOG_CHECKPOINT_INTERVAL
           -  LOG_CHECKPOINT_TIMEOUT
           -  LOG_CHECKPOINTS_TO_ALERT
此外，本文件還介紹瞭如何解釋和處理檢查點錯誤：ALERT<sid>.LOG 檔案中報告的“Checkpoint not Complete（檢查點未完成）”和“Cannot Allocate New Log（無法分配新日誌）”。

詳細資訊

目錄：
 

1.  什麼是檢查點？
2. 檢查點和效能
3. 與增量檢查點相關的引數
4. Redo（重做）日誌和檢查點
5. 瞭解檢查點錯誤訊息（“Cannot allocate new log”和“Checkpoint not complete”）
6. Oracle 版本資訊
7. 使用 Statspack 確定檢查點問題
 
 

檢查點優化和錯誤處理

1.  什麼是檢查點？

檢查點是一種將記憶體中的已修改資料塊與磁碟上的資料檔案進行同步的資料庫事件。通過Checkpoint Oracle 確保了被 transaction 修改過資料可以被同步至磁碟。Oracle transaction 提交的時候不會將已修改資料塊同步寫入磁碟上。

檢查點有兩個用途：(1) 確保資料一致性，和 (2) 實現更快的資料庫恢復。如何更快地恢復？由於直至檢查點生成時所有的資料庫更改均已記錄在資料檔案中，因此無需再應用先於檢查點的 redo 日誌條目。檢查點必須確保快取記憶體中所有已修改的緩衝資料均已切實寫入到相應的資料檔案中，以避免在發生崩潰（例項或磁碟故障）時可能會出現的資料丟失。
 

Oracle 只有在特定條件下才會將髒快取寫入磁碟：

  - shadow process 需要掃描的資料塊個數超過 db_block_buffers 引數的四分之一。
  - 每三秒鐘。
  - 生成一個檢查點時。

檢查點通過五種型別的事件來實現：

  - 每次切換 redo 日誌檔案時。
  - 達到 LOG_CHECKPOINT_TIMEOUT 的延遲時。
  - 當前 redo 日誌檔案中已存在了大小為 （LOG_CHECKPOINT_INTERVAL* OS塊的大小（bytes））的資料。
  - 直接由 ALTER SYSTEM SWITCH LOGFILE 命令實現。
  - 直接使用 ALTER SYSTEM CHECKPOINT 命令實現。
 

在檢查點期間會發生以下操作：
 -  DBWR 將緩衝區快取中所有已修改的資料庫塊寫回到資料檔案中，
 -  檢查點程式 (ckpt) 更新所有資料檔案的檔案頭，以反映上一個檢查點發生的時間 (SCN)

2. 檢查點和效能

檢查點的優化常常會使資料庫管理員左右為難。頻繁的檢查點會實現更快的資料庫恢復，但也會導致資料庫效能降低。那麼，DBA 如何解決這一問題呢？

根據資料庫中的資料檔案數量，檢查點將會是一種高度佔用資源的操作，因為所有資料檔案頭在檢查點期間都會被凍結。關於檢查點的頻率設定，需要對效能進行權衡。檢查點頻率越高，就能在資料庫崩潰後更快地實現恢復。這也是為什麼一些不太能忍受意外系統停機的客戶現場常常會選擇此選項的原因。但是，在很多情況下，頻繁的檢查點可能會導致效能降低，這使得上述觀點並不能完全站穩腳跟。 我們假設資料庫已啟動，且有 95% 的時間處於執行狀態，剩下 5% 未執行時間是由於出現偶發的例項崩潰或硬體故障，需要進行資料庫恢復。對於大多數的客戶現場而言，優化 95% 的效能相比於極少的 5% 停機時間要更具意義。

本文件假設效能是您的首要考慮事項，並由此給出相應的建議。因此，您的目標是通過優化儘量減少檢查點的頻率。

優化檢查點涉及到下面四個關鍵初始化引數：

           -  FAST_START_MTTR_TARGET
           -  LOG_CHECKPOINT_INTERVAL
           -  LOG_CHECKPOINT_TIMEOUT
           -  LOG_CHECKPOINTS_TO_ALERT

下面將詳細討論這些引數。

同時，還針對alert日誌中出現的“checkpoint not complete”訊息給出了處理建議，這些訊息說明redo 日誌和檢查點需要優化。

3. 與增量檢查點相關的引數
注意：日誌檔案切換將始終覆蓋由以下引數引起的檢查點。

• FAST_START_MTTR_TARGET

自 Oracle 9i 以來，FAST_START_MTTR_TARGET 引數已成為優化增量檢查點目標的首選方法。通過 FAST_START_MTTR_TARGET，您可以指定資料庫執行單例項的崩潰恢復所要花費的秒數。基於內部統計資訊，增量檢查點會自動調整檢查點目標，以滿足 FAST_START_MTTR_TARGET 的要求。
V$INSTANCE_RECOVERY.ESTIMATED_MTTR 顯示當前預計的平均恢復時間 (MTTR)（以秒為單位）。即使未指定 FAST_START_MTTR_TARGET，也同樣會顯示此值。
V$INSTANCE_RECOVERY.TARGET_MTTR 顯示由系統強制執行的有效 MTTR 目標（以秒為單位）。
V$MTTR_TARGET_ADVICE 顯示在當前的 MTTR 設定下由當前的工作負載產生的 I/O 數量，以及在其他 MTTR 設定下將由當前的工作負載產生的預計 I/O 數量。此檢視可幫助使用者在執行時效能和設定 FAST_START_MTTR_TARGET 以實現快速恢復之間進行權衡。

• LOG_CHECKPOINT_INTERVAL

LOG_CHECKPOINT_INTERVAL 引數指定增量檢查點目標應滯後於當前日誌尾的最大 redo 塊數量。
如果指定了 FAST_START_MTTR_TARGET，就不應設定 LOG_CHECKPOINT_INTERVAL 或將其設定為 0。在大多數 Unix 系統上，作業系統塊大小都是 512 位元組。
也 就是說，將 LOG_CHECKPOINT_INTERVAL 的值設定為 10,000 就意味著增量檢查點目標相對於當前日誌尾的滯後不得超過 5,120,000 (5M) 位元組。以此計算，如果 redo 日誌的大小為 20M，則會對每個日誌產生 4 個檢查點。

LOG_CHECKPOINT_INTERVAL 會影響檢查點的發生時間，這意味著應特別注意此引數的設定，保持其隨 redo 日誌檔案的大小變化而更新。檢查點的頻率是影響資料庫從意外故障中恢復所需時間的因素之一。檢查點之間的間隔越長，則在發生系統崩潰時，資料庫恢復所需的 時間就越長。檢查點間隔越短意味著資料庫的恢復速度越快，但是代價是檢查點操作會消耗更多的資源。

此引數還會影響在恢復的前滾階段期間完成資料庫恢復操作所需的時間。實際的恢復時間取決於此時間，以及其他因素，例如故障型別（例項或系統崩潰、介質故障等）以及需要應用的歸檔 redo 日誌數量。

• LOG_CHECKPOINT_TIMEOUT

LOG_CHECKPOINT_TIMEOUT 引數指定增量檢查點目標應滯後於當前日誌尾的最長秒數。
換句話說，它指定緩衝區快取中的髒快取可以保持髒狀態的時間。
檢查點頻率影響資料庫從意外故障中恢復所需的時間。檢查點之間的間隔越長，資料庫恢復所需的時間就越多。

Oracle 建議使用 LOG_CHECKPOINT_INTERVAL 而不是 LOG_CHECKPOINT_TIMEOUT 來控制檢查點間隔，後者會每“n”秒啟動一次檢查點，而不管事務頻率。這可能會導致在事務量變化的情況下出現不必要的檢查點。只要可能，就必須避免不必要的檢查點，以實現最佳效能。

許多人會有這樣一種誤解：將 LOG_CHECKPOINT_TIMEOUT 設定為給定值之後，系統就會按該間隔啟動日誌切換，從而啟用用於stand-by資料庫配置的恢復視窗。日誌切換會引起檢查點，但檢查點並不會引起日誌切換。引起日誌切換的唯一方式是使用 ALTER SYSTEM SWITCH LOGFILE 進行手動操作或重新調節 redo 日誌大小，以引起更為頻繁的切換。這由作業系統塊而非時間間隔控制。
線上 redo 日誌的大小對效能和恢復至關重要。
有關 redo 日誌和檢查點的資訊，請參考以下其他部分。

• LOG_CHECKPOINTS_TO_ALERT

通過 LOG_CHECKPOINTS_TO_ALERT，您可以將檢查點記錄到alert日誌中。

這樣做有助於確定檢查點是否按所需頻率發生。
在 Oracle9i 之前，此引數為靜態引數。
Oracle 通常建議將此引數設定為 TRUE，因為開銷很小，可以忽略不計，但alert日誌中的資訊可能會非常有用。

有關上述例項引數會如何影響檢查點的更多詳細資訊，請參閱 Note:76713.1

4. Redo 日誌和檢查點

每次切換日誌時都會發生一次檢查點。如果上一個檢查點已在進行中，由日誌切換引起的檢查點將覆蓋當前檢查點。

此時就需要大小合適的 redo 日誌，以避免因頻繁的日誌切換而引起不必要的檢查點。另外，增量檢查點目標和日誌尾之間的間隔也會受“最小線上日誌檔案大小的 90%”設定所限制。這樣可確保在大多數情況下，日誌切換不必等待檢查點。因此，日誌檔案大小應配置得足夠大。一個好的辦法是，最多每二十分鐘切換一次日誌。日誌檔案過小會增加檢查點活動並降低效能。Oracle 建議使用者將所有線上日誌檔案設定為同一大小，且每個執行緒至少擁有兩個日誌組。若要監視日誌切換髮生的速度，以及隨後的檢查點發生的速度，alert日誌是一個很有價值的工具。
 
以下是通過alert日誌發現日誌切換過於頻繁的示例：
 

Fri May 16 17:15:43 1997
Thread 1 advanced to log sequence 1272
  Current log# 3 seq# 1272 mem# 0: /prod1/oradata/logs/redologs03.log
Thread 1 advanced to log sequence 1273
  Current log# 1 seq# 1273 mem# 0: /prod1/oradata/logs/redologs01.log
Fri May 16 17:17:25 1997
Thread 1 advanced to log sequence 1274
  Current log# 2 seq# 1274 mem# 0: /prod1/oradata/logs/redologs02.log
Thread 1 advanced to log sequence 1275
  Current log# 3 seq# 1275 mem# 0: /prod1/oradata/logs/redologs03.log
Fri May 16 17:20:51 1997
Thread 1 advanced to log sequence 1276
  Current log# 1 seq# 1276 mem# 0: /prod1/oradata/logs/redologs01.log
 

如果 redo 日誌每 3 分鐘切換一次，您就會察覺到效能降低。這表明 redo 日誌不夠大，不能有效地處理該事務負載。

有關如何估計 redo 日誌檔案的適當大小的詳細資訊，請參閱 Note:1038851.6 。有關如何重新調節線上 redo 日誌檔案大小的示例，請參閱 Note:1035935.6 。

5. 瞭解檢查點錯誤訊息（“Cannot allocate new log”和“Checkpoint not complete”）

有時，您可以在 alert.log 檔案中看到以下相應訊息：

  Thread 1 advanced to log sequence 248
    Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log
  Thread 1 cannot allocate new log, sequence 249
  Checkpoint not complete
 

此資訊表明 Oracle 希望重新使用某個 redo 日誌檔案，但當前的檢查點位置仍位於該日誌中。在這種情況下，Oracle 必須等到檢查點位置通過該日誌。由於增量檢查點目標相對於當前日誌尾的滯後絕不會超過最小日誌檔案大小的 90% 以上，因此，如果 DBWR 寫入速度過慢，或者在日誌全滿之前發生日誌切換，或者日誌檔案過小，就會遇到這種情況。在資料庫等待檢查點時，redo 生成過程會停止，直到完成日誌切換。

6. Oracle 版本資訊

在 Oracle8i 中，初始化引數 FAST_START_IO_TARGET 會使增量檢查點自動調整其目標，從而使恢復所需的資料塊數量不多於 FAST_START_IO_TARGET 設定的值。自 Oracle 9i 開始，已棄用此引數，取而代之的是引數 FAST_START_MTTR_TARGET。

7. 使用 Statspack 確定檢查點問題

您可以每 15 分鐘左右收集一次 Statspack 快照，這些快照報告將收集有關在該時間段已開始的檢查點數量、已完成的檢查點數量及檢查點發生時寫入的資料庫緩衝數量的有用資訊。此外，還包含關於 redo 活動的統計資訊。通過收集和比較這些快照報告，您可以完整地瞭解不同時期的檢查點效能。

Statspack 報告中另一個值得關注的內容是等待事件，下面的等待事件明確指出了 redo 日誌吞吐量和檢查點的問題：

log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch/archive
log file switch (clearing log file)
log file switch completion
log switch/archive
log file sync

 

如果上述等待事件中的一個或多個頻繁地出現，且相關數值較大，那您就需要採取行動了，例如新增更多的線上 redo 日誌檔案，或增加其大小和/或修改檢查點引數。

參考