3
Developing a Backup and Recovery Strategy

This chapter offers guidelines and considerations for developing an effective backup and recovery strategy. It includes the following topics:

• Developing a Backup Strategy

• Developing a Recovery Strategy

Developing a Backup Strategy

Before you create an Oracle database, decide how to protect the database against potential media failures. If you do not develop a backup strategy before creating your database, you may not be able to perform recovery if a disk failure damages the datafiles, online redo log files, or control files.

This section describes general guidelines that can help you decide when to perform database backups and which parts of a database you should back up. Of course, the specifics of your strategy depend on the constraints under which you are operating. No matter which backup strategy you implement, however, follow these guidelines whenever possible:

• Obeying the Golden Rule of Backup and Recovery

• Choosing the Database Archiving Mode

• Multiplexing Control Files, Online Redo Logs, and Archived Redo Logs

• Performing Backups Frequently and Regularly

• Performing Backups When You Make Structural Changes

• Backing Up Often-Used Tablespaces

• Performing Backups After Unrecoverable/Unlogged Operations

• Performing Whole Database Backups After Opening with the RESETLOGS Option

• Archiving Older Backups

• Knowing the Constraints for Distributed Database Backups

• Exporting Data for Added Protection and Flexibility

• Avoiding the Backup of Online Redo Logs

Obeying the Golden Rule of Backup and Recovery

The set of files needed to recover from the failure of any Oracle database file--a datafile, control file, or online redo log--is called the redundancy set. The redundancy set contains:

• The last backup of all the database files

• All archived redo logs generated after the last backup was taken

• A duplicate of the online redo log files generated by Oracle multiplexing, operating system mirroring, or both

• A duplicate of the current control file generated by Oracle multiplexing, operating system mirroring, or both

• Configuration files such as initialization parameter file, tnsnames.ora, and listener.ora

The golden rule of backup and recovery is: the set of disks or other media that contain the redundancy set should be separate from the disks that contain the datafiles, online redo logs, and control files. This strategy ensures that the failure of a disk that contains a datafile does not also cause the loss of the backups or redo logs needed to recover the datafile. Consequently, a minimal production-level database requires at least two disk drives: one to hold the files in the redundancy set and one to hold the main database files.

Always keep the redundancy set separated from the primary files in every way possible: on separate volumes, separate file systems, and separate RAID devices. These systems are very reliable, but they can and do fail. Keeping the redundancy set separate ensures that you can recover from a failure without losing committed transactions.

You can implement a system that follows the golden rule in several different ways. Oracle recommends following these guidelines:

• Multiplex the online redo log files and current control file at the Oracle level, not only at the operating system or hardware level. Multiplexing at the Oracle level has the advantage that an I/O failure or lost write should only corrupt one of the copies.

• Use operating system or hardware mirroring for at least the control file, because Oracle does not provide complete support for control file multiplexing: if one multiplexed copy of the control file fails, then Oracle shuts down.

• Use operating system or hardware mirroring for the primary datafiles if possible to avoid having to apply media recovery for simple disk failures.

• Keep at least one copy of the entire redundancy set--including the most recent backup--on hard disk. With disk prices steadily dropping, this strategy is economical for many installations.

  If the redundancy copy is generated by splitting a mirror, then it is not as good as a backup generated through operating system or RMAN commands because it relies on the mirroring subsystem for both the primary files and redundancy set copy. The last real file backup, such as the last backup to tape, is the redundancy set copy. Therefore, keep archived redo logs starting with this copy.

• If your database is stored on a RAID device, then place the redundancy set on a set of devices that is not in the same RAID device.

Choosing the Database Archiving Mode

Before you create an Oracle database, decide how you plan to protect it against potential failures. Answer the following questions:

• Is it acceptable to lose any data if a disk failure damages some of the files that constitute a database? If not, run the database in ARCHIVELOG mode, ideally with a multiplexed online redo log, a multiplexed control file, and multiplexed archive redo logs. If you can afford to lose a limited amount of data, you can operate in NOARCHIVELOG mode and avoid the extra maintenance chores.

• Will you need to recover to a non-current time? If you need to perform incomplete recovery to correct an erroneous change to the database, run in ARCHIVELOG mode and perform control file backups whenever making structural changes. Incomplete recovery is helped by having a backup control file reflecting the database structure at the desired time.

• Does the database need to be available at all times? If so, do not operate the database in NOARCHIVELOG mode because the required whole database backups, taken while the database is shutdown, cannot be made frequently, if at all. Therefore, high-availability databases always operate in ARCHIVELOG mode to take advantage of open datafile backups.

Once you have answered these questions and have determined which mode to use, follow the guidelines for either:

• Backing Up a NOARCHIVELOG Database

• Backing Up an ARCHIVELOG Database

Backing Up a NOARCHIVELOG Database

If you operate your database in NOARCHIVELOG mode, Oracle does not archive filled groups of online redo log files. Therefore, the only protection against a disk failure is the most recent whole backup of the database. Follow these guidelines:

• Plan to make whole database backups regularly, according to the amount of work that you can afford to lose. For example, if you can afford to lose the amount of work accomplished in one week, make a consistent whole database backup once per week. If you can afford to lose only a day's work, make a consistent whole database backup every day. For large databases with a high amount of activity, you usually cannot afford to lose work. In this case, you should operate the database in ARCHIVELOG mode.

• Whenever you alter the physical structure of a database operating in NOARCHIVELOG mode, immediately take a consistent whole database backup. A whole database backup fully reflects the new structure of the database.

Backing Up an ARCHIVELOG Database

If you run your database in ARCHIVELOG mode, ARCn archives groups of online redo log files. Therefore, the archived redo log coupled with the online redo log and datafile backups can protect the database from a disk failure, providing for complete recovery from a disk failure to the instant that the failure occurred (or, to the desired non-current time). Following are common backup strategies for a database operating in ARCHIVELOG mode:

• Perform a whole database backup of the entire database after you create it. This initial whole database backup is the foundation of your backups because it provides backups of all datafiles and the control file of the associated database.

  Note: When you perform this initial whole database backup, make sure that the database is in ARCHIVELOG mode first. Otherwise, the backup control files will contain the NOARCHIVELOG mode setting.

• Make open database or tablespace backups to keep your database backups up-to-date. Subsequent whole database backups are not required, and if a database must remain open at all times, whole database backups while the database is closed are not feasible.

• Make open or closed datafile backups to update backed up information for the database. Doing so supplements the initial whole database backup. In particular, back up the datafiles of extensively used tablespaces frequently to reduce database recovery time. If a more recent datafile backup restores a damaged datafile, you need to apply less redo data (or incremental backups) to the restored datafile to roll it forward to the time of the failure.

  Whether you should take open or closed datafile backups depends on the availability requirements of the data. Open datafile backups are the only choice if the data being backed up must always be available.

  You can also use a datafile copy taken while the database is open and the tablespace is online to restore datafiles. You must apply the appropriate redo log files to these restored datafiles to make the data consistent and bring it forward to the specified point in time.

• Make a control file backup every time you make a structural change to the database. If you are operating in ARCHIVELOG mode and the database is open, use either RMAN or the ALTER DATABASE statement with the BACKUP CONTROLFILE option.

Multiplexing Control Files, Online Redo Logs, and Archived Redo Logs

The control file, online redo log, and archived redo log are crucial files for backup and recovery operations. The loss of any of these files can cause you to lose data irrevocably. You should maintain:

• At least two copies of the control file on different disks mounted under different disk controllers. You can either use Oracle to multiplex the copies or your operating system to mirror them.

• Two or more copies of your online redo log on different disks. The online redo data is crucial for instance, crash, and media recovery.

• Two or more copies of your archived redo log on different disks and, if possible, different media.

  See Also: Chapter 2, "Managing Data Structures" to learn how to integrate data structure management into your backup and recovery strategy, and Oracle8i Concepts for a thorough conceptual overview of all Oracle data structures.

Performing Backups Frequently and Regularly

Frequent backups are essential for any recovery scheme. Base the frequency of backups on the rate or frequency of database changes such as:

• Addition and deletion of tables.

• Insertions and deletions of rows in existing tables.

• Updates to data within tables.

If users generate a significant amount of DML, database backup frequency should be proportionally high. Alternatively, if a database is mainly read-only, and updates are issued only infrequently, you can back up the database less frequently.

Use either Recovery Manager or operating system methods to create backup scripts. RMAN scripts, which are stored in the recovery catalog, are an especially efficient method for performing routine, repetitive backup operations.

See Also: Oracle8i Recovery Manager User's Guide and Reference to learn how to create, delete, replace, and print stored scripts.

Performing Backups When You Make Structural Changes

Administrators as well as users make changes to a database. If you make any of the following structural changes, then perform a backup of the appropriate portion of your database immediately before and after completing the alteration:

• Create or drop a tablespace.

• Add or rename a datafile in an existing tablespace.

• Add, rename, or drop an online redo log group or member.

The part of the database that you should back up depends on your archiving mode:

Mode	Action
ARCHIVELOG	Make a control file backup (using the ALTER DATABASE statement with the BACKUP CONTROLFILE option) before and after a structural alteration. Of course, you can back up other parts of the database as well.
NOARCHIVELOG	Make a consistent whole database backup immediately before and after the modification.

Backing Up Often-Used Tablespaces

Many administrators find that regular whole database backups are not in themselves sufficient for a robust backup strategy. If you run in ARCHIVELOG mode, then you can back up the datafiles of an individual tablespace or even a single datafile. This option is useful if a portion of a database is used more extensively than others, for example, the SYSTEM tablespace and tablespaces that contain rollback segments.

By making more frequent backups of the extensively used datafiles of a database, you avoid a long recovery time. For example, you may make a whole database backup once a week on Sunday. If your database experiences heavy traffic during the week, a media failure on Friday can force you to apply a tremendous amount of redo data during recovery. If you had backed up your most frequently accessed tablespaces three times a week, you can apply a smaller number of changes to roll the restored file forward to the time of the failure.

Performing Backups After Unrecoverable/Unlogged Operations

If users are creating tables or indexes using the UNRECOVERABLE option, make backups after the objects are created. When tables and indexes are created as UNRECOVERABLE, Oracle does not log redo data, which means that you cannot recover these objects from existing backups.

Note: If using RMAN, then you can make an incremental backup.

See Also: Oracle8i SQL Reference for information about the UNRECOVERABLE option of the CREATE TABLE ... AS SELECT and CREATE INDEX statements.

Performing Whole Database Backups After Opening with the RESETLOGS Option

After you have opened a database with the RESETLOGS option, Oracle recommends that you immediately perform a whole database backup. If you do not, and a disaster occurs, then you lose all changes made after opening the database.

See Also: "What Is a RESETLOGS Operation?" for more information about RESETLOGS operations, and "Recovering a Pre-RESETLOGS Backup" to learn the special circumstances that allow you to recover a pre-RESETLOGS backup.

Archiving Older Backups

You should store older backups for two basic reasons:

• An older backup is necessary for perform incomplete recovery to a time before your most recent backup.

• Your most recent backup is corrupted.

If you want to recover to a non-current time, then you need a database backup that completed before the desired time. For example, if you make backups on the 1st and 14th of February, then decide at the end of the month to recover your database to February 7th, you must use the February 1st backup.

For a database operating in NOARCHIVELOG mode, the backup that you use should be a consistent whole database backup. Of course, you cannot perform media recovery using this backup. For a database operating in ARCHIVELOG mode, your whole database backup:

• Does not need not be consistent because redo is available to recover it.

• Should have completed before the intended recovery time (the control file should reflect the database's structure at the point-in-time of recovery).

• Should have all archived logs necessary to recover the datafiles to the required point-in-time.

For added protection, keep two or more database backups (with associated archived redo logs) previous to the current backup. Thus, if your most recent backups are not usable, you will not lose all of your data.

WARNING: After you open the database with the RESETLOGS option, you cannot use existing backups for subsequent recovery beyond the time when the logs were reset. You should therefore shut down the database and make a consistent whole database backup. Doing so will enable recovery of database changes after using the RESETLOGS option.

Knowing the Constraints for Distributed Database Backups

If your database is a node in a distributed database, all databases in the distributed database system should operate in the same archiving mode. Note the following consequences and constraints:

Mode	Constraint	Consequence
ARCHIVELOG	Closed cleanly.	Backups at each node can be performed autonomously, that is, individually and without time coordination.
NOARCHIVELOG	Closed cleanly.	Consistent whole database backups must be performed at the same global time to plan for global distributed database recovery. For example, if a database in New York is backed up at midnight EST, the database in San Francisco should be backed up at 9 PM PST.

Exporting Data for Added Protection and Flexibility

Because the Oracle Export utility can selectively export specific objects, consider exporting portions or all of a database for supplemental protection and flexibility in a database's backup strategy. This strategy is especially useful for recovery catalog backups when using RMAN.

Note that Database exports are not a substitute for whole database backups and cannot provide the same complete recovery advantages that the built-in functionality of Oracle offers.

See Also: Oracle8i Utilities for a complete account of the Export utility.

Avoiding the Backup of Online Redo Logs

Although it may seem that you should back up online redo logs along with the datafiles and control file, this technique is dangerous. You should not back up online redo logs for the following reasons:

• The best method for protecting the online logs against media failure is by multiplexing them, that is, having multiple log members per group, on different disks and disk controllers.

• If your database is in ARCHIVELOG mode, then ARCn is already archiving the redo logs.

• If your database is in NOARCHIVELOG mode, then the only type of backups that you should perform are closed, consistent, whole database backups. The files in this type of backup are all consistent and do not need recovery, so the online logs are not needed.

The danger in backing up online redo logs is that you may accidentally restore them while not intending to. A number of situations are possible in which restoring the online logs cause significant problems to the database. Following are two scenarios that illustrate how restoring backed up online logs severely compromises recovery.

Scenario 1: Unintentionally Restoring Online Redo Logs

When a crisis occurs, it is easy to make a simple mistake. DBAs and system administrators frequently encounter dangers during a database restore. When restoring the whole database, you can accidentally restore the online redo logs, thus overwriting the current logs with the older, useless backups. This action forces you to perform an incomplete recovery instead of the intended complete recovery, thereby losing the ability to recover valuable transactions contained in the overwritten redo logs.

Scenario 2: Erroneously Creating Multiple Parallel Redo Log Timelines

You can unintentionally create multiple parallel redo log timelines for a single instance database. You can avoid this mistake, however, by making it so that the online logs cannot be restored. You must open the database with the RESETLOGS option, which effectively creates the new redo logs, and also a new database incarnation.

If you face a problem where the best course of action is to restore the database from a consistent backup and not perform any recovery, then you may think it is safe to restore the online logs and thereby avoid opening the database with the RESETLOGS option. The problem is that the database eventually generates a log sequence number that was already generated by the database during the previous timeline.

If you then face another disaster and need to restore from this backup and roll forward, you will find it difficult to identify which log sequence number is the correct one. If you had reset the logs, then you would have created a new incarnation of the database. You could only apply archived redo logs created by this new incarnation to this incarnation.

For example, say that the most recent archived log for database PROD has a log sequence number of 100. Assume that you restore a backup of the database along with backed up online redo logs and then do not open with the RESETLOGS option. Assume also that the restored online log is at log sequence 50. Eventually, the database archives a log with the log sequence number of 100--so you now have two copies of log 100 with completely different contents. If you are forced to recover this database, then you may inadvertently restore the wrong series of archived logs, thereby corrupting the database.

Note: Recovery Manager and EBU do not back up online redo logs.

Developing a Recovery Strategy

Oracle provides a variety of procedures and tools to assist you with recovery. To develop an effective recovery strategy, do the following:

• Testing Backup and Recovery Strategies

• Planning Your Response to Non-Media Failures

• Planning Your Response to Media Failures

Testing Backup and Recovery Strategies

Practice backup and recovery techniques in a test environment before and after you move to a production system. In this way, you can measure the thoroughness of your strategies and minimize problems before they occur in a real situation. Performing test recoveries regularly ensures that your archiving, backup, and recovery procedures work. It also helps you stay familiar with recovery procedures, so that you are less likely to make a mistake in a crisis.

If you use Recovery Manager, use the duplicate command to create a test database using backups of your production database. To learn how to duplicate a database, see Oracle8i Recovery Manager User's Guide and Reference.

Planning Your Response to Non-Media Failures

Although media recovery is your primary concern when developing your recovery strategy, you should understand the basic types of non-media failures as well as the causes and solutions for each:

• Statement Failure

• User Process Failure

• User Error

• Instance Failure

Statement Failure

A statement failure is a logical failure in the handling of a statement in an Oracle program. The Oracle database server or the operating system usually returns an error code and a message when a statement failure occurs. Table 3-1 shows typical causes and resolutions for statement failures.

Table 3-1 Typical Causes and Resolutions for Statement Failures

Problem	Solution
A logical error occurred in an application.	Fix the program that generated the error so that its logic flows correctly. You may need to enlist the aid of developers to solve this type of problem.
A user attempted to enter illegal data into a table.	Modify the illegal SQL statement and reissue it.
A user attempted an operation with insufficient privileges, for example, attempting to insert data into a table when the user has only SELECT privileges.	Provide the necessary database privileges for the user to complete the statement successfully.
A user attempted to create a table but exceed the allotted quota limit.	Issue an ALTER USER statement to change the quota limit.
A user attempted a table INSERT or UPDATE, causing an extent to be allocated without sufficient free space in the tablespace.	Add space to the tablespace. You can also use the RESIZE and AUTOEXTEND options for datafiles.

User Process Failure

A user process failure is any failure in a user program accessing an Oracle database. User processes can fail for a wide variety of reasons. Some typical scenarios include:

• A user performed an abnormal disconnection in the session.

• The user's session was abnormally terminated. For example, the user rebooted the client while connected to a database in a client-server configuration.

• The user's program raised an address exception that terminated the session.

In most cases, you do not need to act to resolve user process failures: the user process simply fails to function but does not affect Oracle and other user process. The PMON background process is usually sufficient for cleaning up after an abnormally terminated user process.

User Error

Users errors are any mistakes that users make in adding data to or deleting data from the database. Typical causes of user error are:

• A user accidentally drops or truncates a table.

• A user deletes all rows in a table.

• A user commits data, but discovers an error after the data is committed.

If you have a logical backup of a table from which data has been lost, sometimes you can simply import it back into the table. Depending on the scenario, however, you may have to perform some type of incomplete media recovery to correct such errors.

You can perform either database point-in-time recovery (DBPITR) or tablespace point-in-time recovery (TSPITR). The following table explains the difference between these types of incomplete recovery:

Type	Description	Procedure
DBPITR	Restore backup database. Roll forward to the time just before the error. Open RESETLOGS.	For operating system recovery, see "Performing Incomplete Media Recovery". See Also: For RMAN recovery, see Oracle8i Recovery Manager User's Guide and Reference.
TSPITR	Create auxiliary instance. Recover the tablespace on the auxiliary to the time just before the error. Import data back into the primary database.	For operating system TSPITR, see Chapter 7, "Performing Operating System Tablespace Point-in-Time Recovery". See Also: For RMAN TSPITR, see Oracle8i Recovery Manager User's Guide and Reference.

Instance Failure

Instance failure occurs when an instance abnormally terminates. An instance failure can occur because:

• A power outage causes the server to crash.

• The server becomes unavailable because of hardware problems.

• The operating system crashes.

• One of the Oracle background processes fails.

• You issue a SHUTDOWN ABORT statement.

Fortunately, Oracle performs instance recovery automatically: all you need to do is restart the database. Oracle automatically detects that the database was not shut down cleanly, then applies committed and uncommitted redo records in the redo log to the datafiles and rolls back uncommitted data. Finally, Oracle synchronizes the datafiles and control file and opens the database.

Planning Your Response to Media Failures

Media failure is the biggest threat to your data. A media failure is a physical problem that occurs when a computer unsuccessfully attempts to read from or write to a file necessary to operate the database. Common types of media problems include:

• A disk drive that holds one of the database files experiences a head crash.

• A datafile, online or archived redo log, or control file is accidentally deleted, overwritten, or corrupted.

The technique you use to recover from media failure depends heavily on the type of media failure that occurred. For example, the strategy you use to recover from a corrupted datafile is different from the strategy for recovering from the loss of your control file.

The basic steps for media recovery are:

• Determine which files to recover.

• Determine the type of media recovery required: complete or incomplete, open database or closed database.

• Restore backups or copies of necessary files: datafiles, control files, and the archived redo logs necessary to recover the datafiles.

  Note: If you do not have a backup, then you can still perform recovery if you have the necessary redo log files and the control file contains the name of the damaged file. If you cannot restore a file to its original location, then you must relocate the restored file and inform the control file of the new location.

• Apply redo records (and/or incremental backups when using Recovery Manager) to recover the datafiles.

• Reopen the database. If you perform incomplete recovery, then you must open the database in RESETLOGS mode.

  See Also: Oracle8i Recovery Manager User's Guide and Reference to learn how to perform media recovery using RMAN, and Chapter 5, "Performing Media Recovery" to learn how to perform media recovery using operating system methods.

Determine Which Files to Recover

The first step is to determine what to recover. Some types of failure are obvious: for example, the hardware crashes and you need to recover the entire database. In other cases, a single datafile becomes corrupted. Often you can use the table V$RECOVER_FILE to determine what requires recovery.

Choose a Type of Recovery

When you perform media recovery, you choose either complete recovery or incomplete recovery. 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. 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, also called point-in-time recovery (PITR), produces a version of the database as it was at some time in the past. Incomplete media recovery must either continue on to become complete media recovery, or be terminated by a RESETLOGS operation that creates a new incarnation of the database. The database must be closed for incomplete media recovery operations. You can perform:

  • time-based recovery, which recovers the data up to a specified point in time.

  • cancel-based recovery, which recovers until you issue the CANCEL statement.

  • change-based recovery, which recovers up to a specified SCN.

  • log sequence recovery, which recovers up to a specified log sequence number.

One important and special type media recovery is tablespace point-in-time recovery (TSPITR). TSPITR enables you to recover one or more tablespaces to a point-in-time that is different from the rest of the database.

The type of recovery method you use depends on the situation. Table 3-2 displays typical scenarios and strategies.

Table 3-2 Typical Media Failures and Recovery Strategies

Lost Files	Archiving Mode	Status	Strategy
One or more datafiles	NOARCHIVELOG	Closed	Restore whole database from a consistent database backup. The control file and all datafiles are restored from a consistent backup and the database is opened. All changes made after the backup are lost. Note: The only time you can recover a database in NOARCHIVELOG is when you have not already overwritten the online log files that were current at the time of the most recent backup.
One or more datafiles and an online redo log	NOARCHIVELOG	Closed	Restore whole database from consistent backup. You will lose all changes made since the last backup.
One or more datafiles and all control files	NOARCHIVELOG	Closed	Restore whole database and control file from consistent backup. You will lose all changes made since the last backup.
One or more datafiles	ARCHIVELOG	Open	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.
One or more datafiles and an online redo log required for recovery	ARCHIVELOG	Closed	Perform incomplete recovery of the database up to the point of the lost online redo log.
One or more datafiles and an archived redo log required for recovery	ARCHIVELOG	Open	Perform TSPITR on the tablespaces containing the lost datafiles up to the point of the latest available redo log.
One or more datafiles and/or all control files	ARCHIVELOG	Not open	Restore the lost files from backups and recover the datafiles. No changes are lost, but the database is unavailable during recovery.
One or more datafiles and/or all control files, as well as an archived or online redo log required for recovery	ARCHIVELOG	Not open	Perform incomplete recovery of the database. You will lose all changes contained in the lost log and in all subsequent logs.

Restore Backups of Datafiles and Necessary Archived Redo Logs

The method you use to restore backups depends on whether you use RMAN or operating system methods to back up your data. If you use operating system methods, then you need to identify which files need to be restored and manually copy the backups to their necessary location. If you use RMAN, then issue a restore command and let RMAN take over the transfer of data.

If the database is shut down and you restore one of the datafiles with a backup, either because of a media failure or because for some reason you want to recover the database to a non-current time, Oracle detects an inconsistency between the checkpoint SCN in the datafile headers and the datafile header checkpoint SCNs recorded in the control file at database open time. Oracle then selects the lowest checkpoint SCN recorded in the control file and datafile headers and asks you to begin media recovery starting from a specified log sequence number. You cannot open the database if any of the online datafiles needs media recovery.

There is only one case in which Oracle will tell you that you need to perform media recovery when you do not. If a tablespace is in hot backup mode because you issued the ALTER TABLESPACE ... BEGIN BACKUP statement and the system crashes, then on the next startup Oracle will issue a message stating that media recovery is required. Media recovery is not really required here, however, since you did not restore a backup; in this case, avoid media recovery by issuing the ALTER DATAFILE ... END BACKUP statement. Note that RMAN backups do not have this problem.

See Also: Oracle8i Recovery Manager User's Guide and Reference to learn how to restore backups using RMAN, "Restoring Files" to learn how to restore datafiles using operating system methods.

Begin Media Recovery

You have a choice between two basic methods for recovering physical files. You can:

• Use RMAN to automate recovery.

• Execute SQL or SQL*Plus statements.

Obviously, the recovery method you choose is contingent on which backup method you use. For example, if you backed up your files using:

• The RMAN backup command, then you must use the RMAN restore and recover commands for recovery, since these backups are in an RMAN-specific format.

• The RMAN copy command, then you can use either RMAN or operating system methods for recovery.

• Operating system commands, then you must use your operating system utility for restoring files and the RECOVER (SQL*Plus) or ALTER DATABASE RECOVER (SQL) statements for recovering them.

  Note: The only exception is for operating system backups that are image copies on disk. If you register these image copies as datafile copies with RMAN, then RMAN can restore them.

Recovering with RMAN

RMAN is a powerful tool that can aid in backup and recovery operations. Using RMAN for recovery allows you to:

• Restore and recover both file copies and RMAN-specific backup sets.

• Minimize administration errors by using the recovery catalog.

• Use RMAN's incremental backup feature to minimize recovery time.

• Generate comprehensive reports on previous backups, datafile copies, unrecoverable files, etc.

• Use scripts stored in the file system or recovery catalog to automate jobs.

• Cooperate with a media manager to restore backups from tape.

  See Also: Oracle8i Recovery Manager User's Guide and Reference to learn how to perform RMAN recovery.

Recovering with the SQL*Plus RECOVER Statement

If you do not use RMAN, then you can use operating system methods to restore your backups and SQL*Plus statements to perform media recovery. You can use SQL*Plus statements to:

• Recover both operating system copies and files generated with the RMAN copy command.

• Maintain manual control over media recovery.

You can use three basic SQL*Plus statements for recovery:

• RECOVER DATABASE

• RECOVER TABLESPACE

• RECOVER DATAFILE

Note that each of these is also a sub-clause of an ALTER DATABASE statement. Oracle recommends using the SQL*Plus RECOVER statement rather than the ALTER DATABASE statement with the RECOVER clause. For more information about the SQL*Plus RECOVER statement, see SQL*Plus User's Guide and Reference.

Each statement uses the same criteria to determine whether files are recoverable. If Oracle cannot get the lock for a file it is attempting to recover, it signals an error. This signal prevents two recovery sessions from recovering the same file and prevents media recovery of a file that is in use.

See Also: "Using Media Recovery Statements" to learn about the differences between the SQL ALTER DATABASE RECOVER and SQL*Plus RECOVER statements.