Oracle Checkpoint Process

After the instance has been allocated the memory structure, loads the control file, then wants to open the database, needs to do the control file, the data file, the online redo log maintains the mutual state consistency, the database can open. When an instance of the database shuts down (such as when the system is powered down or shutdown abort is closed), the Oracle database has a mechanism to do this for instance recovery.

Like any company, different employees have different skills and responsibilities for different jobs, but a successful project requires a good project manager to maintain and supervise the members of the project to work in unison with each other. In Oracle instances, such an important role is assumed by the checkpoint (CheckPoint) process (CKPT). Oracle instance when necessary, the checkpoint occurs, when the checkpoint appears, the CKPT process on the one hand to urge the DBWR process in a timely manner before the checkpoint time Db_buffer some of the modified data in a timely manner to write data files, after writing, CKPT The synchronization point of the process update related data files and control files. That is, during the operation of the Oracle instance, the CKPT process is required to periodically synchronize the "point-in-time" of the control files, data files, and online log files.

Most relational databases have the advantage of performance by "not forcing modifications to the block at the time of submission" but rather "writing log files in the form of a record (in redo log)" when committing. Another description of this sentence is: When the user commits the transaction, the write data file is "asynchronous", and the Write log file is "synchronous". This can cause the database instance to crash when the modified data in the Db_buffer in memory may not be written to the data block. When the database is reopened, recovery is required to recover the state of the data in DB Buffer and to ensure that the data that has been committed is written to the data block. Checkpoints are an important mechanism in this process to determine which redo logs should be scanned and applied to recovery when recovering.

Three steps to the operation of the checkpoint and checkpoint process:

A, the system triggers a checkpoint, the system and records the checkpoint time of the checkpoint SCN number, and records that moment modified DB buffer block referenced by RBA as Checkpoint RBA RBA (Redo Byte Address).

B, the checkpoint RBA before the log entity referenced by the Db_buffer in the data block modification, to be written out into the data file.

C, after completing the 2 steps, the CKPT process logs the checkpoint completion information to the control file.

Only the above three steps are completed to indicate that the system checkpoint has been advanced, advancing the log files, data files, control files to a new "sync Point".

Checkpoints only occur in the following situations:

Admin use: Alter system checkpoint command;

The instance is closed normally;

Special Note: Log switching does not cause a full checkpoint to occur.

How to determine which data blocks in the Db_buffer need to be written to disk is a pretty complex algorithm. The general idea is that all dirty data is linked to a list in the ascending order of low RBA, and when the ckpt is awakened, the last check point is first read from the control file and the dirty data of the intermediate time is written to disk.

Ii. conditions for triggering

It is necessary to understand the difference between the two concepts "full checkpoint and incremental checkpoint".

Incremental checkpoint (incremental checkpoint)
Oracle8 later launched the incremental checkpoint mechanism, in the previous version of every checkpoint will be a full thread checkpoint, so that all dirty data will be written to disk, huge i/ O has a significant impact on system performance. To solve this problem, Oracle introduced the checkpoint queue mechanism, and each dirty block is moved to the checkpoint queue, which is arranged according to the Low Rdb (the first time the block address of the redo is modified). The low RBA value of the data block near the end of the checkpoint queue is minimal, and if the pieces are modified again, the order in the checkpoint queue does not change, guaranteeing that the sooner the modified block is written to disk. Every 3 seconds ckpt will update the control files and data files to record checkpoint execution.

In the running Oracle data, there are many events, conditions, or parameters that trigger checkpoints. Like what
L When the routine has been closed through normal transaction processing or immediate option; (Shutdown immediate or shutdown normal;)
L when forced by setting initialization parameters Log_checkpoint_interval, log_checkpoint_timeout and Fast_start_io_target;
l When the database administrator requests it manually; (ALter system checkpoint)

L alter tablespace ... offline;

L per log switchover; (alter system switch logfile)

It should be stated that the ALTER system switch logfile will also trigger the occurrence of a full checkpoint.

ALTER DATABASE datafile. Offline does not trigger the checkpoint process.

If it is a simple offline datafile, then the file checkpoint will not be triggered, and only the file checkpoint will be triggered for offline tablespace, which is why online datafile needs media Recovery and online tablespace not required.

For the table space after the offline online this situation, it is better to do a mandatory checkpoint better.

In several cases, a full checkpoint is triggered, prompting DBWR to write all dirty data to the data file before the checkpoint time.

In addition, the database during normal operation does not produce a full checkpoint, and many of the following events result in incremental checkpoints, such as:

Before the online hot backup data file, the modified block in the data file is required to be written to the data file from Db_buffer. So, issue such a command:

L ALTER tablespace tablespace_name BIGEN backup & end Backup; The local checkpoint associated with the tablespace's data file will also be triggered;

L ALTER tablespace tablespace_name READ only;

L ALTER tablespace tablespace_name OFFLINE NORMAL;

The command will trigger an incremental check point.

Third, the influence factor of checkpoint position

In contrast to traditional checkpoints (that is, checkpoints that have a clear meaning), incremental checkpoints can be gentle, persistent, and synchronous to the synchronization point of the log files and data files. Understanding this is a key point in learning about Checlpoint principles. In fact, for incremental checkpoints, the main discussion is not when incremental checkpoints occur, but rather: how do you control the rate of incremental checkpoint propulsion? A checkpoint is essentially a push to write logs and write data.

The synchronization of the "asynchronous mechanism" of the file, the content of our interest boils down to the following: When the system crashes, how much time does the "Async distance" require the system to recover? In fact, this is exactly what Oracle is designed for, and the database provides some parameter settings (Oracle 9.2 for example)

A, fast_start_mttr_target parameters to control the boost rate of the incremental checkpoint

We all hope that when the instance crashes, the log stream that needs to be read is as short as possible, and the recovery takes as little time as possible. In this way, we will have a small fast_start_mttr_target setting, and the incremental checkpoint will appear more dense and frequent. However, the setting value is too small, will increase the amount of DBWR write data file, the increase of write data file I/O will reduce the performance of the system, reduce the "write log files and write data file asynchronous mechanism" brings the performance benefits.

It is difficult to explain how setting fast_start_mttr_target is the appropriate setting, which is related to our respective database application business. Oracle provides a view v$mttr_target_advice as our setting reference, from which Oracle will give some estimates when you set different fast_start_mttr_target values, An estimate of the number of physical write data files that correspond. We can choose a suitable value, can reduce the recovery time, but does not let DBWR the work to increase too much.

The database changes in the "transaction", and the Oraccle database system uses the system change number, which is the SCN, to record changes within the database. Many events within the database, as well as changes in the database content by the user through SQL statements, can increase the SCN value.

We know that when an application commits a transaction, the log write process (LGWR) writes the record of the transaction in log Buffer to the online redo log file successfully before it is notified by the service process that the related user process is successful.

The checkpoint appears, which pushes changes to the data block referenced in the log file before the checkpoint time, which has been DBWR written to the data file. The CKPT process records the checkpoint SCN information for that checkpoint into data files and control files. Thus driving a "synchronization point" of the database. If the database fails before the next synchronization point completes, the instance recovery from the database begins with the current checkpoint of the system, using the subsequent logs for instance recovery.

As you can see, the presence of checkpoints can make the database run, "Periodic" Maintenance log files, data files for state consistency. Some are similar to our lives: the regular accounts of different companies are settled, and when a checkpoint is completed, everyone acknowledges that all the accounts before this time have been settled.

Oracle Checkpoint Process