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 series of images illustrates this process:

1)As changes are made to the database, they are quickly recorded in the redo log
1) As changes are made to the database, they are quickly recorded in the redo log, but are not immediately written out to the datafiles.

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.
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 entires 1 and 2 have been written to the datafiles.
3) The database writer will write out some changes. Here, the changes for entires 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.
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.
5) This process continues. More redo records are written.

6) More changes are written to the datafiles.
6) More changes are written to the datafiles.

7) The Checkpoint is advanced
7) The checkpoint is advanced.


Checkpoint process (CKPT)

You can see the Oracle background processes with this query: 
select *  
from
   v$session
where
   type ='BACKGROUND';

Here are some of the most important Oracle background processes:
ARCH (Optional) Archive process writes filled redo logs to the archive log location(s). In RAC, the various ARCH processes can be utilized to ensure that copies of the archived redo logs for each instance are available to the other instances in the RAC setup should they be needed for recovery.
CJQ - Job Queue Process (CJQ) - Used for the job scheduler. The job scheduler includes a main program (the coordinator) and slave programs that the coordinator executes. The parameter job_queue_processes controls how many parallel job scheduler jobs can be executed at one time.
CKPT: Checkpoint process writes checkpoint information to control files and data file headers
CQJ0: Job queue controller process wakes up periodically and checks the job log. If a job is due, it spawns Jnnnn processes to handle jobs.
DBWR: Database Writer or Dirty Buffer Writer process is responsible for writing dirty buffers from the database block cache to the database data files. Generally, DBWR only writes blocks back to the data files on commit, or when the cache is full and space has to be made for more blocks. The possible multiple DBWR processes in RAC must be coordinated through the locking and global cache processes to ensure efficient processing is accomplished.
FMON: The database communicates with the mapping libraries provided by storage vendors through an external non-Oracle Database process that is spawned by a background process called FMON. FMON is responsible for managing the mapping information. When you specify the FILE_MAPPING initialization parameter for mapping data files to physical devices on a storage subsystem, then the FMON process is spawned.
LGWR: Log Writer process is responsible for writing the log buffers out to the redo logs. In RAC, each RAC instance has its own LGWR process that maintains that instance thread of redo logs.
LMON: Lock Manager process
MMON: The Oracle 10g background process to collect statistics for the Automatic Workload Repository (AWR).
MMNL: This process performs frequent and lightweight manageability-related tasks, such as session history capture and metrics computation.
MMAN: is used for internal database tasks that manage the automatic shared memory. MMAN serves as the SGA Memory Broker and coordinates the sizing of the memory components.
PMON: Process Monitor process recovers failed process resources. If MTS (also called Shared Server Architecture) is being utilized, PMON monitors and restarts any failed dispatcher or server processes. In RAC, PMON role as service registration agent is particularly important.
Pnnn: (Optional) Parallel Query Slaves are started and stopped as needed to participate in parallel query operations.
RBAL: This process coordinates rebalance activity for disk groups in an Automatic Storage Management instance.
SMON: System Monitor process recovers after instance failure and monitors temporary segments and extents. SMON in a non-failed instance can also perform failed instance recovery for other failed RAC instance.
WMON: The "wakeup" monitor process

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

SEMrush Software