Professional Documents
Culture Documents
Applies To:: Checkpoint Tuning and Troubleshooting Guide (Doc ID 147468.1)
Applies To:: Checkpoint Tuning and Troubleshooting Guide (Doc ID 147468.1)
Applies To:: Checkpoint Tuning and Troubleshooting Guide (Doc ID 147468.1)
1
Copyright (c) 2020, Oracle. All rights reserved. Oracle Confidential.
APPLIES TO:
PURPOSE
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT
It also explains how to interpret and handle checkpoint errors: 'Checkpoint not Complete' and 'Cannot Allocate New Log'
reported in the ALERT<sid>.LOG file.
DETAILS
Contents:
1. What is a Checkpoint?
2. Checkpoints and Performance
3. Parameters related to incremental checkpointing
4. Redo logs and Checkpoint
5. Understanding Checkpoint Error messages ("Cannot allocate new log" and "Checkpoint not complete")
6. Oracle Release Information
7. Using Statspack to determine Checkpointing Problems
1. What is a Checkpoint?
A Checkpoint is a database event which synchronizes the modified data blocks in memory with the datafiles on
disk. It offers Oracle the means for ensuring the consistency of data modified by transactions. The mechanism
of writing modified blocks on disk in Oracle is not synchronized with the commit of the corresponding
transactions.
A checkpoint has two purposes: (1) to establish data consistency, and (2) enable faster database recovery.
How is recovery faster? Because all database changes up to the checkpoint have been recorded in the datafiles,
making it unnecessary to apply redo log entries prior to the checkpoint. The checkpoint must ensure that all the
modified buffers in the cache are really written to the corresponding datafiles to avoid the loss of data
which may occur with a crash (instance or disk failure).
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=2whn9zwj2_118&id=147468.1 1/6
7/6/2020 Document 147468.1
This bulletin assumes that performance is your number one priority and so
recommendations are made accordingly. Therefore, your goal is to minimize the frequency
of checkpoints through tuning.
- FAST_START_MTTR_TARGET
- LOG_CHECKPOINT_INTERVAL
- LOG_CHECKPOINT_TIMEOUT
- LOG_CHECKPOINTS_TO_ALERT
Recommendations are also given for handling "checkpoint not complete" messages
found in the alert log, which indicate a need to tune redo logs and
checkpoints.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=2whn9zwj2_118&id=147468.1 2/6
7/6/2020 Document 147468.1
FAST_START_MTTR_TARGET
LOG_CHECKPOINT_INTERVAL
This parameter also impacts the time required to complete a database recovery
operation during the roll forward phase of recovery. The actual recovery time
is dependent upon this time, and other factors, such as the type of failure
(instance or system crash, media failure, etc.), and the number of archived
redo logs which need to be applied. setting and the estimated number of I/Os that would be
resulted by the current workload under other MTTR settings. This view helps
the user to assess the trade-off between runtime performance and setting
FAST_START_MTTR_TARGET to achieve better recovery time.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=2whn9zwj2_118&id=147468.1 3/6
7/6/2020 Document 147468.1
LOG_CHECKPOINT_TIMEOUT
LOG_CHECKPOINTS_TO_ALERT
See Note:76713.1 to have more detail on How those instance parameters can influence the checkpoint.
Oracle recommends the user to set all online log files to be the same size,
and have at least two log groups per thread. The alert log is a valuabletool for
monitoring the rate that log switches occur, and subsequently, checkpoints
occur.
If redo logs switch every 3 minutes, you will see performance degradation.
This indicates the redo logs are not sized large enough to efficiently handle
the transaction load.
See Note:1038851.6 for further detail on how to estimate an adequate size of the redolog files. See
Note:1035935.6 Example of How To Resize the Online Redo Logfiles
5. Understanding Checkpoint Error messages ( Cannot allocate new log and Checkpoint not complete )
Sometimes, you can see in your alert.log file, the following corresponding
messages:
This message indicates that Oracle wants to reuse a redo log file, but
the current checkpoint position is still in that log. In this case, Oracle must
wait until the checkpoint position passes that log. Because the
incremental checkpoint target never lags the current log tail by more than 90%
of the smallest log file size, this situation may be encountered if DBWR writes
too slowly, or if a log switch happens before the log is completely full,
or if log file sizes are too small.
When the database waits on checkpoints,redo generation is stopped until the
log switch is done.
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=2whn9zwj2_118&id=147468.1 5/6
7/6/2020 Document 147468.1
Statspack snapshots can be taken every 15 minutes or so, these reports gather useful
information about number of checkpoints started and checkpoints completed and number
of database buffers written during checkpointing for that window of time . It also contains
statistics about redo activity. Gathering and comparing these snapshot reports gives you
a complete idea about checkpointing performance at different periods of time.
Another important thing to watch in statspack report is the following wait events,
they could be a good indication about problems with the redo log throughput and checkpointing:
In the case when one or more of the above wait events is repeated frequently
with considerable values then you need to take an action like adding More
online redo log files or increasing their sizes and/or modifying checkpointing parameters.
REFERENCES
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=2whn9zwj2_118&id=147468.1 6/6