天天看點

redolog switch會發生完全檢查點還是增量檢查點?

     網上有很多資料都沒有說清楚發生log switch的時候,到底完全檢查點還是增量檢查點。有人說是完全檢查點,也有人說是增

量檢查點。其實如果你深入了解完全檢查點和增量檢查點的的差別,就應該知道log switch到底是增量檢查點還是完全檢查點。

     在8i以前,log switch的時候oracle确實是會做完全檢查點;但從8i開始,oracle在log switch的時候做的是增量檢查點,但

從嚴格意義上來說并不能完全算是增量檢查點,因為在log switch的時候,不僅會像增量檢查點那樣更新控制檔案,而且還會像完

    下面我們來一起來做做測試:證明了在log switch的時候,發生的既不是完全檢查點,也不是嚴格意義上的增量檢查點。

一、我們首先來驗證在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;

         1 ACTIVE

         2 CURRENT

Sun May 12 19:49:25 CST 2013

         1 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

         3 CURRENT

idle> ALTER SYSTEM SWITCH LOGFILE;

         3 ACTIVE

執行完上述switch logfile操作後等待12小時,然後再次執行上述查詢語句:

Sun May 13 7:56:58 CST 2013

從結果裡我們可以看到現在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

哈哈。。。你可以試試,那些參數的威力。。牛B的一比。。。

現在我們來證明在log switch的時候,發生的不是嚴格意義上的增量檢查點。增量檢查點隻會更新control file,不會更新

datafile header,知道這個那就很好驗證了,利用BBED恢複神器:

hr@OCP>  select group#,status from v$log;

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;

         2 ACTIVE

BBED> set file 1 block 1 

我們發現現在的system01.dbf的datafile header的checkpoint scn的base還是0x000c592e,也就是說oracle在switch logfile的

時候的checkpoint并不是馬上發生,oracle在等待一個發生的時機。

我們現在強制讓log switch checkpoint馬上發生:

等待日志組2變成INACTIVE

      ub4 kscnbas                           @484      0x000c59cf

   ub4 kcvcptim                             @492      0x3097eb6d

         ub4 kcrbaseq                       @500      0x0000003b

         ub4 kcrbabno                       @504      0x00000002

看到了嗎?現在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都需要把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設定為非零的值或者不設定

繼續閱讀