8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23ai | Misc | PL/SQL | SQL | RAC | WebLogic | Linux

Home » Articles » 9i » Here

Recovery Enhancements In Oracle9i

Minimal I/O Recovery

The speed of crash recovery is dependant on the rate at which data is read from the redo logs along with the time it takes to apply the changes to the datafiles for blocks that were dirty in the buffer cache at the time of instance failure. Processing redo log data for blocks that were not dirty in the buffer cache is unneccessary so it no longer happens in Oracle9i.

To avoid unneccessary processing the recovery phase is split into two passes. The first sequential read scans logs from the last checkpoint position to identify which data blocks contain unsaved changes and need to be recovered. This information is stored in the PGA and used when performing the second pass. The second pass reads only blocks that were identified as requiring recovery by the first pass. These blocks are processed to complete recovery of the datafiles.

Since reading the logfiles is significantly quicker than processing the blocks, the time spent doing two reads then missing out the unchanged blocks is less than processing each block, which results in quicker recovery.

Fast-Start Time-Based Recovery

Rather than wait for specific events such as log switches to trigger checkpoints, Oracle9i can be instructed to use fast-start checkpointing architecture to allow the DBWn processes to periodically write dirty buffers to disk and incrementally advance the checkpoint position. This results in a reduced Mean Time To Recovery (MTTR) and a reduction in I/O spikes associated with log switches.

The FAST_START_MTTR_TARGET initialization parameter is used to specify the number of seconds crash recovery should take. Oracle uses this target time to configure the the FAST_START_IO_TARGET and LOG_CHECKPOINT_INTERVAL parameters to reduce crash recovery time to a level as close to the target time as possible. The FAST_START_IO_TARGET, LOG_CHECKPOINT_INTERVAL and LOG_CHECKPOINT_TIMEOUT parameters should not be set as they may interfere with the process.

The maximum value for FAST_START_MTTR_TARGET is 3600 (1 hour), with values exceeding this being rounded down. There is no minimum value, but values that are too low may not be possible to achieve as this is limited by the low limit of the target number of dirty buffers, which is 1000. Added to this is the time mounting the database will take.

If the value is set too low, then the effective MTTR target will be the best MTTR target the system can achieve. If the value is set to high, the effective MTTR is estimated based on the whole buffer cache being dirty. The ESTIMATED_MTTR column in the V$INSTANCE_RECOVERY view can be used to view the effective MTTR. If the parameter setting, shown by the TARGET_MTTR column, is consistently different to the effective MTTR it should be adjusted since this means it is set at an unrealistic value.

Remember that the extra checkpointing required to reduce the crash recovery time may compromise the system performance. A balance must be reached between general system performance and crash recovery time. Set FAST_START_MTTR_TARGET to zero to disable fast-start checkpointing.

The FAST_START_IO_TARGET initialization parameter is used to specify the maximum number of dirty blocks in the buffer cache. Its use has been deprecated in favour of the FAST_START_MTTR_TARGET. In addition the DB_BLOCK_MAX_DIRTY_TARGET parameter has been removed.

Flash Freeze

Flash Freeze is a diagnostic tool that captures a diagnostic snapshot of the entire system at the time of failure the first time it occurs. The database can be restarted on another node in the cluster, or the frozen instance can be deregistered from a Real Application Cluster, leaving the frozen instance available for offline diagnostics. The gathered data can then be used to find the problem that caused the failure and prevent future failures.

Media Recovery Enhancements

In Oracle8i media recovery would fail if a corrupt redo log block was encountered, requiring point in time recovery to be restarted to an SCN preceeding the corrupt block. Oracle9i has a number of enhancements including:

Hope this helps. Regards Tim...

Back to the Top.