28 Performing User-Managed Database Flashback and Recovery

About User-Managed Restore and Recovery

Typically, you restore a file when a media failure or user error has damaged or deleted one or more datafiles. In a user-managed restore operation, you use an operating system utility to restore a backup of the file.

If a media failure affects datafiles, then the recovery procedure depends on:

• The archiving mode of the database: ARCHIVELOG or NOARCHIVELOG

• The type of media failure

• The files affected by the media failure (datafiles, control files, archived redo logs, and the server parameter file are all candidates for restore operations)

If either a permanent or temporary media failure affects any datafiles of a database operating in NOARCHIVELOG mode, then the database automatically shuts down. If the media failure is temporary, then correct the underlying problem and restart the database. Usually, crash recovery will recover all committed transactions from the online redo log. If the media failure is permanent, then recover the database as described in "Recovering a Database in NOARCHIVELOG Mode".

Table 28-1 explains the implications for media recovery when you lose files in database that runs in ARCHIVELOG mode.

To perform media recovery, Oracle recommends that you use the RECOVER statement in SQL*Plus. You can also use the SQL statement ALTER DATABASE RECOVER, but the RECOVER statement is simpler in most cases. To start any type of media recovery, you must adhere to the following restrictions:

• You must have administrator privileges.

• All recovery sessions must be compatible.

• One session cannot start complete media recovery while another performs incomplete media recovery.

• You cannot start media recovery if you are connected to the database through a shared server process.

Automatic Recovery with the RECOVER Command

When using SQL*Plus to perform media recovery, the easiest strategy is to perform automatic recovery with the SQL*Plus RECOVER command. Automatic recovery initiates recovery without manually prompting SQL*Plus to apply each individual archived redo log.

When using SQL*Plus, you have the following options for automating the application of the default filenames of archived redo logs needed during recovery:

• Issuing SET AUTORECOVERY ON before issuing the RECOVER command. If you recovery with SET AUTORECOVERY OFF, which is the default, then you must enter filenames manually or accept the suggested filename by pressing Enter.

• Specifying the AUTOMATIC keyword as an option of the RECOVER command.

In either case, no interaction is required when you issue the RECOVER command if the necessary files are in the correct locations with the correct names. When the database successfully applies a redo log file, the following message is returned:

Log applied.

You are then prompted for the next redo log in the sequence. If the most recently applied log is the last required log, then recovery is terminated.

The filenames used when you use automatic recovery are derived from the concatenated values of LOG_ARCHIVE_FORMAT with LOG_ARCHIVE_DEST_n, where n is the highest value among all enabled, local destinations. For example, assume the following initialization parameter settings are in effect in the database instance:

LOG_ARCHIVE_DEST_1 = "LOCATION=/arc_dest/loc1/" 
LOG_ARCHIVE_DEST_2 = "LOCATION=/arc_dest/loc2/"
LOG_ARCHIVE_DEST_STATE_1 = DEFER 
LOG_ARCHIVE_DEST_STATE_2 = ENABLE 
LOG_ARCHIVE_FORMAT = arch_%t_%s_%r.arc

In this example, SQL*Plus automatically suggests the filename /arc_dest/loc2/arch_%t_%s_%r.arc (where %t is the thread, %s is the sequence and %r is the resetlogs ID).

STARTUP MOUNT
SET AUTORECOVERY ON
RECOVER DATABASE
ALTER DATABASE OPEN;

STARTUP MOUNT
RECOVER AUTOMATIC DATABASE
ALTER DATABASE OPEN;

Recovery When Archived Logs Are in the Default Location

Recovering when the archived logs are in their default location is the simplest case. As a log is needed, the database suggests the filename. If you are running nonautomatic media recovery with SQL*Plus, then the output is displayed in the format shown by this example:

ORA-00279: change 53577 generated at 11/26/02 19:20:58 needed for thread 1
ORA-00289: suggestion : /oracle/oradata/trgt/arch/arcr_1_802.arc
ORA-00280: change 53577 for thread 1 is in sequence #802
Specify log: [<RET> for suggested | AUTO | FROM logsource | CANCEL ]

Similar messages are returned when you use an ALTER DATABASE ... RECOVER statement. However, no prompt is displayed.

The database constructs suggested archived log filenames by concatenating the current values of the initialization parameters LOG_ARCHIVE_DEST_n (where n is the highest value among all enabled, local destinations) and LOG_ARCHIVE_FORMAT and using log history data from the control file. The following are possible settings:

LOG_ARCHIVE_DEST_1 = 'LOCATION = /oracle/oradata/trgt/arch/'
LOG_ARCHIVE_FORMAT = arcr_%t_%s.arc

SELECT NAME FROM V$ARCHIVED_LOG;

NAME
----------------------------------------
/oracle/oradata/trgt/arch/arcr_1_467.arc
/oracle/oradata/trgt/arch/arcr_1_468.arc
/oracle/oradata/trgt/arch/arcr_1_469.arc

Thus, if all the required archived log files are mounted at the LOG_ARCHIVE_DEST_1 destination, and if the value for LOG_ARCHIVE_FORMAT is never altered, then the database can suggest and apply log files to complete media recovery automatically.

Recovery When Archived Logs Are in a Nondefault Location

Performing media recovery when archived logs are not in their default location adds an extra step. You have the following mutually exclusive options:

• Edit the LOG_ARCHIVE_DEST_n parameter that specifies the location of the archived redo logs, then recover as usual.

• Use the SET statement in SQL*Plus to specify the nondefault log location before recovery, or the FROM parameter of the RECOVER command

Recovery Cancellation

If you start media recovery and must then interrupt it, then either enter CANCEL when prompted for a redo log file, or use your operating system's interrupt signal if you must terminate when recovering an individual datafile, or when automated recovery is in progress. After recovery is canceled, you can resume it later with the RECOVER command. Recovery resumes where it left off when it was canceled.

Parallel Media Recovery

By default, Oracle uses parallel media recovery to improve performance of the roll forward phase of media recovery. In parallel media recovery, the database uses a "division of labor" approach to allocate different processes to different data blocks while rolling forward, thereby making the procedure more efficient. The number of processes used is derived from the CPU_COUNT initialization parameter, which by default is equal to the number of CPUs on the system. For example, if parallel recovery is performed on a system where CPU_COUNT is 4, and only one datafile is recovered, then four spawned processes read blocks from the archive logs and apply redo.

Typically, media recovery is limited by data block reads and writes. Parallel recovery attempts to use all of the available I/O bandwidth of the system to improve performance. Unless there is a system I/O bottleneck or poor asynchronous I/O support, parallel recovery is likely to improve performance of recovery.

To override the default behavior of performing parallel recovery, use the RECOVER with the NOPARALLEL option, or RECOVER PARALLEL 0. The RECOVERY_PARALLELISM initialization parameter controls instance or crash recovery only. Media recovery is not affected by the value used for RECOVERY_PARALLELISM.

Performing Closed Database Recovery

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.

To restore and recover damaged or missing datafiles:

1. If the database is open, query V$RECOVER_FILE to determine which datafiles need to be recovered and why they need to be recovered.

   If you are planning to perform complete recovery rather than point-in-time recovery, then you can recover only those datafiles which require recovery, rather than the whole database. For point-in-time recovery, you must restore and recover all datafiles, unless you perform TSPITR as described in Chapter 20, "Performing RMAN Tablespace Point-in-Time Recovery (TSPITR)". You can also use Flashback Database, but this procedure affects all datafiles and returns the entire database to a past time.

   You can query V$RECOVER_FILE to list datafiles requiring recovery by datafile number with their status and error information.

   SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME 
   FROM   V$RECOVER_FILE;
   

   Note:

   You cannot use V$RECOVER_FILE with a control file restored from backup or a control file that was re-created after the time of the media failure affecting the datafiles. A restored or re-created control file does not contain the information needed to update V$RECOVER_FILE accurately.

   You can also perform useful joins using the datafile number and the V$DATAFILE and V$TABLESPACE views, to get the datafile and tablespace names. Use the following SQL*Plus commands to format the output of the query:

   COL DF# FORMAT 999
   COL DF_NAME FORMAT A35
   COL TBSP_NAME FORMAT A7
   COL STATUS FORMAT A7
   COL ERROR FORMAT A10
   COL CHANGE# FORMAT 99999999
   SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name, 
          d.STATUS, r.ERROR, r.CHANGE#, r.TIME
   FROM   V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
   WHERE  t.TS# = d.TS#
   AND    d.FILE# = r.FILE#;
   

   The ERROR column identifies the problem for each file requiring recovery.

2. Query V$ARCHIVED_LOG and V$RECOVERY_LOG to determine which archived redo log files are needed.

   V$ARCHIVED_LOG lists filenames for all archived redo logs, whereas V$RECOVERY_LOG lists only the archived redo logs that the database needs to perform media recovery. The latter view also includes the probable names of the files using LOG_ARCHIVE_FORMAT.

   Note:

   V$RECOVERY_LOG is only populated when media recovery is required for a datafile. Thus, this view is not useful in the case of a planned recovery, such as recovery from a user error.

   If a datafile requires recovery, but no backup of the datafile exists, then you need all redo generated starting from the time when the datafile was added to the database.

3. If all archived logs are available in the default location, then skip to the next step.

   If some archived logs need to be restored, and if sufficient space is available, then restore the required archived redo log files to the location specified by LOG_ARCHIVE_DEST_1. The database locates the correct log automatically when required during media recovery. For example, you might enter a command such as the following on Linux or UNIX:

   % cp /disk2/arch/* $ORACLE_HOME/oradata/trgt/arch
   

   If sufficient space is not available, then restore some or all of the required archived redo log files to an alternative location.

4. If the database is open, then shut it down. For example:

   SHUTDOWN IMMEDIATE
   

5. Inspect the media to determine the source of the problem.

   If the hardware problem that caused the media failure was temporary, and if the data was undamaged (for example, a disk or controller power failure), then no media recovery is required: start the database and resume normal operations.

   If you cannot repair the problem, then proceed to the next step.

6. If the files are permanently damaged, then identify the most recent backups for the damaged files. Restore only the datafiles damaged by the media failure: do not restore undamaged datafiles or any online redo log files.

   For example, if ORACLE_HOME/oradata/trgt/users01.dbf is the only damaged file, then you may find that /backup/users01_10_24_02.dbf is the most recent backup of this file. 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.

7. Use an operating system utility to restore the datafiles to their default location or to a new location. For example, a Linux or UNIX user restoring users01.dbf to its default location might enter:

   % cp /backup/users01_10_24_06.dbf $ORACLE_HOME/oradata/trgt/users01.dbf
   

   Use the following guidelines when determining where to restore datafile backups:

   • If hardware problem is repaired and you can restore the datafiles to their default locations, then restore the datafiles to their default locations and begin media recovery.

   • If the hardware problem persists and you cannot restore datafiles to their original locations, then restore the datafiles to an alternative storage device. Indicate the new location of these files in the control file with ALTER DATABASE RENAME FILE. See Oracle Database Administrator's Guide, as necessary.

   • If you are restoring a datafile to a raw disk or partition, then the technique is basically the same as when restoring to a file on a file system. Be aware of the naming conventions for files on raw devices (which differ depending on the operating system), however, and use an operating system utility that supports raw devices.

8. Connect to the database with administrator privileges, then start a new instance and mount, but do not open, the database. For example, enter:

   STARTUP MOUNT
   

9. If you restored one or more damaged datafiles to alternative locations, then update the control file of the database to reflect the new datafile names. For example, to change the filename of the datafile in tablespace users you might enter:

   ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO
                              '/disk2/users01.dbf';
   

10. Obtain the datafile names and statuses of all datafiles by checking the list of datafiles that normally accompanies the current control file or querying the V$DATAFILE view. For example, enter:

    SELECT NAME,STATUS FROM V$DATAFILE;
    

11. Ensure that all datafiles requiring recovery are online. The only exceptions are datafiles in an offline tablespace that was taken offline normally or datafiles in a read-only tablespace. For example, to guarantee that a datafile named /oracle/dbs/tbs_10.f is online, enter the following:

    ALTER DATABASE DATAFILE '/oracle/dbs/tbs_10.f' ONLINE;
    

    If a specified datafile is already online, then the database ignores the statement. If you prefer, create a script to bring all datafiles online at once as in the following:

    SPOOL onlineall.sql
    SELECT 'ALTER DATABASE DATAFILE '''||name||''' ONLINE;' FROM V$DATAFILE;
    SPOOL OFF
    
    SQL> @onlineall
    

12. If you restored archived redo logs to an alternative location, then you can specify the location before media recovery with the LOGSOURCE parameter of the SET command in SQL*Plus. For example, if the logs are staged in /tmp, you can enter the following command:

    SET LOGSOURCE /tmp
    

    Alternatively, use the FROM parameter on the RECOVER command in the following step. For example, if the logs are staged in /tmp, you can enter the following command:

    RECOVER AUTOMATIC FROM '/tmp' DATABASE
    

    Note:

    Overriding the redo log source does not affect the archive redo log destination for online redo log groups being archived.

13. Issue a statement to recover the database, tablespace, or datafile. For example, enter one of the following RECOVER commands:

    RECOVER AUTOMATIC DATABASE   # whole database
    RECOVER AUTOMATIC TABLESPACE users   # specific tablespace
    RECOVER AUTOMATIC DATAFILE '?/oradata/trgt/users01.dbf'; # specific datafile
    

    If you choose not to automate the application of archived redo logs, then you must accept or reject each prompted log. If you automate recovery, then the database applies the logs automatically. Recovery continues until all required archived and online redo logs have been applied to the restored datafiles. The database notifies you when media recovery is complete:

    Media recovery complete.
    

    If no archived redo logs are required for complete media recovery, then the database applies all necessary online redo log files and terminates recovery.

14. After recovery terminates, open the database for use:

    ALTER DATABASE OPEN;
    

    See Also:

    "Overview of User-Managed Media Recovery" for more information about applying redo log files and Oracle Database Reference for descriptions of V$ views

15. After archived logs are applied, and after making sure that a copy of each archived log group still exists in offline storage, delete the restored copy of the archived redo log file to free disk space. For example:

    % rm /tmp/*.arc
    

    See Also:

    Oracle Database Reference for more information about the data dictionary views, and "Overview of User-Managed Media Recovery" for an overview of log application during media recovery

Performing Open Database Recovery

It is possible for a media failure to occur while the database remains open, leaving the undamaged datafiles online and available for use. Damaged datafiles—but not the tablespaces that contain them—are automatically taken offline if the database writer is unable to write to them. Queries that cannot read damaged files return errors, but the datafiles are not taken offline because of the failed queries. For example, you may run a SQL query and see output such as:

ERROR at line 1:
ORA-01116: error in opening database file 3
ORA-01110: data file 11: '/oracle/oradata/trgt/cwmlite02.dbf'
ORA-27041: unable to open file
SVR4 Error: 2: No such file or directory
Additional information: 3

You cannot use the procedure in this section to perform complete media recovery on the SYSTEM tablespace while the database is open. If the media failure damages datafiles of the SYSTEM tablespace, then the database automatically shuts down.

To restore datafiles in an open database:

1. Follow step 1 through step 3 in "Performing Closed Database Recovery".

2. If the database is open, then take all tablespaces containing damaged datafiles offline. For example, if tablespace users and tools contain damaged datafiles, then execute the following SQL statements:

   ALTER TABLESPACE users OFFLINE TEMPORARY;
   ALTER TABLESPACE tools OFFLINE TEMPORARY;
   

   If you specify TEMPORARY, then Oracle Database performs a checkpoint for all online datafiles in the tablespace. Files that are offline when you issue this statement may require media recovery before you bring the tablespace back online. If you specify IMMEDIATE, then you must perform media recovery on the tablespace before bringing it back online.

3. Inspect the media to determine the source of the problem.

   As explained in "Running the DBVERIFY Utility", you can use the DBVERIFY utility to run an integrity check on offline datafiles.

   If the hardware problem that caused the media failure was temporary, and if the data was undamaged, then no media recovery is required. You can bring the offline tablespaces online and resume normal operations. If you cannot repair the problem, or if DBVERIFY reports corrupt blocks, then proceed to the next step.

4. If files are permanently damaged, then use operating system commands to restore the most recent backup files of only the datafiles damaged by the media failure. For example, to restore users01.dbf you might use the cp command on Linux or UNIX as follows:

   % cp /disk2/backup/users01.dbf $ORACLE_HOME/oradata/trgt/users01.dbf
   

   If the hardware problem is fixed and the datafiles can be restored to their original locations, then do so. Otherwise, restore the datafiles to an alternative storage device.Do not restore undamaged datafiles, online redo logs, or control files.

   Note:

   In some circumstances, if you do not have a backup of a specific datafile, you can use ALTER DATABASE CREATE DATAFILE to create an empty replacement file that is recoverable.

5. If you restored one or more damaged datafiles to alternative locations, then update the control file of the database to reflect the new datafile names. For example, to change the filename of the datafile in tablespace users you might enter:

   ALTER DATABASE RENAME FILE '?/oradata/trgt/users01.dbf' TO
                              '/disk2/users01.dbf';
   

6. If you restored archived redo logs to an alternative location, then you can specify the location before media recovery with the LOGSOURCE parameter of the SET command in SQL*Plus. For example, if the logs are staged in /tmp, you can enter the following command:

   SET LOGSOURCE /tmp
   

   Alternatively, use the FROM parameter on the RECOVER command in the following step. For example, if the logs are staged in /tmp, you can enter the following command:

   RECOVER AUTOMATIC FROM '/tmp' TABLESPACE users, tools;
   

   Note:

   Overriding the redo log source does not affect the archive redo log destination for online redo log groups being archived.

7. Connect to the database with administrator privileges, and start offline tablespace recovery of all damaged datafiles in one or more offline tablespaces using one step. For example, recover users and tools as follows:

   RECOVER AUTOMATIC TABLESPACE users, tools;
   

   The database begins the roll forward phase of media recovery by applying the necessary archived and online redo logs to reconstruct the restored datafiles. Unless the applying of files is automated with RECOVER AUTOMATIC or SET AUTORECOVERY ON, the database prompts for each required redo log file.

   Recovery continues until all required archived logs have been applied to the datafiles. The online redo logs are then automatically applied to the restored datafiles to complete media recovery. If no archived redo logs are required for complete media recovery, then the database does not prompt for any. Instead, all necessary online redo logs are applied, and media recovery is complete.

8. When the damaged tablespaces are recovered up to the moment that media failure occurred, bring the offline tablespaces online. For example, to bring tablespaces users and tools online, issue the following statements:

   ALTER TABLESPACE users ONLINE;
   ALTER TABLESPACE tools ONLINE;
   

Performing Cancel-Based Incomplete Recovery

In cancel-based recovery, recovery proceeds by prompting you with the suggested filenames of archived redo log files. Recovery stops when you specify CANCEL instead of a filename or when all redo has been applied to the datafiles.

To perform cancel-based recovery:

1. Follow steps step 1 through step 8 in "Performing Closed Database Recovery".

2. Begin cancel-based recovery by issuing the following command in SQL*Plus:

   RECOVER DATABASE UNTIL CANCEL
   

   Note:

   If you fail to specify the UNTIL clause on the RECOVER command, then the database assumes a complete recovery and will not open until all redo is applied.

   The database applies the necessary redo log files to reconstruct the restored datafiles. The database supplies the name it expects to find from LOG_ARCHIVE_DEST_1 and requests you to stop or proceed with applying the log file. If the control file is a backup, then you must supply the names of the online redo logs if you want to apply the changes in these logs.

3. Continue applying redo log files until the last log has been applied to the restored datafiles, then cancel recovery by executing the following command:

   CANCEL
   

   The database indicates whether recovery is successful. If you cancel before all the datafiles have been recovered to a consistent SCN and then try to open the database, then you will get an ORA-1113 error if more recovery is necessary. You can query V$RECOVER_FILE to determine whether more recovery is needed, or if a backup of a datafile was not restored prior to starting incomplete recovery.

4. Open the database with the RESETLOGS option. You must always reset the logs after incomplete recovery or recovery with a backup control file. For example:

   ALTER DATABASE OPEN RESETLOGS;
   

   If you attempt to OPEN RESETLOGS when you should not, or if you neglect to reset the log when you should, then the database returns an error and does not open the database. Correct the problem and try again.

   See Also:

   "About User-Managed Media Recovery Problems" for descriptions of situations that can cause ALTER DATABASE OPEN RESETLOGS to fail

5. After opening the database with the RESETLOGS option, check the alert log.

   Note:

   The easiest way to locate trace files and the alert log is to run the following SQL query: SELECT NAME, VALUE FROM V$DIAG_INFO.

   When you open with the RESETLOGS option, the database returns different messages depending on whether recovery was complete or incomplete. If the recovery was complete, then the following message appears in alert log:

   RESETLOGS after complete recovery through change scn
   

   If the recovery was incomplete, then this message is reported in the alert log, where scn refers to the end point of incomplete recovery:

   RESETLOGS after incomplete recovery UNTIL CHANGE scn
   

   Also check the alert log to determine whether the database detected inconsistencies between the data dictionary and the control file. Table 28-3 describes two possible scenarios.

   Table 28-3 Inconsistencies Between Data Dictionary and Control File

   Datafile Listed in Control File	Datafile Listed in Data Dictionary	Result
   Yes	No	References to the unlisted datafile are removed from the control file. A message in the alert log indicates what was found.
   No	Yes	The database creates a placeholder entry in the control file under MISSINGnnnnn (where nnnnn is the file number in decimal). MISSINGnnnnn is flagged in the control file as offline and requiring media recovery. You can make the datafile corresponding to MISSINGnnnnn accessible by using ALTER DATABASE RENAME FILE for MISSINGnnnnn so that it points to the datafile. If you do not have a backup of this datafile, then drop the tablespace.

   
   

Performing Time-Based or Change-Based Incomplete Recovery

This section describes how to specify an SCN or time for the end point of recovery. 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 perform change-based or time-based recovery:

1. Follows steps step 1 through step 8 in "Performing Closed Database Recovery".

2. Issue the RECOVER DATABASE UNTIL statement to begin recovery. If recovering to an SCN, then specify as a decimal number without quotation marks. For example, to recover through SCN 10034 issue:

   RECOVER DATABASE UNTIL CHANGE 10034;
   

   If recovering to a time, then the time is always specified using the following format, delimited by single quotation marks: 'YYYY-MM-DD:HH24:MI:SS'. The following statement recovers the database up to a specified time:

   RECOVER DATABASE UNTIL TIME '2000-12-31:12:47:30'
   

3. Apply the necessary redo log files to recover the restored datafiles. The database automatically terminates the recovery when it reaches the correct time, and returns a message indicating whether recovery is successful.

   Note:

   Unless recovery is automated, the database supplies the name from LOG_ARCHIVE_DEST_1 and asks you to stop or proceed with after each log. If the control file is a backup, then after the archived logs are applied you must supply the names of the online logs.

4. Follow steps 4 and 5 in "Performing Cancel-Based Incomplete Recovery".

About User-Managed Media Recovery Problems

Table 28-4, "Media Recovery Problems" describes potential problems that can occur during media recovery.

The symptoms of media recovery problems are usually external or internal errors signaled during recovery. For example, an external error indicates that a redo block or a data block has failed checksum verification checks. Internal errors can be caused by either bugs in the database or errors arising from the underlying operating system and hardware.

If media recovery encounters a problem while recovering a database backup, then whether or not it is a stuck recovery problem or a problem during redo application, the database always stops and leaves the datafiles undergoing recovery in a consistent state, that is, at a consistent SCN preceding the failure. You can then do one of the following:

• Open the database read-only to investigate the problem.

• Open the database with the RESETLOGS option, as long as the requirements for opening RESETLOGS have been met. The RESETLOGS restrictions apply to opening the physical standby database as well, because a standby database is updated by a form of media recovery.

In general, opening the database read-only or opening with the RESETLOGS option require all online datafiles to be recovered to the same SCN. If this requirement is not met, then the database may signal ORA-1113 or other errors when you attempt to open. Some common causes of ORA-1113 are described in Table 28-4, "Media Recovery Problems".

The basic methodology for responding to media recovery problems occurs in the following phases:

1. Try to identify the cause of the problem. Run a trial recovery if needed.

2. If the problem is related to missing redo logs or you suspect there is a redo log, memory, or data block corruption, then try to resolve it using the methods described in Table 28-5.

3. If you cannot resolve the problem using the methods described in Table 28-5, then do one of the following:

   • Open the database with the RESETLOGS option if you are recovering a whole database backup. If you have performed serial media recovery, then the database contains all the changes up to but not including the changes at the SCN where the corruption occurred. No changes from this SCN onward are in the recovered part of the database. If you have restored online backups, then opening RESETLOGS succeeds only if you have recovered through all the ALTER ... END BACKUP operations in the redo stream.

   • Proceed with recovery by allowing media recovery to corrupt data blocks. After media recovery completes, try performing block media recovery using RMAN.

   • Call Oracle Support Services as a last resort.

     See Also:

     "Performing Disaster Recovery" to learn about block media recovery

Investigating the Media Recovery Problem: Phase 1

If media recovery encounters a problem, then obtain as much information as possible after recovery halts. You do not want to waste time fixing the wrong problem, which may in fact make matters worse.

The goal of this initial investigation is to determine whether the problem is caused by incorrect setup, corrupted redo logs, corrupted data blocks, memory corruption, or other problems. If you see a checksum error on a data block, then the data block is corrupted. If you see a checksum error on a redo log block, then the redo log is corrupted.

Sometimes the cause of a recovery problem can be difficult to determine. Nevertheless, the methods in this chapter allow you to quickly recover a database even when you do not completely understand the cause of the problem.

To investigate media recovery problems:

1. Examine the alert.log to see whether the error messages give general information about the nature of the problem. For example, does the alert_SID.log indicate any checksum failures? Does the alert_SID.log indicate that media recovery may have to corrupt data blocks in order to continue?

2. Check the trace file generated by the Oracle process during recovery. It may contain additional error information.

Trying to Fix the Recovery Problem Without Corrupting Blocks: Phase 2

Depending on the type of media recovery problem you suspect, you have different solutions at your disposal. You can try one or a combination of the techniques described in Table 28-5. The solutions listed below are common repair techniques and fairly safe for resolving most media recovery issues.

If you cannot fix the problem with the methods described in Table 28-5, then there may be no easy way to fix the problem without losing data. You have these options:

• Open the database with the RESETLOGS option (for whole database recovery).

  This solution discards all changes after the point where the redo problem occurred, but guarantees a logically consistent database.

• Allow media recovery to corrupt one or more data blocks and then proceed.

  This option only succeeds if the alert log indicates that recovery can continue if it is allowed to corrupt a data block, which should be the case for most recovery problems. This option is best if you need to bring up the database quickly and recover all changes. If you are considering this option, then proceed to "Deciding Whether to Allow Recovery to Corrupt Blocks: Phase 3".

  See Also:

  "Performing Disaster Recovery" to learn how to perform block media recovery with the RECOVER ... BLOCK command

Deciding Whether to Allow Recovery to Corrupt Blocks: Phase 3

When media recovery encounters a problem, the alert log may indicate that recovery can continue if it is allowed to corrupt the data block causing the problem. The alert log contains information about the block: its block type, block address, the tablespace it belongs to, and so forth. For blocks containing user data, the alert log may also report the data object number.

In this case, the database can proceed with recovery if it is allowed to mark the problem block as corrupt. Nevertheless, this response is not always advisable. For example, if the block is an important block in the SYSTEM tablespace, marking the block as corrupt can eventually prevent you from opening the recovered database. Another consideration is whether the recovery problem is isolated. If this problem is followed immediately by many other problems in the redo stream, then you may want to open the database with the RESETLOGS option.

For a block containing user data, you can usually query the database to find out which object or table owns this block. If the database is not open, then you should be able to open the database read-only, even if you are recovering a whole database backup. The following example cancels recovery and opens read-only:

CANCEL
ALTER DATABASE OPEN READ ONLY;

Assume that the data object number reported in the alert_SID.log is 8031. You can determine the owner, object name, and object type by issuing this query:

SELECT OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_TYPE
FROM DBA_OBJECTS
WHERE DATA_OBJECT_ID = 8031;

To determine whether a recovery problem is isolated, you can run a diagnostic trial recovery, which scans the redo stream for problems but does not actually make any changes to the recovered database. If a trial recovery discovers any recovery problems, then it reports them in the alert_SID.log. You can use the RECOVER ... TEST statement to invoke trial recovery, as described in "Executing the RECOVER ... TEST Statement".

After you have done these investigations, you can follow the guidelines in Table 28-6 to decide whether to allow recovery to corrupt blocks.

Allowing Recovery to Corrupt Blocks: Phase 4

If you decide to allow recovery to proceed in spite of block corruptions, then run the RECOVER command with the ALLOW n CORRUPTION clause, where n is the number of allowable corrupt blocks.

To allow recovery to corrupt blocks:

1. Ensure that all normal recovery preconditions are met. For example, if the database is open, then take tablespaces offline before attempting recovery.

2. Run the RECOVER command. The following statements shows a valid example:

   RECOVER DATABASE ALLOW 5 CORRUPTION
   

Performing Trial Recovery

When problems such as stuck recovery occur, you have a difficult choice. If the block is relatively unimportant, and if the problem is isolated, then it is better to corrupt the block. But if the problem is not isolated, then it may be better to open the database with the RESETLOGS option.

Because of this situation, the Oracle Database supports trial recovery. A trial recovery applies redo in a way similar to normal media recovery, but it never writes its changes to disk and it always rolls back its changes. Trial recovery occurs only in memory.

RECOVER DATABASE TEST
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL TEST
RECOVER TABLESPACE users TEST
RECOVER DATABASE UNTIL CANCEL TEST