Oracle recovery Internal principles (Overview)

Oracle 7 v7.2 recovery outline

Author: Andrea Borr & Bill Bridge

Versions: 1 May 3, 1995

Summary

This topic describes how to recover a database in Oracle 7.2. Readers of this article should be familiar with the management guide of Oracle 7.2. Compared with the management guide, this document aims to describe the algorithms, data structures, and technical details used for Oracle restoration in more detail.

Articles: Oracle recovery Internal principles http://www.bkjia.com/search.aspx? Where = nkey & keyword = 19824

I. Introduction

Oracle databases provide database recovery in the following two failed modes:

1. instance failure: Data in Oracle data cache or in memory is lost

2. Media failure: database files are lost.

For any failure scenario in the above two modes, to ensure Database Consistency during restoration, there are some prerequisites that must be met.

Although the recovery process has something in common, the difference in the prerequisites also makes the recovery execution quite different:

1. instance recovery: recover lost data in the Oracle Data Cache

2. Media recovery: recover lost data in database files

1.1 common mechanisms for instance recovery and media recovery

Both instance recovery and media recovery depend on the redo log. Redo logs are composed of some redo log threads. There is only one redo thread to reload logs in a single instance environment, and each instance in the parallel server environment has a redo thread.

A redo log thread refers to a group of files stored on the operating system, the file records all changes made to the database by the instance-submitted changes and unsubmitted changes (the latter indicates that there are data block changes in the Oracle data cache ). Because the instance has modified the blocks in the rollback segment, the rollback segment changes are also recorded in the redo log thread.

The first step of instance recovery and media recovery is rollback. Rollback is at the database recovery level. During the rollback process, the changes recorded in the redo log are re-applied to the data file. Because the rollback segment changes are also recorded in the redo log, the rollback segment is rebuilt during the rollback process. At the end of the current rollback, all changes recorded in the redo log are applied to the data file. At this moment, data blocks not only contain submitted data, but also some uncommitted data.

The second step of instance recovery and media recovery is rollback. Roll back tasks at the Database Transaction layer. During the rollback process, the modifications made by uncommitted transactions caused by rollback recorded in the rollback segment will be revoked.

1.2 instance failure and recovery, crash failure and recovery

Instance failure means that when the instance is suddenly terminated (for example, shutdown abort or the host loses power), the content in the instance data cache will be lost.

Crash failure means that all instances of the database fail at the same time. Failure of an instance in a single instance Environment is equivalent to failure of a crash. Crash recovery refers to restoring all instances to the consistent state before the crash. All of this is automatically performed after the alter database open command, and the user cannot intervene.

If an instance fails, the Database Consistency is impaired because it causes the dirty data of the instance to be lost. The so-called "dirty data" means that the data block content in the instance data cache is newer than that in the data file. When the instance crashes, it is not time to write dirty data into the data file. The reason for this dirty data loss problem is that Oracle's Cache Management adopts an algorithm that is conducive to transaction processing performance rather than preventing instance crashes. The following Cache Management Algorithms for performance tuning make instance recovery a bit complicated:

1. LRU (least recently used) cache replacement algorithm

2. Do not force the dirty data to be refreshed to the data file during submission

The damage caused by the above algorithm to the database integrity when the instance fails is reflected in the following points:

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

B. When the instance crashes, the data file may contain some uncommitted transaction modification blocks.

C. When the instance crashes, some committed transaction modification blocks may not be refreshed to the data file. The data file contains the data blocks before the transaction is modified.

During instance recovery, the database recovery layer repairs the damage points A and C, and then the Database Transaction Layer repairs the damage point B.

1 2 Next Page