Understanding Fast-Start Checkpointing

Checkpoint parameters affect Oracle database recovery in the following ways:

• Checkpoint frequency: The more frequent the checkpoints, the less time it will take to recover the database in the event of an instance failure. This is because there will be fewer redo log records to apply during recovery. However, frequent checkpointing can also impact database performance, as it causes the DBWn process to write more dirty blocks to disk.
• Checkpoint position: The checkpoint position is the last SCN at which all committed changes have been written to the data files. If a database failure occurs, Oracle will use the checkpoint position to determine which changes need to be applied during recovery. If the checkpoint position is close to the time of the failure, then recovery will be faster. However, if the checkpoint position is far away from the time of the failure, then recovery will take longer.

The following checkpoint parameters can be used to influence checkpoint frequency and position:

1. LOG_CHECKPOINT_INTERVAL: This parameter specifies the minimum number of redo log blocks that must be generated before a checkpoint is forced.
2. FAST_START_MTTR: This parameter specifies the maximum number of redo log blocks that Oracle will write to disk before forcing a checkpoint.
3. CHECKPOINT_PROCESS: This parameter specifies the number of checkpoint processes that Oracle will use.
4. CHECKPOINT_TIMEOUT: This parameter specifies the maximum amount of time that Oracle will wait for a checkpoint to complete before forcing a new checkpoint.

It is important to configure these parameters carefully to balance the need for fast recovery with the impact on database performance. Here are some general guidelines for configuring checkpoint parameters for Oracle database recovery:

1. In high-update systems, set the LOG_CHECKPOINT_INTERVAL and FAST_START_MTTR parameters to relatively low values to minimize the amount of redo logging that needs to be processed during recovery. However, be aware that this can increase the overhead for normal database operations.
2. In systems where performance is more important than recovery time, set the LOG_CHECKPOINT_INTERVAL and FAST_START_MTTR parameters to higher values. This will reduce the overhead for normal database operations, but it will also increase the amount of redo logging that needs to be processed during recovery.
3. Set the CHECKPOINT_PROCESS parameter to a value that is appropriate for the size and workload of the database. More checkpoint processes can improve the performance of checkpoint operations, but this can also increase the overhead for normal database operations.
4. Set the CHECKPOINT_TIMEOUT parameter to a value that is appropriate for the recovery time objectives (RTOs) of the database. A shorter checkpoint timeout will result in more frequent checkpoints, which can improve recovery time. However, a shorter checkpoint timeout can also increase the overhead for normal database operations.

It is important to test and monitor the database recovery process to ensure that the checkpoint parameters are configured correctly.

Within Oracle, when a user queries the database for a specific set of records, a copy of the data is made within the database memory called the data buffers. When the user makes changes to the data or inserts additional records, the data buffer becomes dirty or changed. These changes are maintained within the memory. A copy of all transactions is maintained within the redo log buffer. Checkpointing is a process of writing the dirty buffers from the database onto the hard disk, when the redo log buffers are filled. A checkpoint happens at specific time intervals on parameter values discussed later within the lesson. After checkpointing, the redo log buffers are cleaned and ready to keep track of the next set of transactions within the database. When the buffer is filled, the information is written into the redo log files within the disk. The system process copies the online redo log files to archival storage when they are full or when a log switch occurs. In the case of a database failure, these archived redo log files are used in the recovery of a database.

To increase the performance of recovery, Fast-Start checkpointing is introduced within Oracle. Fast-Start checkpointing records the position of the redo log, from where crash or instance recovery of a database must start. The oldest dirty buffer^[1] within the buffer cache ^[2] determines this position. The Fast-Start checkpointing feature limits the number of dirty buffers and thereby limits the amount of time required for instance recovery. The lower the number of dirty buffers, the less time is required for recovery. This overhead of several dirty buffers can be defined by specifying an appropriate value for the parameter FAST_START_IO_TARGET.
A DBA can set FAST_START_IO_TARGET to n, where n is an integer limiting the number of buffers that Oracle processes during crash or instance recovery. Because the number of I/Os to be processed during recovery correlates closely to the duration of the recovery, the FAST_START_IO_TARGET parameter gives you the most precise control over the duration of the recovery.
FAST_START_IO_TARGET advances the checkpoint, because Oracle server processes use the value of FAST_START_IO_TARGET to determine how much writing to perform. The smaller the value of FAST_START_IO_TARGET, the better the recovery performance. This is because fewer blocks require recovery. If you use smaller values for this parameter, however, you impose a higher overhead during normal processing. This is because Oracle server processes must write more buffers to the disk more frequently.

FAST_START_IO_TARGET = 1000
LOG_CHECKPOINT_TIMEOUT = 1800
LOG_CHECKPOINT_INTERVAL = 0

Once the parameters are set, use the statistics from the V$INSTANCE_RECOVERY view to estimate the recovery time, then either adjust the parameter to decrease or increase the recovery time as required.
This parameter is extremely important in applications where the downtime for a database is kept to the bare minimum. The time required for instance or crash recovery is proportional to the number of dirty buffers that must be read or written during the roll forward phase^[3] . FAST_START_IO_TARGET is a dynamic initialization parameter, which limits the numbers of dirty buffers^[4] that must be read for recovery. A parameter whose value can be changed when the database is open is called a dynamic parameter. For a non-dynamic parameter, the database must be re-started for its value to take effect. A smaller value for this parameter means an increase in performance, because fewer dirty buffers are read.
Setting the value of FAST_START_IO_TARGET to zero (0) can disable Fast-Start checkpointing. The dynamic initialization parameters LOG_CHECKPOINT_INTERVAL and LOG_CHECKPOINT_TIMEOUT also influence Fast-Start checkpointing. LOG_CHECKPOINT_INTERVAL specifies the frequency of checkpoints in terms of the number of redo log file blocks that are written between consecutive checkpoints. LOG_CHECKPOINT_TIMEOUT specifies the maximum amount of time before another checkpoint occurs. The value is specified in seconds.

A checkpoint can be induced into a database by using the ALTER SYSTEM CHECKPOINT command. The SQL statement ALTER SYSTEM CHECKPOINT explicitly forces Oracle to perform a checkpoint, ensuring that all changes made by the committed transactions are written to datafiles on the disk. You can specify this clause only when your instance has the database open. Oracle does not return control until the checkpoint is complete. The next lesson describes the steps to put Fast Start on-demand rollback into effect.

Click the Quiz link below to check your understanding of Fast-Start Fault Recovery.
Faststart Faultrecovery - Quiz

[1]Dirty buffer: When a user changes the records within a transaction, that transaction within the buffer becomes dirty or changed.

[2]Buffer cache: A buffer cache is a memory area within the Oracle database, where records are processed.

[3]Roll forward phase: In this process, which happens during recovery, all transactions within the redo log files are applied to the database.

[4]Dirty buffer: When a user changes the records within a transaction, that transaction within the buffer becomes dirty or changed.