【體系結構】與Checkpoint相關的問題解決思路

思路清晰

1.  什麼是checkpoint （檢查點）

2.  checkpoint 與效能影響

3.  與checkpoint 相關的引數

4.  redolog 與 checkpoint 的關係

5.  問題解決思路：“ cannot allocate new log ”和“ checkpoint not complete ”

1.  什麼是checkpoint （檢查點）

checkpoint 是一個資料庫事件，它將記憶體中被修改的資料塊寫進磁碟中。它保證了 Oracle 事務修改的資料一致性。在 Oracle 中，將修改後的塊寫入磁碟的機制與事務提交的機制是不同步的。

checkpoint 有兩個目的： 1 是保證資料的一致性； 2 是為了啟用更快的資料庫例項恢復。如何才能更快的恢復，因為檢查點之前的所有資料庫更改都已經寫進了資料檔案中，因此不需要再對這部分進行應用 redolog 。檢查點必須確保快取中所有更改的資料塊都真正寫入了相應的資料檔案，以避免由於例項崩潰而導致的資料丟失。

Oracle 只在某些特定的條件下才會將髒資料寫進磁碟中 :

- 程式必須掃描超過 db_block_buffer 引數的 1/4

- 每三秒一次

- 當發生 checkpoint

checkpoint 會在五種情況下發生：

- 日誌切換時

- 當達到 LOG_CHECKPOINT_TIMEOUT 延遲時

- 當產生日誌大小 = （ LOG_CHECKPOINT_INTERVAL*OS 塊大小 ）時

- 當執行 alter system switch logfile 時

- 當執行 alter system checkpoint 時

checkpoint 會發生以下事情：

- DBWR 程式會把所有在 buffer cache 中修改的資料塊寫進磁碟資料檔案中

- checkpoint 程式會更新所有資料檔案和控制檔案的頭，以指示最後一個 checkpoint 發生的時間戳 SCN

2.  checkpoint 與效能

檢查點會給DBA 帶來一個調優難題。頻繁的 checkpoint 會使恢復更快，但是會導致資料庫系統的效能下降。 DBA 應該如何解決這個問題？

根據資料庫中資料檔案的數量，checkpoint 可能是一個高度資源密集型的操作。因為在檢查點期間所有的資料檔案頭都會被凍結，直到檢查點結束。在檢查點的頻率方面有一個效能的權衡：更頻繁的檢查點可以在例項崩潰後更快地恢復資料庫，這也是一些對計劃外系統停機的容忍度非常低的客戶會經常選擇這個選項。然而，在許多情況下，頻繁的檢查點會導致效能的下降。

調優checkpoint 涉及到以下幾個引數

- FAST_START_MTTR_TARGET

- LOG_CHECKPOINT_INTERVAL

- LOG_CHECKPOINT_TIMEOUT

- LOG_CHECKPOINTS_TO_ALERT

3.  與checkpoint 相關的引數

1）  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 之間的平衡，以獲得更好的恢復時間。

2）  LOG_CHECKPOINT_INTERVAL

LOG_CHECKPOINT_INTERVAL 引數指定增量檢查點應該滯後於當前redolog 末尾的重做塊的最大數量。如果指定了 FAST_START_MTTR_TARGET ，就不應該設定 LOG_CHECKPOINT_INTERVAL ，或者將其設定為0 。

LOG_CHECKPOINT_INTERVAL 會影響檢查點發生的時間，這就意味著應該仔細注意該引數的設定。檢查點頻率是影響資料庫從意外故障中恢復所需時間的因素之一。如果檢查點時間間隔更長，意味著如果系統崩潰，資料庫需要更多的時間來恢復。檢查點時間間隔如果更短，意味著資料庫將更快的恢復，但要以檢查點操作期間增加的資源利用率作為代價。

3）  LOG_CHECKPOINT_TIMEOUT

LOG_CHECKPOINT_TIMEOUT 引數指定增量檢查點目標應該滯後於當前日誌末尾的最大秒數。換句話說，它指定了buffer cache 中的髒緩衝區可以保持多長時間。

Oracle 建議使用 LOG_CHECKPOINT_INTERVAL 來控制檢查點間隔，而不是 LOG_CHECKPOINT_TIMEOUT 。LOG_CHECKPOINT_TIMEOUT 將在每 n 秒啟動一個檢查點，而不管事務是否繁忙。在事務量不同的情況下，這可能會導致不必要的檢查點。

4）  LOG_CHECKPOINTS_TO_ALERT

LOG_CHECKPOINTS_TO_ALERT 允許我們將檢查點記錄在alert 檔案中。這樣做對於確定檢查點是否按照預期的頻率執行是很有用的。 Oracle 建議將此值設定為 TRUE ，因為消耗是可以忽略不計的，但是會產生很有用的 alert 資訊。

4.  redolog 與檢查點

每次redolog 切換都會發生一個檢查點。如果一個檢查點正在進行中，此時又發生 redolog 切換，那麼就會覆蓋當前的檢查點。為了避免這種情況，就需要我們設定適當大小的 redolog ，以避免由於頻繁的切換日誌而導致不必要的檢查點。因此， redolog 的大小應該配置得足夠大。 Oracle 建議每 10-20 分鐘切換一次日誌，日誌檔案過小會增加檢查點活動並降低效能。 Oracle 建議將所有 redolog 設定為相同的大小，並且每個執行緒至少設定兩個日誌組。我們可以透過告警日誌來監視日誌切換頻率，和隨後發生的檢查點。

5.  cannot allocate new log 和 checkpoint not complete

有時候我們可以在alert 日誌中發現以下資訊

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 希望重用 redolog ，但當前的檢查點位置仍然在該日誌中。在這種情況下， Oracle 必須等待檢查點位置透過該日誌。這種情況下很可能遇到了 DBWR 寫太慢，或者 redolog 寫滿之前發生了日誌切換，或者日誌檔案太小，就會遇到這種情況。

 

 

---- end ----