管理oracle日誌之調整檢查點

lyf625發表於2010-03-08
Oracle
• 檢查點事件代表在那個時刻資料庫處於一致的狀態，檢查點之所以重要，是因為在例項失敗後，只有發生在最後一個檢查點之後事務需要恢復；有兩種型別的檢查點：增量檢查點和完全檢查點；
• 增量檢查點是從ORACLE 8開始引入的，之前的版本只存在完全檢查點，這個時候，所有的髒資料都要寫回磁碟，巨大的I/O對系統性帶來很大影響，而且在寫出所有髒塊的過程中會鎖定資料快取，寫出完成之前再不能夠產生新的髒塊；和增量檢查點相關的一個新的結構是檢查點佇列，這個佇列中存放了所有按low RBA(第一次對此塊修改對應的Redo Block Address)排序的髒塊，每三秒，增量檢查點去更新控制檔案，記錄當前檢查點佇列的最小的low RBA以及on-disk RBA(LGWR程式已經寫入到日誌檔案的最後的日誌位置)等資訊，例項恢復的時候將從控制檔案的low RBA開始，而不是從資料檔案的Checkpoint SCN開始；
• 完全檢查點發生時，會執行下面的動作：
Ø 通知DBWn程式將所有的髒塊寫回磁碟；
Ø DBWn在寫出髒塊時如果發現對應的日誌還在日誌緩衝區，就觸發LGWR寫出日誌條；
Ø 檢查點程式更新控制檔案和資料檔案頭；
• 檢查點的觸發條件有下面一些：
Ø 例項關閉（ABORT方式除外）；
Ø 日誌切換；
Ø 使用者觸發：Alter System Checkpoint; Alter Tablespace … Begin Backup;
Ø 初始引數FAST_START_MTTR_TARGET指定的值已超過（增量檢查點）；
Ø 日誌檔案長度的90%（增量檢查點）；
Ø 每三秒（增量檢查點）；
• 完全檢查點發生時，必須等到要求DBWn完成的任務完成後，檢查點才能結束，增量檢查點（FAST_START_MTTR_TARGET以及日誌檔案長度的90%）也會去建議DBWn應該儘快完成的任務，但不會強制觸發DBWn，更不會等待其完成（看http://asktom.oracle.com/pls/ask/f?...372後的理解）；
• 監控檢查點的活動很重要，因為太多的檢查點會增加不必要的I/O，太少的檢查點會使資料庫在例項恢復時經歷過長的時間；
• 測量檢查點效能有下面一些方法：
Ø Select n.Name, Se.Total_Waits, Se.Average_Wait
From V$system_Event Se, V$event_Name n
Where n.Name = Se.Event(+)
And n.Name In
('checkpoint completed', 'log file switch (checkpoint incomplete)');

checkpoint completed等待檢查點的完成;
log file switch (checkpoint incomplete) 如果緊接著的一個日誌切換檢查點發生，前面日誌切換檢查點尚未完成，這時，前面的檢查點會終止，後面的檢查點得從頭再來，導致更多的I/O操作卻不能縮短例項恢復的時間；
Ø Select *
From V$sysstat
Where Name In
('background checkpoints started', 'background checkpoints completed')；

background checkpoints started 自例項啟動以來開始過的檢查點；
background checkpoints completed自例項啟動以來已經成功完成的檢查點；
這兩個值的差異值或者差異值減一等於未完成的日誌切換檢查點；
Ø Statspack中與檢查點效能相關的資料有：例項活動統計（Instance Activity Stats）的background checkpoints started 和background checkpoints completed；
Ø 當出現日誌切換檢查點未完成事件時，報警日誌檔案中會有記錄，大致的描述如下：Thread x cannot allocate new log, sequence y Checkpoint not complete;
Ø 初始引數LOG_CHECKPOINTS_TO_ALERT置為TRUE時，每一個檢查點的性息都可以在報警日誌檔案中找到；
• 調整檢查點效能有下面兩種方法（加大日誌檔案，調整初始引數）：
Ø 每個日誌切換時會發生完全檢查點，加大日誌檔案可以使檢查點的間隔更大些，以減少檢查點未完成這個事件發生頻率；

Ø 增大日誌檔案方法是，先增加新的更大日誌檔案組，再刪除小的日誌檔案組；
Ø 為了在例項恢復效能以及檢查點活動負擔間達到平衡，調整日誌檔案大小，使日誌切換的發生間隔在20到30分鐘之間為宜；
Ø 在9i中，ORACLE建議只需調整FAST_START_MTTR_TARGET這個引數，含義是例項失敗時的平均恢復時間（秒），取值範圍為0~3600，這個引數可以用Alter System語句動態改變，為零時取消這個功能，這個引數通常是用另兩個引數來實現的：FAST_START_IO_TARGET（例項失敗時的平均贓塊數）, LOG_CHECKPOINT_INTERVAL（例項失敗時的平均日誌OS塊數）；
Ø 設定上面的引數後，可以用V$INSTANCE_RECOVERY這個檢視觀察效果：TARGET_MTTR（平均恢復時間，通常等於上面引數指定的值，如果因為伺服器資源的限制可能稍大於上面的引數值） ESTIMATED_MTTR（評估的當前時刻例項失敗後的恢復用時）；


 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13024285/viewspace-628850/，如需轉載，請註明出處，否則將追究法律責任。

相關文章