對checkpoint的理解一文的學習

checkpoint的作用是什麼？ 看這了篇文章受益頗多.

http://space.itpub.net/7199859/viewspace-255305

[@more@]

log switch會觸發一個檢查點,在檢查點完成之前,日誌檔案是不能夠被重用的,狀態也就是active,那麼什麼時間才會inactive?

今天對這個問題有了更深的理解:

其實通常所說的logfile switch 觸發檢查點，實際上就是給出一個標記，而並不真正去寫髒塊。等待增量檢查點做到了那個標記，再標識完成。

所以觸發增量檢查點的時機就顯的尤為重要:

90％ OF THE SMALLEST REDO LOGFILE

意味著最後一次增量檢查點與當前日誌檔案末尾所差的redo block數量如果超過最小redo log的90％?敲淳突崬シ⒃雋考觳櫚恪?/p>

FAST_START_MTTR_TARGET：例項恢復的時間限制，
oracle將這個時間換算成redo blocks數量，當log buffer中未寫入log file的redo block數量超過這個值，就會觸發增量檢查點。

FAST_START_IO_TARGET：例項恢復所需要讀取的redo blocks數量，當log buffer中未寫入log file的redo block數量超過這個值，就會觸發增量檢查點。

LOG_CHECKPOINT_TIMEOUT：2次增量檢查點的時間間隔。

LOG_CHECKPOINT_INTERVAL：最後一次增量檢查點與當前日誌檔案末尾所差的redo block數量。

注意：增量檢查點並不是將髒列表中的所有髒塊都寫出到資料檔案中，而是寫出一部分，保證滿足所有條件即可。

也學了兩個重要的檢視,v$instance_recovery 和x$kcccp

看看當前各個增量檢查點觸發條件的值：

SQL> select actual_redo_blks act,target_redo_blks target,LOG_FILE_SIZE_REDO_BLKS logfile,LOG_CHKPT_TIMEOUT_REDO_BLKS log_check,target_mttr tmttr,estimated_mttr es_mttr from v$instance_recovery;

62967 170577 184320 170577 0 14

--LOG_FILE_SIZE_REDO_BLKS的值是184320，這正好是日誌檔案的90％
--日誌塊是0.5K一個，換算成M，184320*0.5/1024＝90 日誌檔案是100M

--再看一下最後一次檢查點的位置：
SQL> select CPLRBA_SEQ,CPLRBA_BNO,CPODR_SEQ,CPODR_BNO from x$kcccp;

CPLRBA_SEQ CPLRBA_BNO CPODR_SEQ CPODR_BNO
---------- ---------- ---------- ----------

47 107610 47 170607

--最後一次檢查點發生在47號日誌的17610塊,當前日誌也是47號，日誌尾在170607塊