Oracle first apply media recovery to the file

Use the operation described in "Renaming and Relocating Datafiles" in the Oracle8i Administrator's Guide , as necessary. To recover the restored datafiles:. If you prefer, create a script to bring all datafiles online at once as in the following:. If you automated recovery, Oracle applies the necessary logs automatically. Oracle continues until all required archived and online redo log files have been applied to the restored datafiles. Oracle notifies you when media recovery is complete.

If no archived redo log files are required for complete media recovery, Oracle applies all necessary online redo log files and terminates recovery. Oracle automatically takes the damaged datafiles offline--but not the tablespaces that contain them--if DBWR fails to be able to write to them. Queries that cannot read damaged files receive errors, but Oracle does not take the files offline for this reason alone. If the hardware problem cannot be repaired quickly, proceed with database recovery by restoring damaged files to an alternative storage device.

To prepare for recovery in an open database:. To restore datafiles in an open database:. If you restored one or more damaged datafiles to alternative locations, indicate the new locations of these files to the control file of the associated database by using the procedure in the Oracle8i Administrator's Guide. To recover offline tablespaces in an open database:.

See "Performing Media Recovery in Parallel". Oracle begins the roll forward phase of media recovery by applying the necessary redo log files archived and online to reconstruct the restored datafiles. Oracle continues until all required archived redo log files have been applied to the restored datafiles. The online redo log files are then automatically applied to the restored datafiles to complete media recovery.

If no archived redo log files are required for complete media recovery, Oracle does not prompt for any. Instead, all necessary online redo log files are applied, and media recovery is complete. Performing Incomplete Media Recovery This section describes the steps necessary to complete the different types of incomplete media recovery operations, and includes the following topics:.

Performing Time-Based Recovery Performing Change-Based Recovery Note that if your database is affected by seasonal time changes for example, daylight savings time , you may experience a problem if a time appears twice in the redo log and you want to recover to the second, or later time. To deal with time changes, perform cancel-based or change-based recovery to the point in time where the clock is set back, then continue with the time-based recovery to the exact time.

Restore backup control files if necessary and backup datafiles. To prepare for cancel-based recovery:. If a media failure occurred, correct the hardware problem that caused the failure. To restore the files necessary for cancel-based recovery:. The restored control file should reflect the database's physical file structure, that is, contain the names of datafiles and online redo log files, at the point at which incomplete media recovery is intended to finish. Review the list of files that correspond to the current control file as well as each control file backup to determine the correct control file to use.

If necessary, replace all current control files of the database with the correct control file backup. Alternatively, create a new control file. Restore backups taken as part of a full or partial backup of all the datafiles of the database. You must have taken all backup files used to replace existing datafiles before the intended time of recovery.

For example, if you intend to recover to redo log sequence number 38, then restore all datafiles with backups completed before redo log sequence number If you do not have a backup of a specific datafile, create an empty replacement file that can be recovered.

If you added a datafile after the intended time of recovery, you do not need to restore a backup for this file since it will no longer be used for the database after recovery is complete.

If you solved the hardware problem that caused a media failure and can restore all datafiles to their original locations, then restore the files.

If a hardware problem persists, restore damaged datafiles to an alternative storage device. Note: Files in read-only tablespaces should be taken offline if you are using a control file backup. Otherwise, recovery will try to update the headers of the read-only files. To perform cancel-based recovery:. Oracle applies the necessary redo log files to reconstruct the restored datafiles. Note that if the control file is a backup file, you must supply names of online logs. Note: If you use an OPS configuration, and you are performing incomplete recovery or using a backup control file, then Oracle can only compute the name of the first archived redo log file from the first thread.

The first redo log file from the other threads must be supplied by the user. Once the first log file in a given thread has been supplied, Oracle can suggest the names of the subsequent log files in those threads. Continue applying redo log files until the most recent, undamaged redo log file has been applied to the restored datafiles.

Cancel recovery after Oracle has applied the redo log file just prior to the damaged file: CANCEL Oracle returns a message indicating whether recovery is successful. Note that if you cancel recovery before it is complete and then try to open the database, you will get an ORA error if more recovery is necessary for the file.

This section describes how to perform the time-based media recovery procedure in these stages:. Note: If you are performing time-based, incomplete recovery using a backup control file and have read-only tablespaces, contact Oracle Support before attempting this procedure. To prepare for time-based recovery:. Follow the same preparation procedure described in the section "Performing Cancel-Based Recovery".

Review the list of files that corresponds to the current control file and each control file backup to determine the correct control file to use. Alternatively, create a new control file to replace the missing one. Restore backups of all the datafiles of the database. All backups used to replace existing datafiles must have been taken before the intended time of recovery.

For example, if you intend to recover to January 2 at p. Follow these guidelines: If You do not have a backup of a datafile Create an empty replacement file, which can be recovered. A datafile was added after the intended time of recovery Do not restore a backup of this file, since it will no longer be used for the database after recovery completes.

The hardware problem causing the failure has been solved and all datafiles can be restored to their default locations Restore the files and skip Step 5 of this procedure. A hardware problem persists Restore damaged datafiles to an alternative storage device. Note: Files in read-only tablespaces should be offline if you are using a control file backup.

Otherwise, the recovery will try to update the headers of the read-only files. Make sure that all datafiles of the database are online. All datafiles of the database must be online unless an offline tablespace was taken offline normally. If a specified datafile is already online, Oracle ignores the statement.

If the control file is a backup, you must supply names of online logs. Apply redo log files until the last required redo log file has been applied to the restored datafiles. Oracle automatically terminates the recovery when it reaches the correct time, and returns a message indicating whether recovery is successful. To prepare for change-based recovery:.

Follow the same restore procedure described in the section "Performing Time-Based Recovery". If the control file is a backup file, you must supply names of online logs.

Oracle continues to apply redo log files. Continue applying redo log files until the last required redo log file has been applied to the restored datafiles. Oracle automatically terminates the recovery when it reaches the correct SCN, and returns a message indicating whether recovery is successful.

Opening the Database After Media Recovery Whenever you perform incomplete recovery or perform recovery using a backup control file, you must reset the online redo logs when you open the database. The new version of the reset database is called a new incarnation. All previous backups and archived logs created during the lifetime of this incarnation of the database are still valid. Archived redo logs also have these two values in their header.

Figure shows the case of a database that can only be recovered to SCN because an archived redo log is missing. At SCN , the database crashes. You restore the SCN backup and prepare for complete recovery. Unfortunately, one of your archived redo logs is corrupted. As the diagram illustrates, you generate new changes in the new incarnation of the database, eventually reaching SCN Oracle does not allow you to apply logs from an old incarnation to the new incarnation.

Media recovery is most often used to recover from media failure, such as the loss of a file or disk, or a user error, such as the deletion of the contents of a table.

Media recovery can be a complete recovery or a point-in-time recovery. Complete recovery can apply to individual datafiles, tablespaces, or the entire database. Point-in-time recovery applies to the whole database and also sometimes to individual tablespaces, with automation help from Oracle Recover Manager RMAN. In a complete recovery, you restore backup data files and apply all changes from the archived and online redo log files to the data files.

Recovery cannot continue until the required redo log file is applied. If Oracle returns an error message after supplying a redo log filename, then the following responses are possible.

ORA : unable to obtain file status. ORA unable to read the header block of file. If you can locate an uncorrupted or complete log copy, then apply the intact copy and continue recovery.

If no copy of the log exists and you know the time of the last valid redo entry, then you must use incomplete recovery. Restart recovery from the beginning, including restoring backups. When you perform complete recovery, you recover the backups to the current SCN. You can either recover the whole database at once or recover individual tablespaces or datafiles. Because you do not have to open the database with the RESETLOGS option after complete recovery as you do after incomplete recovery, you have the option of recovering some datafiles at one time and the remaining datafiles later.

This section describes the steps necessary to complete media recovery operations, and includes the following topics:. Oracle9i Backup and Recovery Concepts to familiarize yourself with fundamental recovery concepts and strategies. This section describes steps to perform complete recovery while the database is not open. You can recover either all damaged datafiles in one operation, or perform individual recovery of each damaged datafile in separate operations.

In this stage, you shut down the instance and inspect the media device that is causing the problem. If you do not have a backup of a specific datafile, then you may be able to create an empty replacement file that can be recovered.

The hardware problem is repaired and you can restore the datafiles to their default locations. The hardware problem persists and you cannot restore datafiles to their original locations. Restore the datafiles to an alternative storage device. Indicate the new location of these files in the control file. If a specified datafile is already online, then Oracle ignores the statement.

If you prefer, create a script to bring all datafiles online at once as in the following:. See "Performing Media Recovery in Parallel". If no archived redo log files are required for complete media recovery, then Oracle applies all necessary online redo log files and terminates recovery. It is possible for a media failure to occur while the database remains open, leaving the undamaged datafiles online and available for use. Oracle automatically takes the damaged datafiles offline--but not the tablespaces that contain them--if the database writer is unable to write to them.

Queries that cannot read damaged files return errors, but Oracle does not take the files offline because of the failed queries. For example, you may run a query and see output such as:. The media recovery procedure in this section cannot be used to perform complete media recovery on the datafiles of the SYSTEM tablespace.

In this stage, you take affected tablespaces offline and inspect the media device that is causing the problem. To prepare for datafile recovery when the database is open:. For maximum performance, use parallel recovery to recover the datafiles. Oracle continues until all required archived redo log files have been applied to the restored datafiles.

The online redo log files are then automatically applied to the restored datafiles to complete media recovery. If no archived redo log files are required for complete media recovery, then Oracle does not prompt for any.

Instead, all necessary online redo log files are applied, and media recovery is complete. Oracle9i Database Administrator's Guide for more information about creating datafiles. This section describes the steps necessary to complete the different types of incomplete media recovery operations, and includes the following topics:.

Note that if your database is affected by seasonal time changes for example, daylight savings time , then you may experience a problem if a time appears twice in the redo log and you want to recover to the second, or later time.

To handle time changes, perform cancel-based or change-based recovery. To restore the files necessary for cancel-based recovery and bring them online:. Do not restore a backup of this file because it will no longer be used for the database after recovery completes. The hardware problem causing the failure has been solved and all datafiles can be restored to their default locations. Restore the files as described in "Restoring Datafiles" and skip Step 5 of this procedure.

Files in read-only tablespaces should be offline if you are using a control file backup. Otherwise, the recovery will try to update the headers of the read-only files. If a specified datafile is already online, Oracle ignores the statement. In cancel-based recovery, recovery proceeds by prompting you with the suggested filenames of archived redo log files.

Cancel-based recovery is better than change-based or time-based recovery if you want to control which archived log terminates recovery. For example, you may know that you have lost all logs past sequence , so you want to cancel recovery after log is applied.

If you use an Oracle Real Application Clusters configuration, and you are performing incomplete recovery or using a backup control file, then Oracle can only compute the name of the first archived redo log file from the first thread. The first redo log file from the other threads must be supplied by the user. After the first log file in a given thread has been supplied, Oracle can suggest the names of the subsequent log files in this thread.

Oracle returns a message indicating whether recovery is successful. Note that if you cancel recovery before all the datafiles have been recovered to a consistent SCN and then try to open the database, you will get an ORA error if more recovery is necessary for the file. This section describes how to perform the time-based media recovery procedure in the following stages:.

If a backup of the control file is being used with this incomplete recovery that is, a control file backup or re-created control file was restored , then indicate this in the statement used to start recovery.

The following statement recovers the database up to a specified time using a control file backup:. If you are using Export to supplement regular backups, then you can also attempt to restore the database by importing an exported backup of the database into a re-created database or a database restored from an old backup.

Using archived redo logs would have enabled you to use complete or incomplete recovery to reconstruct your database, thereby minimizing the amount of lost work. In this scenario, the media failure is repaired so that you are able to restore all database files to their original location.