4
Choosing Recovery Strategies

This chapter offers guidelines and strategies to follow when preparing for database recovery, and includes the following topics:

• Recovery Concepts and Strategies
• Recovery Planning

Recovery Concepts and Strategies

Before recovering a database, familiarize yourself with the fundamental data structures, concepts and strategies of Oracle recovery. This section describes basic recovery issues, and includes the following topics:

• Important Recovery Data Structures
• Recovery Planning
• Recovery Operations

Of course, before learning about the data structures important to recovery operations, you should first understand what is meant by restoring and recovering data.

You restore a file by reconstructing or retrieving an original copy of it from a backup.

When you recover a file, you are making a restored file current, or current to a specific point in time. This process of recovery is also known as "`rolling forward."

There are two types of recovery commands:

• SQL

  The SQL RECOVER command rolls a restored file forward by applying redo (archived and online redo logs).

• Recovery Manager

  A Recovery Manager recover command rolls a restored datafile forward by applying incremental backups (if they exist) and then applying redo (archived and online redo logs).

Important Recovery Data Structures

Table 4-1 describes important data structures involved in recovery processes. Be familiar with these data structures before starting any recovery procedure.

Table 4-1 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 concurrence and redo record ordering. Think of the SCN as a timestamp that helps ensure transaction consistency.
Rollback Segments	Information in a rollback segment is used during database recovery to undo any uncommitted changes applied from the redo log to the datafiles. After the rollback segments are used to remove all uncommitted data from the datafiles, data is in a consistent state.
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 is a copy of the physical files that constitute the Oracle database. When original data is lost, you can use the backup to reconstruct the lost information.
Incremental Backups (Recovery Manager only)	An incremental backup consists of one or more datafiles containing only those blocks that have been modified since a previous backup.
Recovery Catalog (Recovery Manager only)	A repository of information used and maintained by Recovery Manager. Contains information about the following: datafile and archivelog backup sets and pieces datafile copies archived redo logs and copies of them tablespaces and datafiles at the target database user-created stored scripts
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.

Recovery Planning

Before recovering a database, you should create a recovery plan or strategy. This section describes important issues to consider when defining your plan.

Factors Determining Your Recovery Strategy

Your recovery strategy will depend upon the answers to the following questions:

• Is the Database Running in ARCHIVELOG Mode?
• What Files Were Lost or Damaged?
• Has a User Accidentally Destroyed Data?
• Have You Tested Backup and Recovery Strategies?

After answering these questions, you can choose a recovery strategy that is appropriate for your particular situation.The following sections describe the types of recovery to perform in specific situations.

Is the Database Running in ARCHIVELOG Mode?

If your database is not running in ARCHIVELOG mode, you should restore the database from a consistent database backup. This is your only option when the database is not in ARCHIVELOG mode. The control file and all datafiles are restored from a consistent backup and the database is opened. All changes made subsequent to the backup are lost.

What Files Were Lost or Damaged?

If one or more datafiles are lost, but the database stays open, you should perform tablespace (or datafile) recovery while the database is open. The tablespaces or datafiles are taken offline, restored from backups, recovered and placed online. No changes are lost and the database remains available during the recovery.

If an archive log or online log that is required for recovery is also lost, then you should perform point-in-time database or tablespace recovery.

If one or more datafiles and/or all control files are lost, and the database is not open, then you cannot use this procedure. All lost files are restored from backups, recovered and the database is opened. No changes are lost, but the database is unavailable during recovery. If an archive log or online log required for recovery is also lost, then you should perform point-in-time database recovery.

Has a User Accidentally Destroyed Data?

You should perform point-in-time database recovery when an archive log or online log required for recovery is lost, or to recover from user errors. All datafiles and the control file are restored from backups taken before the point-in-time, recovered to the point-in-time and the database is opened. All changes made subsequent to the point-in-time are lost. If the database remains open and no tablespaces that contain rollback segments are lost, you can also use point-in-time tablespace recovery.

Point-in-Time Tablespace Recovery

All changes made to the recovered tablespaces after the point-in-time are lost. The database, excluding the recovered tablespaces, is available during recovery.

Have You Tested Backup and Recovery Strategies?

You should test your backup and recovery strategies in a test environment before moving to a production system. You should continue to test your system regularly. That way, you can test the thoroughness of your strategies and later avoid real-life crises. Performing test recoveries regularly ensures that your archiving and backup procedures work. It also keeps you familiar with recovery procedures, so that you are less likely to make mistakes in a crisis.

Recovery Operations

Media recovery restores a database's datafiles to a point-in-time before disk failure, and includes the committed data in memory that was lost due to failure. Following is a list of media recovery operations:

• Complete Media Recovery

  Complete media recovery includes the application of all necessary redo or incremental backups ever generated for the particular incarnation of the database being recovered. Complete media recovery can be performed on offline datafiles while the database is open. Complete media recovery may require an open resetlogs operation if a backup control file is included in the recovery, or a resetlogs operation creating a new control file has been performed. Types of complete media recovery are:

  • Closed Database Recovery
  • Open-Database, Offline-Tablespace Recovery
  • Open-Database, Offline-Tablespace, Individual Datafile Recovery
• Incomplete Media Recovery

  Incomplete media recovery produces a version of the database as it was at some time in the past. Incomplete media recovery must either continue on to become a complete media recovery, or be terminated by an open resetlogs operation that creates a new incarnation of the database. The database must be closed for incomplete media recovery operations. Types of incomplete media recovery are:

  • Time-based Recovery

    You specify the point in time to recover to

  • Cancel-based Recovery

    You decide to cancel during the recovery operation

  • Change-based Recovery

  For Recovery Manager, types of incomplete media recovery are:

  • Time-based Recovery
  • Change-based Recovery
  • Log Sequence Recovery (replaces cancel-based recovery, above)

    Recovers up to a specified log sequence number

---