網上有很多資料都沒有說清楚發生log switch的時候，到底完全檢查點還是增量檢查點。有人說是完全檢查點，也有人說是增
量檢查點。其實如果你深入了解完全檢查點和增量檢查點的的差別，就應該知道log switch到底是增量檢查點還是完全檢查點。
在8i以前，log switch的時候oracle确實是會做完全檢查點；但從8i開始，oracle在log switch的時候做的是增量檢查點，但
從嚴格意義上來說并不能完全算是增量檢查點，因為在log switch的時候，不僅會像增量檢查點那樣更新控制檔案，而且還會像完
全檢查點那樣會更新資料檔案頭。
下面我們來一起來做做測試：證明了在log switch的時候，發生的既不是完全檢查點，也不是嚴格意義上的增量檢查點。
測試DB版本:
idle> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
一、我們首先來驗證在log switch的時候，發生的不是完全檢查點：
查幾個跟日志切換檢查點相關的參數
idle> @?/rdbms/admin/show_para
Enter value for p: _dbwr_scan_interval
old 12: AND upper(i.ksppinm) LIKE upper('%&p%')
new 12: AND upper(i.ksppinm) LIKE upper('%_dbwr_scan_interval%')
P_NAME P_DESCRIPTION P_VALUE
ISDEFAULT ISMODIFIED ISADJ
_dbwr_scan_interval dbwriter scan interval 300
TRUE FALSE FALSE
Enter value for p: _disable_selftune_checkpointing
new 12: AND upper(i.ksppinm) LIKE upper('%_disable_selftune_checkpointing%')
_disable_selftune_checkpointing Disable self-tune checkpointing FALSE
idle> show parameter log_checkpoint_timeout
NAME TYPE VALUE
log_checkpoint_timeout integer 1800
沒修改參數之前：
idle> select group#,status from v$log;
GROUP# STATUS 1 CURRENT
2 INACTIVE
3 INACTIVE idle> alter system switch logfile;
idle> !date
Sun May 12 19:43:20 CST 2013
idle> select group#,status from v$log;
GROUP# STATUS 1 ACTIVE
2 CURRENT
3 INACTIVE Sun May 12 19:49:25 CST 2013
GROUP# STATUS 1 INACTIVE
2 CURRENT
3 INACTIVE 1号日志組從ACTIVE變成INACTIVE大約要5分鐘左右
修改參數可以命alter system switch logfile;時redo log file的狀态一直是active(保持一天)：
_dbwr_scan_interval=24*3600
log_checkpoint_timeout=24*3600
_disable_selftune_checkpointing=TRUE
idle> alter system set "_dbwr_scan_interval"=86400;
System altered.
idle> alter system set log_checkpoint_timeout=86400;
idle> alter system set "_disable_selftune_checkpointing"=true;
哈哈。。。可以觀察一下是不是一直是ACTIVE
Sun May 12 19:55:54 CST 2013
GROUP# STATUS 1 INACTIVE
2 INACTIVE
3 CURRENT idle> ALTER SYSTEM SWITCH LOGFILE;
GROUP# STATUS 1 CURRENT
2 INACTIVE
3 ACTIVE
執行完上述switch logfile操作後等待12小時，然後再次執行上述查詢語句：
Sun May 13 7:56:58 CST 2013
GROUP# STATUS 1 CURRENT
2 INACTIVE
3 ACTIVE 從結果裡我們可以看到現在redo log group 3還是處于active狀态，我現在的這個庫是測試庫隻有我一個人在用，是以很空閑，如
果switch logfile的時候發生的是full checkpoint，則當我等待24小時後再次查詢v$log的時候redo log group 3必然是處于
inactive狀态：
即現在我們已經證明了在log switch的時候，發生的不是完全檢查點。
Sun May 13 20:56:58 CST 2013
GROUP# STATUS 1 CURRENT
2 INACTIVE
3 INACTIVE 哈哈。。。你可以試試，那些參數的威力。。牛B的一比。。。
現在我們來證明在log switch的時候，發生的不是嚴格意義上的增量檢查點。增量檢查點隻會更新control file，不會更新
datafile header，知道這個那就很好驗證了，利用BBED恢複神器：
hr@OCP> select group#,status from v$log;
GROUP# STATUS 1 INACTIVE
2 CURRENT
3 INACTIVE BBED> set file 1 block 1
FILE# 1
BLOCK# 1 BBED> p kcvfhckp
struct kcvfhckp, 36 bytes @484
struct kcvcpscn, 8 bytes @484
ub4 kscnbas @484 0x000c592e
ub2 kscnwrp @488 0x0000 ub4 kcvcptim @492 0x3097e9b7
ub2 kcvcpthr @496 0x0001
union u, 12 bytes @500
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000038
ub4 kcrbabno @504 0x000000a3
ub2 kcrbabof @508 0x0010 ub1 kcvcpetb[0] @512 0x02
ub1 kcvcpetb[1] @513 0x00
ub1 kcvcpetb[2] @514 0x00
ub1 kcvcpetb[3] @515 0x00
ub1 kcvcpetb[4] @516 0x00
ub1 kcvcpetb[5] @517 0x00
ub1 kcvcpetb[6] @518 0x00
ub1 kcvcpetb[7] @519 0x00
即現在的system01.dbf的datafile header的checkpoint scn的base是0x000c592e。
現在我執行一次switch logfile，再來觀察system01.dbf的datafile header的checkpoint scn：
hr@OCP> update employees set salary=salary+1000;
107 rows updated.
hr@OCP> commit;
Commit complete.
hr@OCP> alter system switch logfile;
hr@OCP> select group#,status from v$log;
GROUP# STATUS 1 INACTIVE
2 ACTIVE
3 CURRENT
FILE# 1
BLOCK# 1 ub4 kscnbas @484 0x000c592e
ub2 kscnwrp @488 0x0000 struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x00000038
ub4 kcrbabno @504 0x000000a3
ub2 kcrbabof @508 0x0010 我們發現現在的system01.dbf的datafile header的checkpoint scn的base還是0x000c592e，也就是說oracle在switch logfile的
時候的checkpoint并不是馬上發生，oracle在等待一個發生的時機。
我們現在強制讓log switch checkpoint馬上發生：
GROUP# STATUS 1 CURRENT
2 ACTIVE
3 ACTIVE 等待日志組2變成INACTIVE
GROUP# STATUS 1 CURRENT
2 INACTIVE
3 ACTIVE FILE# 1
BLOCK# 1 ub4 kscnbas @484 0x000c59cf
ub2 kscnwrp @488 0x0000 ub4 kcvcptim @492 0x3097eb6d
struct kcvcprba, 12 bytes @500
ub4 kcrbaseq @500 0x0000003b
ub4 kcrbabno @504 0x00000002
ub2 kcrbabof @508 0x0010 看到了嗎？現在system01.dbf的datafile header的checkpoint scn的base已經變成了0x000c59cf，也就是說----在log switch的
時候，發生的不是嚴格意義上的增量檢查點，因為其不僅更新了control file，還更新了datafile header。
最後，我們來說一下oracle中checkpoint的種類。oracle中的checkpoint一共有七種，它們分别是：
1、Full Checkpoint
2、Thread Checkpoint
3、File Checkpoint
4、Object Checkpoint
5、Parallel Query Checkpoint
6、Incremental Checkpoint
7、Log Switch Checkpoint
￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥
增量checkpoint
增量checkpoint工作過程
因為每次完全的checkpoint都需要把buffer cache所有的髒塊都寫入到資料檔案中，這樣就是産生一個很大的IO消耗，頻繁的完全checkpoint操作很對系統的性能有很大的影響，為此 Oracle引入的增量checkpoint的概念，buffer cache中的髒塊将會按照BCQ隊列的順序持續不斷的被寫入到磁盤當中，同時CKPT程序将會每3秒中檢查DBWn的寫入進度并将相應的RBA資訊記錄到控制檔案中。有了增量checkpoint之後在進行執行個體恢複的時候就不需要再從崩潰前的那個完全checkpoint開始應用重做日志了，隻需要從控制檔案中記錄的RBA開始進行恢複操作，這樣能節省恢複的時間。
發生增量checkpoint的先決條件
* 恢複需求設定 （FAST_START_IO_TARGET/FAST_START_MTTR_TARGET）
* LOG_checkpoint_INTERVAL參數值
* LOG_checkpoint_TIMEOUT參數值
* 最小的日志檔案大小
* buffer cache中的髒塊的數量
增量checkpoint的特點
* 增量checkpoint是一個持續活動的checkpoint。
* 沒有checkpoint RBA，因為這個checkpoint是一直都在進行的，是以不存在normal checkpoint裡面涉及的checkpoint RBA的概念。
* checkpoint advanced in memory only
* 增量checkpoint所完成的RBA資訊被記錄在控制檔案中。
* 增量checkpoint可以減少執行個體恢複時間。
完全checkpoint：
完全檢查點主要包括以下步驟：
①首先，在日志緩沖中确定目前的(也就是最新的)重做記錄，提取其RBA與SCN作為檢查點目标
②LGWR清空日志緩存，将重作記錄寫入線上日志
③DBWn程序将檢查點目标(RBA與SCN)産生的及檢查點目标之前産生的髒資料塊，按RBA的順序寫入資料檔案
④最後,CKPT程序将檢查點目标(RBA與SCN)寫入資料檔案的頭部和控制檔案
觸發完全檢查點的條件：
①執行shutdown immediate指令
②執行alter system checkpoint指令
③執行部分表空間維護指令：alter tablespace ...offline|online|begin backup|end backup|read only|read write
CHECKPOINT 優化
從9I開始CHECKPOINT的優化大大簡化了
設定FAST_START_MTTR_TARGET
較大的值：恢複時間較長
較小的值：增加IO負載
10g 的CHECKPOINT的自動優化
fast_start_mttr_target設定為非零的值或者不設定
![oracle中的start with connect by用法[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)