Backup Recovery   «Prev  Next»
Lesson 3 Understanding Fast-Start checkpointing
Objective Describe effect that checkpoint parameters/ commands have on recovery.

Understanding Fast-Start Checkpointing

Oracle's Recovery Process

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.

Oracle RMAN Backup and Recovery

Faster recovery with checkpointing

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.

As an example, set the initialization parameter settings as follows:
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.

Forcing a checkpoint

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.

Faststart Faultrecovery - Quiz

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.