Fundamental Recovery Concepts and Strategies

• Important Recovery Data Structures

• Recovery Operations

• Recovery Planning and Strategies

Important Recovery Data Structures

Data Structure	Description
Control File	The control file contains records that describe and maintain information about the physical structure of a database. The control file is updated continuously during database use, and must be available for writing whenever the database is open. If the control file is not accessible, the database will not function properly.
System Change Number (SCN)	The system change number is a clock value for the Oracle database that describes a committed version of the database. The SCN functions as a sequence generator for a database, and controls concurrency and redo record ordering. Think of the SCN as a timestamp that helps ensure transaction consistency.
Redo Records	A redo record is a group of change vectors describing a single, atomic change to the database. Redo records are constructed for all data block changes and saved on disk in the redo log. Redo records allow multiple database blocks to be changed so that either all changes occur or no changes occur, despite arbitrary failures.
Redo Logs	All changes to the Oracle database are recorded in redo logs, which consist of at least two redo log files that are separate from the datafiles. During database recovery from an instance or media failure, Oracle applies the appropriate changes in the database's redo log to the datafiles; this updates database data to the instant that the failure occurred.
Backup	A database backup consists of operating system backups of the physical files that constitute the Oracle database. To begin database recovery from a media failure, Oracle uses file backups to restore damaged datafiles or control files.
Checkpoint	A checkpoint is a data structure in the control file that defines a consistent point of the database across all threads of a redo log. Checkpoints are similar to SCNs, and also describe which threads exist at that SCN. Checkpoints are used by recovery to ensure that Oracle starts reading the log threads for the redo application at the correct point. For Parallel Server, each checkpoint has its own redo information.

Table 24 - 1. Important Recovery Data Structures

See Also: For more information about these and other data structures, see the Oracle7 Server Concepts manual.

Recovery Operations

• Media Recovery

• Closed Database Recovery

• Open-Database, Offline-Tablespace Recovery

• Open-Database, Offline-Tablespace, Individual Datafile Recovery

• Cancel-Based Recovery

• Time-Based Recovery

• Change-Based Recovery

Recovery Planning and Strategies

Test Backup and Recovery Strategies

Determine What Type of Recovery Operation Is Appropriate

• Media failure has damaged your database.

• You need to recover to a point-in-time in the past (for example, undo an erroneous operational or programmatic change to the database).

• You have lost online logs.

1. What recovery operations are available?

The answer to this first question depends on whether your database is archiving redo logs.

• If the database is in ARCHIVELOG mode, several recovery operations are available.

• If the database is in NOARCHIVELOG mode, usually only one recovery operation is available, which is to restore the most recent full backup and re-enter all work performed since the backup. (If you have used Export to supplement regular backups, you can instead use Import to restore data.) Some special losses are easier to repair.

2. What recovery operations are appropriate for this particular problem?

If the database is in ARCHIVELOG mode, several recovery operations are available to restore a damaged database to a transaction-consistent state.

3. Is the damaged database part of a distributed database?

If so, database recovery may need to be coordinated among the nodes of the distributed database.

4. Are disaster recovery procedures in place?

If you have lost all of your online media, or have determined that your recovery time will be too long, you may want to activate your standby database rather than perform media recovery on your primary database.

Moving Datafiles

Type of File	Section Name	See
Datafile	Renaming and Relocating Datafiles for Tablespace
Online Redo Log File	Renaming and Relocating Online Redo Log Members
Control File	Creating Additional Copies of the Control File, and Renaming or Relocating Control Files

Table 24 - 2. Damaged File Restoration

Coordinate Distributed Recovery

Type of Recovery Operation	Implication for Distributed Database System
Restoring a full backup for a database that was never accessed (updated or queried) from a remote node	Use non-coordinated, autonomous database recovery.
Restoring a full backup for a database that was accessed by a remote node	Shut down all databases and restore them using the same coordinated full backup.
Complete media recovery of one or more databases in a distributed database	Use non-coordinated, autonomous database recovery.
Incomplete media recovery of a database that was never accessed by a remote node	Use non-coordinated, autonomous database recovery.
Incomplete media recovery of a database that was accessed by a remote node	Use coordinated, incomplete media recovery to the same global point-in-time for all databases in the distributed database.

Table 24 - 3. Database Recovery in a Distributed Database System

Coordinate Time-Based and Change-Based Distributed Database Recovery In special circumstances, one node in a distributed database may require recovery to a past point-in-time. To preserve global data consistency, it is often necessary to recover all other nodes in the system to the same point-in-time. This is called "coordinated, time-based, distributed database recovery." The following tasks should be performed with the standard procedures of time-based and change-based recovery described in this chapter.

1. Recover the database that requires the recovery operation using time-based recovery. For example, if a database needs to be recovered because of a user error (such as an accidental table drop), recover this database first using time-based recovery. Do not recover the other databases at this point.

2. After you have recovered the database and opened it using the RESETLOGS option, look in the ALERT file of the database for the RESETLOGS message.

If the message is, "RESETLOGS after complete recovery through change nnnnnnnn," you have applied all the changes in the database and performed a complete recovery. Do not recover any of the other databases in the distributed system, or you will unnecessarily remove changes in them. Recovery is complete.

If the reset message is, "RESETLOGS after incomplete recovery UNTIL CHANGE nnnnnnnn," you have successfully performed an incomplete recovery. Record the change number from the message and proceed to the next step.

3. Recover all other databases in the distributed database system using change-based recovery, specifying the change number (SCN) from Step 2.

Recover Database with Snapshots If a master database is independently recovered to a past point in time (that is, coordinated, time-based distributed database recovery is not performed), any dependent remote snapshot that was refreshed in the interval of lost time will be inconsistent with its master table. In this case, the administrator of the master database should instruct the remote administrators to perform a complete refresh of any inconsistent snapshot.