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.
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.
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.