Release 8.1.5
A67773-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Backup and Recovery Guide Release 8.1.5 A67773-01 |
|
This chapter offers guidelines and considerations for developing an effective backup and recovery strategy. It includes the following topics:
When developing your backup strategy, you need to know which types of backups you can perform. In each type of physical backup you either back up a file or group of files. This section defines and describes:
Logical Backups, also known as exports, are described in detail in Oracle8i Utilities.
A whole database backup should include backups of the control file along with all database files that belong to a database. Whole database backups are the most common type of backup.
Whole database backups do not require you to operate the database in a specific archiving mode. Before performing whole database backups, however, be aware of the implications of backing up in ARCHIVELOG and NOARCHIVELOG modes (see "Choosing Between NOARCHIVELOG and ARCHIVELOG Mode").
Whole database backups can be consistent or inconsistent. This section contains the following topics:
See Also: For detailed procedures for backing up a database using RMAN commands, see Chapter 8, "Making Backups and Copies with Recovery Manager".
For detailed procedures for backing up a database using O/S commands, see Chapter 13, "Performing Operating System Backups".
A consistent backup of a whole database is a backup in which all read-write datafiles and control files have been checkpointed with respect to the same SCN. In addition, all the online, read-write datafiles are not "fuzzy," i.e., do not contain changes beyond the SCN in the header. Oracle determines whether a restore backup is consistent by checking all the datafile headers against the datafile header information contained in the control file.
The control files and datafiles are made consistent during a database checkpoint. The only tablespaces in a consistent backup that are allowed to have older SCNs are read-only and offline normal tablespaces, which are still consistent with the other datafiles in the backup because no changes have been made to these tablespaces and so no recovery is required. If the offline datafile's checkpoint SCN matches the offline-SCN in the control file, then Oracle know the datafile needs no redo.
The important point is that you can open the database after restoring a consistent whole database backup without applying redo logs because the data is already consistent: no action is required to make the data in the restored datafiles correct. Consequently, you can restore a year-old consistent backup of your database without performing media recovery and without Oracle performing instance recovery.
The only way to make a consistent whole database backup is to shut down the database cleanly and make the backup while the database is closed. If a database is not shut down cleanly, e.g., an instance fails or you issue a SHUTDOWN ABORT statement, the database's datafiles are always inconsistent--unless you opened the database in read-only mode. Instance recovery will be required at open time.
A consistent whole database backup is the only valid backup option for databases running in NOARCHIVELOG mode, because otherwise redo will need to be applied to create consistency--and in NOARCHIVELOG mode Oracle overwrites redo records without archiving them first.
To make a consistent database backup current or to take it to a non-current point in time, perform media recovery. If you use a current control file for recovery, Oracle starts media recovery beginning at the lowest checkpoint SCN in the datafile headers; if you use a backup control file, Oracle starts media recovery using the lowest of the following: the control file SCN and the lowest SCN in the datafile headers.
To perform media recovery either apply archived redo logs or, if you are using Recovery Manager, apply incremental backups and/or archived logs. All redo data is located in the archived and online redo logs.
An inconsistent backup of a whole database is a backup in which all read-write datafiles and control files have not been checkpointed with respect to the same SCN. For example, one datafile header may contain an SCN of 100 while others contain an SCN of 95. Oracle will not open the database until these SCNs are made consistent, i.e., until all changes recorded in the online redo logs have been made to the datafiles.
If your database must be up and running 24 hours a day, 7 days a week, you have no choice but to perform inconsistent backups of a whole database. For example, a backup of an offline tablespace in an open database is inconsistent with other tablespaces because portions of the database are being modified and written to disk while the backup of the tablespace is progressing. The datafile headers for the online and offline datafiles may contain inconsistent SCNs. You must run your database in ARCHIVELOG mode to make open backups.
If you run the database in ARCHIVELOG mode, you can construct a whole database backup using backups of datafiles taken at different times. For example, if your database contains seven tablespaces, and you back up the control file as well as a different tablespace each night, in a week you will back up all tablespaces in the database as well as the control file. You can consider this backup as a whole database backup.
You have the option of making inconsistent closed backups if a database is backed up after a system crash or SHUTDOWN ABORT. This type of backup is valid if the database is running in ARCHIVELOG mode, because both online and archived redo logs are available to make the backup consistent.
If you run your database in NOARCHIVELOG mode, only back it up when you have closed it cleanly using the IMMEDIATE or NORMAL options. Inconsistent whole database backups of databases running in NOARCHIVELOG mode are usable only if the redo logs containing the changes made prior to the backup are available when you restore it--an unlikely occurrence.
The reason that NOARCHIVELOG inconsistent backups are not recommended is that the datafile headers of the backed up files contain different SCNs (a normal shutdown will guarantee the consistency of these SCNs), and because the database is in NOARCHIVELOG mode, no archived redo logs are available to apply the lost changes. For this reason, RMAN does not allow you to back up a database that has been running in NOARCHIVELOG mode and shut down abnormally because the backup is not usable for recovery.
The moral is: if you run your database in NOARCHIVELOG mode, always aim to have a backup that is usable without performing any recovery. This aim is defeated if you need to apply redo from logs to recover a backup. If you need redo data to make a database consistent, operate in ARCHIVELOG mode.
Figure 3-1 illustrates the various options available to you when perform whole database backups:
After open or inconsistent closed backups, always guarantee that you will have the redo necessary to recover the backup by archiving the unarchived redo logs. When the database is open, issue the following SQL statement to force Oracle to switch out of the current log and archive it as well as all other unarchived logs:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
When the database is mounted, open, or closed, issue the following SQL statement to force Oracle to archive all non-current redo logs:
SQL> ALTER SYSTEM ARCHIVE LOG ALL;
When the database is mounted, open, or closed, issue the following SQL statement to archive a specified log group, where integer is the number of the group:
SQL> ALTER SYSTEM ARCHIVE LOG GROUP integer;
Afterwards, back up all archived redo logs produced since the backup began. This operation ensures that you can use the backup and also allows you to delete the original archived logs from disk. If you do not have all archived redo logs produced during the backup, you cannot recover the backup because you do not have all the redo records necessary to make it consistent.
Unless you are making a consistent whole database backup, make a binary backup up your control file using the ALTER DATABASE command with the BACKUP CONTROLFILE option, specifying the backup destination in quotes. For example, enter:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO '/oracle/copy/cf.f';
You can also back up the control file to a trace file. Use the script in the trace file, which is located in the location specified by the USER_DUMP_DEST parameter, to re-create the control file should it become necessary. Use the following syntax:
SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
Note that trace backups have one major disadvantage: they have no record of any previous backups made with the old control file.
See Also: For more information about backing up the control file using SQL statements, see "Performing Control File Backups".
A tablespace backup is a backup of the datafiles that constitute the tablespace. The reason is that a tablespace is a logical grouping, whereas a datafile is a physical file--and only physical files can be physically backed up. For example, if tablespace TBS_2 contains datafiles 2, 3, and 4, then a backup of tablespace TBS_2 backs up those three datafiles.
Tablespace backups, whether online or offline, are only valid if the database is operating in ARCHIVELOG mode. The reason is that redo will be required to make the restored tablespace consistent with the other tablespaces in the database.
The only time a tablespace backup is valid for a database running in NOARCHIVELOG mode is when the tablespace is currently read-only or offline-normal. These cases are exceptions because no redo is required to recover them. For example, take the scenario depicted in Figure 3-2:
Because there were necessarily no changes to the offline tablespace between t + 5 and t + 10, Oracle does not require media recovery. If you make the tablespace read-write at t + 15 and then subsequently attempt to restore the t + 5 backup, however, Oracle requires media recovery for the changes after t + 15. Consequently, you will only be able to open the database if all necessary redo is located in the online redo logs.
A datafile backup is a backup of a single datafile. Datafile backups, which are not as common as tablespace backups, are valid in ARCHIVELOG databases.
The only time a datafile backup is valid for a database in NOARCHIVELOG mode is if every datafile in a tablespace is backed up. You cannot restore the database unless all datafiles are backed up. The datafiles must be read-only or offline-normal.
A control file backup is a copy of a database's control file. If the database is mounted, you can issue the following SQL statement, where controlfile_location is the name for the backup:
ALTER DATABASE BACKUP CONTROLFILE TO 'controlfile_location';
You can also back up to a trace file: the trace file contains a script for re-creating the control file. The statement is as follows:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
You can also use the RMAN backup current controlfile command.
See Also: To learn how to make control file backups using SQL*Plus, see "Backing Up the Control File After Structural Changes". To learn how to make control file backups using RMAN, see "Backing Up Control Files".
You can make physical backups using Recovery Manager or O/S commands and logical backups using a utility such as Export:
The Recovery Manager (RMAN) utility manages Oracle backup and recovery operations. RMAN uses information about the database stored in the control file to automatically locate, back up, restore, and recover database files--including datafiles, control files, and archived redo logs. For example, RMAN can:
See Also: For a conceptual overview of Recovery Manager, see "Overview of Recovery Manager".
Recovery Manager obtains necessary information for its backup and recovery operations from either the control file or from an optional repository called a recovery catalog. The recovery catalog, which is maintained by RMAN, is a warehouse of information obtained from the control files of its target databases. RMAN refers to the data in the recovery catalog when directing server processes during restore and recover operations.
See Also: For a conceptual overview of the Recovery Manager metadata, see "Recovery Manager Metadata". To learn how to manage the RMAN metadata, see Chapter 6, "Managing Recovery Manager Metadata".
To utilize tape storage for your Oracle database backups, RMAN requires a media manager. A media manager is a third-party software utility that loads, labels, and unloads sequential media such as tape drives for the purpose of backing up and recovering data.
The Oracle Backup Solutions Program (BSP) allows third-party vendors to easily integrate their products with the Recovery Manager; you can access online information about BSP via the following URL:
http://www.oracle.com/st/products/features/backup.html
Although media management software offers you the additional flexibility of backing up to both disk and tertiary storage, a media manager is not required if you only intend to back up to disk.
See Also: For a conceptual overview of media management, see "Media Management". To learn what you need to do to configure a media manager for use with RMAN, see "Configuring a Media Manager".
Although RMAN is commonly used as a command-line utility, you can also perform RMAN backups using Oracle Enterprise Manager. Oracle Enterprise Manager-Backup Manager is a GUI interface to Recovery Manager that enables you to perform backup and recovery via a point-and-click method.
See Also: For information about performing backup and recovery using Oracle Enterprise Manager, see the Oracle Enterprise Manager Administrator's Guide.
You can perform an O/S backup with a native command on your O/S. For example, you can use the cp command to back up files in UNIX. In this case, you must write and maintain UNIX scripts to control the O/S backup.
See Also: For information about the utilities available on your operating system, see your operating system-specific documentation.
The Oracle Export utility writes data from an Oracle database to operating system files in an Oracle-specific format. Export files store information about schema objects created for a database. Because the Oracle Export utility can selectively export specific objects, you may consider exporting portions of or all of a database for supplemental protection and flexibility. Database exports are not a substitute for whole database backups.
See Also: For information about using exports to supplement your backup strategy, see Oracle8i Utilities.
The Oracle Enterprise Backup Utility (EBU) is a utility that automates backups of Oracle7 databases; it is not compatible with Oracle8i databases.
Table 3-2 compares the features of the backup methods described in this chapter:
The format of your backup is contingent on the method you use to make it. You can back up files in the following formats:
When you issue the RMAN backup command (and do not specify the proxy option), you create a backup set. A backup set is a logical structure containing one or more physical backup pieces. Typically, a backup set contains one backup piece. Backup sets can:
Backup sets are in an Oracle proprietary format, which means that an Oracle instance cannot use files in a backup set until RMAN restores them to an instance-usable format. For example, a tablespace backup in a backup set is a compressed version of each file in the tablespace; you must use an RMAN command to restore the datafiles in the backup set.
When you specify datafiles that you want to back up, an Oracle server session reads the files and creates the backup set. You do not need to precede an RMAN backup with the ALTER TABLESPACE BEGIN BACKUP statement (for information about how blocks are read in RMAN backups, see "Detection of Logical Block Corruption").
RMAN can include datafiles, control files, or archived redo logs in a backup set. If you perform a whole database backup, then RMAN automatically backs up every file in that database as well as the control file. You can also tell RMAN to include a control file backup in any datafile backup set.
See Also: For a conceptual overview of Recovery Manager backups, see "Backup Sets". To learn how to make RMAN backups, see Chapter 8, "Making Backups and Copies with Recovery Manager". For reference information for the RMAN backup command, see "backup".
Create an image copy using the RMAN copy command of any of the following objects:
When you issue the command, an Oracle server session--not an O/S routine--reads the file and writes the copy out to disk. You do not need to precede an RMAN copy with the ALTER TABLESPACE BEGIN BACKUP statement.
Image copies can be used immediately by an Oracle instance, i.e., they are already in an instance-usable format. You can only make image copies to disk.
See Also: For an overview of RMAN image copies, see "Image Copies". To learn how to make RMAN image copies, see "Making Image Copies". For information on the RMAN copy and backup commands, see "copy" and "backup".
Create operating system (O/S) backups using an operating system command such as the UNIX dd. You can write O/S backups to disk or tape in any format that your O/S utilities support. Recovery Manager can catalog and use O/S backups that are image backups on disk.
See Also: To learn how to make operating system backups, see Chapter 13, "Performing Operating System Backups".
Logical backups store information about the schema objects created for a database. Use the Export utility to write data from an Oracle database to operating system files that have an Oracle database format.
Because the Oracle Export utility can selectively export specific objects or portions of an object, you can export portions or all of a database for supplemental protection and flexibility in a database's backup strategy. Database exports are not a substitute for physical backups and cannot provide the same complete recovery advantages that the built-in functionality of Oracle offers.
See Also: For more information about the Export Utility, see Oracle8i Utilities.
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 should a disk failure damage 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 will depend on the constraints under which you are operating. No matter which backup strategy you implement, however, follow these guidelines whenever possible:
Before you create an Oracle database, decide how you plan to protect it against potential failures. Answer the following questions:
Once you have answered these questions and have determined which mode to use, follow the guidelines for either:
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:
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:
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.
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:
See Also: To learn how to integrate data structure management into your backup and recovery strategy, see Chapter 2, "Managing Data Structures". For a thorough conceptual overview of all Oracle data structures, see Oracle8i Concepts.
Frequent backups are essential for any recovery scheme. Base the frequency of backups on the rate or frequency of database changes such as:
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 O/S 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: For an overview of RMAN stored scripts, see "Stored Scripts". To learn how to create, delete, replace, and print stored scripts, see "Storing Scripts in the Recovery Catalog".
Administrators as well as users make changes to a database. If you make any of the following structural changes, perform a backup of the appropriate portion of your database immediately before and after completing the alteration:
The part of the database that you should back up depends on your archiving mode:
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, e.g., the SYSTEM tablespace and tablespaces that contain rollback segments. By making more frequent backups of the extensively used datafiles of a database, you gather more recent copies of the datafiles.
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 would have to apply a smaller number of changes to data to roll the restored file forward to the time of the failure.
If users are creating tables or indexes using the UNRECOVERABLE option, consider taking 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.
See Also: For information about the UNRECOVERABLE option, see the CREATE TABLE ... AS SELECT and CREATE INDEX commands in the Oracle8i SQL Reference.
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 will lose all work performed since opening the database.
When you open a database with the RESETLOGS option, Oracle automatically:
Oracle performs these actions so that it can identify which archived redo logs apply to which incarnations of the database.
The resetting of the online redo logs has severe consequences for your backup and recovery strategy. As a rule, you cannot restore pre-RESETLOGS backups, so all your old backups are worthless in the new incarnation. The only exceptions are:
See Also: For more information, see "Recovering a Pre-RESETLOGS Backup".
If you are operating in NOARCHIVELOG mode, your only option is to make a cold, consistent, whole database backup. If you do not, then your backups are inconsistent and require recovery before the database can be opened. Because no redo data is available for recovery, Oracle will prevent you from opening the database.
If you are operating in ARCHIVELOG mode, you can either perform a consistent, closed, whole database backup or an inconsistent, open database backup. The option you choose depends on:
If your most important criterion is getting the database up and running, then you must perform open database backups. You run a risk when you perform an open database backup--if the backups do not complete before you have another media failure, then you will lose all changes made since opening the database with the RESETLOGS option. You cannot use a backup taken before opening the database with RESETLOGS to recover this incarnation of the database.
If the most important criterion is to restore in case of another failure, then you may elect to take a consistent, closed database backup. Oracle recommends that you perform a consistent whole database backup whenever possible.
You should store older backups for two basic reasons:
If you want to recover to a non-current time, 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 you use should be a consistent whole database backup. Of course, you will not be able to perform media recovery using this backup. For a database operating in ARCHIVELOG mode, your whole database backup:
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.
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:
See Also: To learn about performing media recovery in distributed systems, see "Opening the Database after Media Recovery".
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: For a complete account of the Export utility, see the Oracle8i Utilities guide.
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 danger in backing up online redo logs is that you may accidentally restore them while not intending to. There are a number of situations where restoring the online logs would cause very significant problems in the recovery process. Following are two scenarios that illustrate how restoring backed up online logs severely compromises recovery.
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, it is also possible to accidentally restore the online redo logs, thus overwriting the current logs with the older, useless backups. This action forces the DBA to perform an incomplete recovery instead of the intended complete recovery, thereby losing the ability to recover valuable transactions contained in your overwritten redo logs.
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. If you do so, however, the database will eventually generate 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.
Oracle provides a variety of procedures and tools to assist you with recovery. To develop an effective recovery strategy, learn to do the following:
Practice your backup and recovery strategies 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 Chapter 10, "Creating a Duplicate Database with Recovery Manager".
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:
A statement failure is a logical failure in the handling of a statement in an Oracle program. Oracle or the O/S usually returns an error code and a message when a statement failure occurs. Table 3-3 shows typical causes and resolutions for statement failures.
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:
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.
Users errors are any mistakes that users make in adding data to or deleting data from the database. Typical causes of user error are:
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 will probably 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 |
For RMAN recovery, see "Performing Incomplete Recovery". For O/S recovery, see "Performing Incomplete Media Recovery". |
|
|
TSPITR |
For RMAN TSPITR, see Appendix A, "Performing Tablespace Point-in-Time Recovery with Recovery Manager". For O/S TSPITR, see Appendix B, "Performing Operating System Tablespace Point-in-Time Recovery". |
Instance failure occurs when an instance abnormally terminates. An instance failure can occur because:
Fortunately, Oracle performs instance recovery automatically: all you need to do is start 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.
Media failure is the biggest threat to your data. A media failure is a physical problem that occurs when a computer attempts to read from or write to a file necessary to operate the database. Common types of media problems include:
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:
See Also: To learn how to perform media recovery using RMAN, see Chapter 9, "Restoring and Recovering with Recovery Manager". To learn how to perform media recovery using O/S methods, see Chapter 14, "Performing Operating System Recovery".
First, you need 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.
When you perform media recovery, you choose either complete recovery or incomplete recovery. Following is a list of media recovery operations:
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:
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:
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-4 displays typical scenarios and strategies.
The method you use to restore backups depends on whether you use RMAN or O/S methods to back up your data. If you use RMAN, then issue a restore command and let RMAN take over the transfer of data. If you use O/S methods, then you need to identify which files need to be restored and manually copy the backups to their necessary location.
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 command 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 command. Note that RMAN backups do not have this problem.
See Also: To learn how to restore backups using RMAN, see "Restoring Datafiles, Control Files, and Archived Redo Logs". To learn how to restore datafiles using O/S methods, see "Restoring Files".
You have a choice between two basic methods for recovering physical files. You can:
Obviously, the recovery method you choose is contingent on which backup method you use. For example, if you backed up your files using:
RMAN is a powerful tool that can aid in backup and recovery operations. Using RMAN for recovery allows you to:
See Also: For a conceptual overview of Recovery Manager recovery, see "Restoring Files" and "Media Recovery". To learn how to perform RMAN recovery, see Chapter 9, "Restoring and Recovering with Recovery Manager". For reference information for the RMAN recover command, see "recover".
If you do not use RMAN, then you can use O/S methods to restore your backups and SQL*Plus commands to perform media recovery. You can use SQL*Plus commands to:
You can use three basic SQL*Plus commands for recovery:
Note that each of these is also a sub-clause of an ALTER DATABASE statement. Oracle recommends using the SQL*Plus RECOVER command rather than the ALTER DATABASE statement with the RECOVER clause. For more information about the SQL*Plus RECOVER command, see SQL*Plus User's Guide and Reference.
Each command 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. In each case you can recover a database, tablespace, or datafile.
See Also: To learn about the differences between the SQL ALTER DATABASE RECOVER and SQL*Plus RECOVER statements, see "Using Media Recovery Statements".
