Whether the redolog switch has a full checkpoint or an incremental checkpoint

The redolog switch has a full checkpoint or incremental checkpoint. There is a lot of information on the Internet, but it is not clear whether the full checkpoint or incremental checkpoint occurs when a log switch occurs. Some people say it is a full checkpoint or an incremental checkpoint. In fact, if you have a deep understanding of the differences between the full check point and the incremental check point, You should know whether the log switch is an incremental check point or a full check point. Before 8i, oracle did perform a full checkpoint during log switch, but since 8i, oracle performed an incremental checkpoint during log switch, however, in a strict sense, it is not completely an incremental checkpoint, because in log switch, not only will the control file be updated as the incremental checkpoint, in addition, the data file header will be updated as the full checkpoint does. Next we will conduct a test together: it proves that during log switch, what happens is neither a full checkpoint nor a strict incremental checkpoint. I. First, let's verify that when a log switch occurs, it does not have a full checkpoint: Check several parameters related to the log switching checkpoint. idle> @? /Rdbms/admin/show_paraEnter value for p: _ dbwr_scan_intervalold 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 too far ------------------------------ --------- ----- _ dbwr_scan_interval dbwrit Er scan interval 300 true false FALSEidle> @? /Rdbms/admin/show_paraEnter value for p: _ disable_selftune_checkpointingold 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 has passed ---------------------------- ----------- _ d Revoke Disable self-tune checkpointing false true false FALSEidle> show parameter log_checkpoint_timeoutNAME type value before ----------- before changing parameters: idle> select group #, status from v $ log; GROUP # STATUS ---------- ---------------- 1 CURRENT 2 INACTIVE 3 INACTIVEidle> alter system switch Logfile; idle>! DateSun May 12 19:43:20 CST 2013 idle> select group #, status from v $ log; GROUP # STATUS ---------- -------------- 1 ACTIVE 2 CURRENT 3 INACTIVEidle>! DateSun May 12 19:49:25 CST 2013 idle> select group #, status from v $ log; GROUP # STATUS ---------- ---------------- 1 INACTIVE 2 CURRENT 3 INACTIVE1 log GROUP changes from ACTIVE to INACTIVE in about 5 minutes to modify the parameter can be set to alter system switch logfile; the redo log file status remains active for one day: _ dbwr_scan_interval = 24 * 3600log_checkpoint_timeout = 24 * timeout = TRUEidle> 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. Haha... Check whether it is always ACTIVEidle>! DateSun May 12 19:55:54 CST 2013 idle> select group #, status from v $ log; GROUP # STATUS ---------- -------------- 1 INACTIVE 2 INACTIVE 3 CURRENTidle> alter system switch logfile; System altered. idle> select group #, status from v $ log; GROUP # STATUS ---------- -------------- 1 CURRENT 2 INACTIVE 3 ACTIVE wait 12 hours after the switch logfile operation is completed, then execute the preceding query statement again: idle>! DateSun May 13 7:56:58 CST 2013 idle> select group #, status from v $ log; GROUP # STATUS ---------- ---------------- 1 CURRENT 2 INACTIVE 3 ACTIVE from the results, we can see that redo log group 3 is still active, my current library is a test library that is only used by me, so it is idle. If full checkpoint occurs during logfile switch, then, when I wait for 24 hours to query the v $ log again, the redo log group 3 must be in the inactive state: that is, we have now proved that when the log switch is in, not a full checkpoint occurs. Idle>! DateSun May 13 20:56:58 CST 2013 idle> select group #, status from v $ log; GROUP # STATUS ---------- -------------- 1 CURRENT 2 INACTIVE 3 INACTIVE haha... You can try the power of those parameters .. A Ratio of ox B... Now we can prove that what happens in log switch is not an incremental checkpoint in a strict sense. The incremental checkpoint only updates the control file and does not update the datafile header. If you know this, it is very good to verify. Use the BBED restoration artifact: hr @ OCP> select group #, status from v $ log; GROUP # STATUS ---------- ---------------- 1 INACTIVE 2 CURRENT 3 INACTIVEBBED> set file 1 block 1 FILE #1 BLOCK #1 BBED> p kcvfhckpstruct 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 that is, the base of the checkpoint scn of the current system01.dbf datafile header is 0x 000c592e. Now I run switch logfile once, and then observe the checkpoint scn: hr @ OCP> update employees set salary = salary + 1000; 107 rows updated of system01.dbf's datafile header. 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 kcvfhckpstruct kcvfhckp, 36 bytes @ 484 struct kcvcpscn, 8 bytes @ 484 ub4 kscnbas @ 484 0x000c592e ub2 kscnwrp @ 488 0x0000 ub4 kcvcptim @ 492 limit 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 kcv Cpetb [4] @ 516 0x00 ub1 kcvcpetb [5] @ 517 0x00 ub1 kcvcpetb [6] @ 518 0x00 ub1 kcvcpetb [7] @ 519 0x00 we found that system01.dbf's datafile header's checkpoint scn base is 0x000c592e, that is to say, when oracle switches logfile, the checkpoint does not happen immediately. oracle is waiting for a time. We force log switch checkpoint to happen immediately: hr @ OCP> alter system switch logfile; System altered. hr @ OCP> select group #, status from v $ log; GROUP # STATUS ---------- ---------------- 1 CURRENT 2 ACTIVE 3 active wait for log group 2 to become INACTIVEhr @ OCP> select group #, status from v $ log; GROUP # STATUS ---------- -------------- 1 CURRENT 2 INACTIVE 3 ACTIVEBBED> set file 1 block 1 FILE #1 BLOCK #1 BBED> p kcvfhckpstruct kcvfhckp, 36 byte S @ 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 have you seen it? Now the base of the checkpoint scn of system01.dbf's datafile header has changed to 0x000c59cf, that is, when the log switch occurs, it is not a strictly incremental checkpoint, because it not only updates the control file, but also updates the datafile header. Finally, let's look at the checkpoint type in oracle. There are seven types of checkpoints in oracle: 1. Full Checkpoint2, Thread Checkpoint3, File Checkpoint4, Object Checkpoint5, Parallel Query Checkpoint6, Incremental Checkpoint7, Log Switch Checkpoint **************** **************************************** **************************************** * ************************************ incremental checkpoint incremental checkpoint operation process because every full checkpoint needs to write all the dirty blocks in the buffer cache to the data file, in this way, a large I O consumption and frequent full checkpoint operations have a great impact on the system performance. Therefore, the incremental checkpoint concept introduced by Oracle is as follows, dirty blocks in the buffer cache will be continuously written to the disk in the order of BCQ queues, at the same time, the CKPT process checks the DBWn write progress every three seconds and records the corresponding RBA information to the control file. After incremental checkpoint is available, you do not need to apply the redo log from the full checkpoint before the crash when restoring the instance, you only need to start the recovery operation from the RBA recorded in the control file, which can save recovery time. Prerequisites for an incremental checkpoint * recovery requirement setting (FAST_START_IO_TARGET/FAST_START_MTTR_TARGET) * LOG_checkpoint_INTERVAL parameter value * LOG_checkpoint_TIMEOUT parameter value * Minimum log file size * Number of dirty blocks in buffer cache incremental checkpoint features * incremental checkpoint is a continuously active checkpoint. * There is no checkpoint RBA, because this checkpoint is always in progress, so there is no checkpoint RBA concept involved in the normal checkpoint. * Checkpoint advanced in memory only * RBA information completed by incremental checkpoint is recorded in the control file. * Incremental checkpoint can reduce the instance recovery time. Full checkpoint: the complete checkpoint mainly includes the following steps: ① first, determine the current (that is, the latest) Redo record in the log buffer, extract its RBA and SCN as the checkpoint target ② LGWR clears the log cache, and rewrites the record into the online log ③ DBWn process clears the checkpoint target (RBA and SCN) dirty data blocks generated before and before the checkpoint target are written to the data file in RBA order. ④ Finally, the CKPT process writes the checkpoint target (RBA and SCN) the conditions for triggering a full checkpoint for writing the data file header and control file: ① execute the shutdown immediate command ② execute the alter system checkpoint command ③ execute some tablespace maintenance commands: alter tablespace... offline | online | begin backup | end backup | read only | read write CHECKPOINT optimization from 9I CHECKPOINT optimization greatly simplifies setting a large value for FAST_START_MTTR_TARGET: A value with a relatively long recovery time: automatically optimized fast_start_mttr_target for CHECKPOINT with an I/o load of 10 Gb is set to a non-zero value or not set.