http://www.cnoug.org/viewthread.php?tid=21969
Post-owner: WANGHai
Checkpoint What is CheckPoint? checkpoint is a database event, which refreshes the modified data from the cache to disk and updates the control file and data file. When did you take CheckPoint? We know that checkpoint will brush the dirty data, but when will checkpoint? In the following cases, CheckPoint is triggered. 1. When the switch occurs when a log group 2. When meet LOG_CHECKPOINT_TIMEOUT, LOG_CHECKPOINT_INTERVAL, fast_start_io_target, fast_start_mttr_target time parameters 3. When running ALTER SYSTEM SWITCH LOGFILE 4. When running when ALTER SYSTEM CHECKPOINT 5. When run alter tablespace XXX When Begin Backup, End Backup 6. When running Alter TableSpace, DataFile Offline; incremental checkpoint (incremental checkpoint) Oracle8 launched an incremental checkpoint mechanism, you will be a Full Thread every time checkpoint in the previous version. Checkpoint, this kind of dirty data will be written to disk, huge I / O brings a big impact on system performance. In order to solve this problem, Oracle introduces the CheckPoint Queue mechanism, each dirty block will be moved to the checkpoint queue, follow the Low RDB (the first time to modify the corresponding redo block address), close to the checkpoint queue The LOW RBA value of the tail end is the smallest, and if these flaps are again modified, it does not change the order in the checkpoint queue, so that the earlier, the sooner, the sooner, the sooner it is written. Every 3 seconds CKPT will update the control files and data files to record the case execution of CheckPoint.
Complete checkpoint data dictionary select * from X $ KCCRT where indx = 0; ADDR INDX INST_ID RTNUM RTSTA RTCKP_SCN RTCKP_TIM RTCKP_THR RTCKP_RBA_SEQ RTCKP_RBA_BNO RTCKP_RBA_BOF RTCKP_ETB RTOTF RTOTB RTNLF RTLFH RTLFT RTCLN RTSEQ RTENB RTETS RTDIS RTDIT RTLHP RTSID RTOTS -------- ---------- -------------------------------------- ------ ------------------------------- ------------ ----------------------- - - ---------- ------------------------- - ---------- ------------------------- ------------------------------------- ---------------------------- 4084B228 0 1 1 15 720368521 06/25/2004 18:49:37 1 949 2 16 0600000000000000 2 0 3 1 3 1 949 1 05/16/2004 13: 29:03 0 1389 TBDB2IN1 06/12/2004 12:30:50 Here show the last full checkpoint is at 06/25/2004 18:49:37, so we inference 06/25/2004 18:49 : 37 A log switch has occurred, and then go to the operating system to see the archive of production, and there is an archive production at 18:49.
-rw-r ----- 1 oracle oinstall 83532800 Jun 25 18:49 1_948.dbf incremental checkpoint SQL> select * from X $ KCCCP where indx = 0; ADDR INDX INST_ID CPTNO CPSTA CPFLG CPDRT CPRDB CPLRBA_SEQ CPLRBA_BNO CPLRBA_BOF CPODR_SEQ CPODR_BNO CPODR_BOF CPODS CPODT CPODT_I CPHBT CPRLS CPRLC CPMID CPSDR_SEQ CPSDR_BNO CPSDR_ADB -------------------------- - -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------- -------------------------------------- ---------- -------------------------------------- ------------------------------------------------------------ ---- -------------------------------------------------------------------------------------------------------------------------- - - ---------- ---------- 4084B45C 0 1 1 2 0 10762 29753 949 76847 0 949 106814 0 721554970 06/25/2004 21:05:10 529794310 529036227 1 526310932 1413781667 949 1 0 Here shown Low-RBA, ON-Disk RBA, CHEC KPoint Time and other information. Biti_Rainy:
Every 3 seconds CKPT will update the control files and data files to record the case execution of CheckPoint. Here, you should only update the control file, every 3 seconds are not updated data files say that the execution of Checkpoint is recorded. This statement is correct, but not enough, it should be said that due to the principle of incremental checkpoints and checkpoint que, CKPT process each time Just telling DBWR, writing Dirty Buffer will always write to the latest location, just telling DBWR a checkpoint queen in the checkpoint queue, and the CKPT is reported in the control file in the control file. Location. This makes it, for example, when the database is to be restored (Instance Recovery) can start recovery from this latest location, not the recovery from the CheckPoint SCN in the data file, which will shorten the recovery time, especially in the case of instance crash. In addition, it should be noted that when the checkpoint occurs, the CKPT will update the data file header and the control file, which is not updated in the current checkpoint, but writes the last DBWR written in the completed checkpoint. When the SCN update occurs, that is, the update control file and the data file header are lagging behind the checkpoint. This is also easy to understand from the principle of recovery, because the DIRTY BUFFER has not been written yet, Naturally, I can't update it immediately into the current SCN. JerrySun turn:
something about checkpoint queue latchwanghai, the following is just for your reference:) Firstly we have two queue structures associated with checkpoints - the checkpoint queue - or thread queue - (CKPTQ), and the file queue.For each buffer to be checkpointed,. it is linked to these two queues. The CKPTQ contains all buffers that need to be checkpointed for this instance. The File queue contains all buffers that belong to a specific file that need to be checkpointed. There is one file queue per file. The file queues are used by tablespace checkpoint requests.Both these queues constitute a set of checkpoint queues.Before a process can put a buffer on a checkpoint queue, it must make sure that the queue is not being used. There is one checkpoint queue latch per set of checkpoint queues, that is used to control access to these queues. to reduce contention on this latch, the set of thread and file queues is replicated as per the number of working sets for the instance.The determination of the number of working sets has changed across the DB versions. For 9.2, the default number is calculatedinternally as #CPUs / 2 * 8. The maximum of DBWR's (db_writer_processes) you can have at 9.2 is 20. Working sets are assigned to DBWR's In a round-robinfashion at startup. For the relationship between checkpoint queue and Write List, please refer to
http://blog.9cbs.net/biti_rainy/archive/2004/08/01/learn_oracle_20040801_1.aspx
