zoukankan      html  css  js  c++  java
  • 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
    idle> @?/rdbms/admin/show_para
    Enter value for p: _disable_selftune_checkpointing
    old  12:     AND upper(i.ksppinm) LIKE upper('%&p%')
    new  12:     AND upper(i.ksppinm) LIKE upper('%_disable_selftune_checkpointing%')
    P_NAME                                   P_DESCRIPTION                                      P_VALUE                
    ISDEFAULT ISMODIFIED ISADJ
    ---------------------------------------- -------------------------------------------------- 
    ------------------------------ --------- ---------- -----
    _disable_selftune_checkpointing          Disable self-tune checkpointing                    FALSE                  
    TRUE      FALSE       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
    idle> !date
    Sun May 12 19:49:25 CST 2013
    idle> select group#,status from v$log;
        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;
    System altered.
    idle> alter system set "_disable_selftune_checkpointing"=true;
    System altered.
    哈哈。。。可以观察一下是不是一直是ACTIVE
    idle> !date
    Sun May 12 19:55:54 CST 2013
    idle> select group#,status from v$log;
        GROUP# STATUS
    ---------- ----------------
             1 INACTIVE
             2 INACTIVE
             3 CURRENT
    idle> ALTER SYSTEM SWITCH LOGFILE;
    System altered.
    idle> select group#,status from v$log;
        GROUP# STATUS
    ---------- ----------------
             1 CURRENT
             2 INACTIVE
             3 ACTIVE


    执行完上述switch logfile操作后等待12小时,然后再次执行上述查询语句:
    idle> !date
    Sun May 13 7:56:58 CST 2013
    idle> select group#,status from v$log;
        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的时候,发生的不是完全检查点。
    idle> !date
    Sun May 13 20:56:58 CST 2013
    idle> select group#,status from v$log;
        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;
    System altered.
    hr@OCP> select group#,status from v$log;
        GROUP# STATUS
    ---------- ----------------
             1 INACTIVE
             2 ACTIVE
             3 CURRENT


    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,也就是说oracle在switch logfile的
    时候的checkpoint并不是马上发生,oracle在等待一个发生的时机。
    我们现在强制让log switch checkpoint马上发生:
    hr@OCP> alter system switch logfile;
    System altered.
    hr@OCP> select group#,status from v$log;
        GROUP# STATUS
    ---------- ----------------
             1 CURRENT
             2 ACTIVE
             3 ACTIVE
    等待日志组2变成INACTIVE
    hr@OCP> select group#,status from v$log;
        GROUP# STATUS
    ---------- ----------------
             1 CURRENT
             2 INACTIVE
             3 ACTIVE
    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      0x000c59cf
          ub2 kscnwrp                           @488      0x0000
       ub4 kcvcptim                             @492      0x3097eb6d
       ub2 kcvcpthr                             @496      0x0001
       union u, 12 bytes                        @500     
          struct kcvcprba, 12 bytes             @500     
             ub4 kcrbaseq                       @500      0x0000003b
             ub4 kcrbabno                       @504      0x00000002
             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已经变成了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设置为非零的值或者不设置

  • 相关阅读:
    Django第一天上课笔记
    easyui-datebox 只能获取当前日期以前的日期
    身份证号码 正则表达式 jquery
    动态修改属性设置 easyUI
    easyUi onLoadSuccess:、onChange这些事件不能嵌套使用!!!!
    jstl无法调用js
    decode
    easyui-panel 滚动条禁用
    js文件引用js文件
    硬编码
  • 原文地址:https://www.cnblogs.com/javawebsoa/p/3074828.html
Copyright © 2011-2022 走看看