Instance Architecture   «Prev  Next»

Lesson 17 The Checkpoint process (CKPT)
Objective Explain function of the Checkpoint process.

Checkpoint process (CKPT)

The Checkpoint process (not surprisingly) controls database checkpoints. Every 3 seconds the Checkpoint process determines the earliest redo log entry for which changes have not been written to the database. This becomes the checkpoint, and it is recorded in the control file and in all the datafiles. The following Slide Show illustrates this process:

  1. As changes are made to the database, they are quickly recorded in the redo log.
  2. We have three redo log entries. They are all shown in blue, because DBWR has not yet written any of the changes to the datafiles.
  3. The database writer will write out some changes. Here, the changes for entries 1 and 2 have been written to the datafiles.
  4. A checkpoint is recorded every three seconds. Here the checkpoint is redo log entry 3, because all prior changes have been written.
  5. This process continues. More redo records are written
  6. More changes are written to the datafiles.
  7. and finally the checkpoint is advanced.

Checkpoint Process

The checkpoint and data recovery

Recording the checkpoint is important for recovery purposes. The checkpoint identifies the first redo log entry that Oracle will need to process in a recovery situation. All changes related to previous redo log entries have been written to the disk.

Checkpoint Process (CKPT)

When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process.
The CKPT process does not write blocks to disk; DBWn always performs that work. The statistic DBWR checkpoints displayed by the System_Statistics monitor in Enterprise Manager indicates the number of checkpoint requests completed.

Considerations with Bigfile Tablespaces

  1. Bigfile tablespaces are intended to be used with Automatic Storage Management or other logical volume managers that support dynamically extensible logical volumes and striping or RAID.
  2. Avoid creating bigfile tablespaces on a system that does not support striping because of negative implications for parallel execution and RMAN backup parallelization.
  3. Avoid using bigfile tablespaces if there could possibly be no free space available on a disk group, and the only way to extend a tablespace is to add a new datafile on a different disk group.
  4. Using bigfile tablespaces on platforms that do not support large file sizes is not recommended and can limit tablespace capacity. Refer to your operating system specific documentation for information about maximum supported file sizes.
  5. Performance of database opens, checkpoints, and DBWR processes should improve if data is stored in bigfile tablespaces instead of traditional tablespaces. However, increasing the datafile size might increase time to restore a corrupted file or create a new datafile.