Introduction to Oracle Recovery internal principles

Oracle 7 v7.2 Recovery outline

Author: Andrea Borr & Bill Bridge

Version: 1 May 3, 1995

This article provides an overview of how Oracle 7.2 releases database recovery. Readers of this article should be familiar with the Oracle 7.2 Management Guide. The purpose of this article is to provide a more detailed description of the algorithms, data structures, and technical details used by Oracle recovery than the Administration Guide.

First, Introduction

The Oracle database provides database recovery in the following two types of failure modes:

1. Instance failure: Loss of data in the Oracle data cache or in-memory data

2. Media failure: Missing database file

Either of the above two modes of failure scenario, in the recovery time to ensure database consistency, there are some prerequisites must be met.

Although the process of recovery has some common ground, the differences in the prerequisites make a significant difference in the execution of the recovery:

1. Instance recovery: Recovering data lost in the Oracle data cache

2. Media recovery: Recovering data lost from database files

1.1 Common mechanisms for instance recovery and media recovery

Both instance recovery and media recovery depend on the redo log. The redo log consists of some redo log threads. Redo logs in a single-instance environment have only one redo thread, and each instance in a parallel server environment has a redo thread.

A redo log thread refers to a set of files stored on the operating system that record all changes made to the database by that instance-committed changes and uncommitted changes (which means that the data block changes in the Oracle data buffer are also present). Because the instance also modifies the block in the rollback segment, changes to the rollback segment are also recorded in the Redo log thread.

The first step in instance recovery and media recovery is roll forward. Roll forward belongs to the database recovery level. In the process of rolling forward, the data changes recorded in the redo log are applied to the data file again. Because changes to the rollback segment are also recorded in the Redo log, the roll forward process will also rebuild the rollback segment block. At the end of the current rollback, all changes recorded in the redo log are applied to the data file. At the moment, the data block not only contains the data that has been submitted, but also contains some uncommitted data.

The second step in instance recovery and media recovery is rollback. Rollback a task that is part of the database transaction layer. In the rollback process, changes recorded in the rollback segment from uncommitted transactions that are caused by the roll forward are revoked.

1.2 Instance failure and recovery, crash failure and recovery

Instance failure means that the contents of the instance data cache are lost when the instance terminates abruptly (for example, because the shutdown abort or the host loses power).

Crash failure means that all instances of the database fail at the same time. Instance failure in a single-instance environment is equivalent to a crash failure. Crash recovery refers to restoring all instances to a consistent state before the crash. This is done automatically after the command ALTER DATABASE open, and the user cannot intervene.

An instance failure can compromise the consistency of the database because it results in the loss of dirty data for that instance. The so-called "dirty data" means that the contents of the data block in the instance data cache are newer than those on the data file. When the instance crashes, there is no time to write dirty data to the data file. The problem with this dirty data loss is that Oracle's cache management employs algorithms that favor transactional performance rather than preventing instances from crashing. The following cache management algorithms for performance tuning make the instance recovery process somewhat complicated:

1. LRU (least recently used) cache replacement algorithm

2. Do not force dirty data to be flushed to the data file at the time of submission

The above algorithm causes damage to the database integrity when the instance fails in the following points:

A. When an instance crashes, the data file may contain part of all blocks not all of the block in which an atomic transaction is modified

B. When an instance crashes, a data file may contain blocks of uncommitted transaction modifications

C. In the case of a crash, some of the blocks that have committed a transaction modification may not have been flushed to the data file, which contains the blocks of data before the transaction was modified.

During the instance recovery process, the database recovery layer fixes the damage points A and C above, and then the subsequent database transaction layer fixes the damage point B.

In addition to the prerequisites for repairing database integrity damage, instance recovery needs to meet some prerequisites:

1. Instance recovery must be restored on the online data file.

2. Instance recovery must use the online redo log file and cannot require an archive redo log file. Although instance recovery can also be recovered by using the archive Redo log file (except that the database runs in a non-archive mode), the recovery process is not automatic when the user is required to restore the archived log files first.

3. The invocation of the instance recovery process is automatic and is invoked at the next time the database is started.

4. The file or repair process that detects the repair during the instance recovery process itself is automatic and requires no human intervention.

5. The length of roll forward in instance recovery is determined by the internal mechanism (checkpoint) and user-configured parameters of the Oracle database (such as the size and number of log files, frequency of checkpoint, parameters for parallel restores, and so on).