【效能優化】增量檢查點

Oracle從8i開始引入了檢查點佇列這麼一種概念，用於記錄資料庫裡面當前所有的髒資料塊的資訊，DBWR根據這個佇列而將髒資料塊寫入到資料檔案中。檢查點佇列按時間先後記錄著資料庫裡面髒資料塊的資訊，裡面的條目包含RBA（Redo Block Address，重做日誌裡面用於標識檢查點期間資料塊在重做日誌裡面第一次發生更改的編號）和資料塊的資料檔案號和塊號。在檢查點期間不論資料塊更改幾次，它在檢查點佇列裡面的位置始終保持不變，檢查點佇列也只會記錄它最早的RBA，從而保證最早更改的資料塊能夠儘快寫入。當DBWR將檢查點佇列裡面的髒資料塊寫入到資料檔案後，檢查點的位置也要相應地往後移，CKPT每三秒會在控制檔案中記錄檢查點的位置，以表示Instance Recovery時開始恢復的日誌條目，這個概念稱為檢查點的“心跳”（heartbeat）。檢查點位置發生變更後，Oracle裡面通過4個引數用於控制檢查點位置和最後的重做日誌條目之間的距離。在這裡面需要指出的是，多數人會將這4個引數看作控制增量檢查點發生的時間。事實上這是錯誤的，這4個引數是用於控制檢查點佇列裡面的條目數量，而不是控制檢查點的發生。

（1、）fast_start_io_target

該引數用於表示資料庫發生Instance Recovery的時候需要產生的IO總數，它通過v$filestat的AVGIOTIM來估算的。比如我們一個資料庫在發生Instance Crash後需要在10分鐘內恢復完畢，假定OS的IO每秒為500個，那麼這個資料庫發生Instance Recovery的時候大概將產生500*10*60=30,000次IO，也就是我們將可以把fast_start_io_target設定為 30000。

（2、）fast_start_mttr_target

我們從上面可以看到fast_start_io_target來估算檢查點位置比較麻煩。Oracle為了簡化這個概念，從9i開始引入了 fast_start_mttr_target這麼一個引數，用於表示資料庫發生Instance Recovery的時間，以秒為單位。這個引數我們從字面上也比較好理解，其中的mttr是mean time to recovery的簡寫，如上例中的情況我們可以將fast_start_mttr_target設定為600。當設定了 fast_start_mttr_target後，fast_start_io_target這個引數將不再生效，從9i後 fast_start_io_target這個引數被Oracle廢除了。

（3、）log_checkpoint_timeout

該引數用於表示檢查點位置和重做日誌檔案末尾之間的時間間隔，以秒為單位，預設情況下是1800秒。

（4、）log_checkpoint_interval

該引數是表示檢查點位置和重做日誌末尾的重做日誌塊的數量，以OS塊表示。

（5、）90% OF SMALLEST REDO LOG

除了以上4個初始化引數外，Oracle內部事實上還將重做日誌檔案末尾前面90%的位置設為檢查點位置。在每個重做日誌中，這麼幾個引數指定的位置可能不盡相同，Oracle將離日誌檔案末尾最近的那個位置確認為檢查點位置。
                                                                                                                                                                                                                              from ITPUB http://www.itpub.net/thread-1341844-2-1.html

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