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 methods described in Table 21-2. Note that these methods are fairly safe: in almost all cases, they should not cause any damage to the database.

Table 21-2 Media Recovery Solutions

If you suspect . . .	Then . . .
Missing/misnamed archived logs	Determine whether you entered the correct filename. If you did, then check to see whether the log is missing from the operating system. If it is missing, and you have a backup, then restore the backup and apply the log. If you do not have a backup, then if possible perform incomplete recovery up to the point of the missing log.
`ORA-1113` `for` `ALTER` `DATABASE` `OPEN`	Review the causes of this error in Table 21-1, "Media Recovery Problems". Make sure that all read/write datafiles requiring recovery are online. If you use a backup control file for recovery, then the control file and datafiles must be at a consistent SCN for the database to be opened. If you do not have the necessary redo, then you must re-create the control file.
Corrupt archived logs	The log is corrupted if the checksum verification on the log redo block fails. If `DB_BLOCK_CHECKSUM` is not enabled either during the recovery session or when the database generated the redo, then recovery problems may be caused by corrupted logs. If the log is corrupt and an alternate copy of the corrupt log is available, then try to apply it and see whether this tactic fixes the problem. The `DB_BLOCK_CHECKSUM` initialization parameter determines whether checksums are computed for redo log and data blocks.
Archived logs with incompatible parallel redo format	If you are running an Oracle release prior to Oracle9i Release 2, and if you are attempting to apply redo logs created with the parallel redo format, then you must do the following steps: Upgrade the database to a later release. Perform media recovery. Shut down the database consistently and back up the database. Downgrade the database to the original release. See Also: Oracle Database Performance Tuning Guide to learn about the parallel redo feature
Memory corruption or transient problems	You may be able to fix the problem by shutting down the database and restarting recovery. The databse should be left in a consistent state if the second attempt also fails.
Corrupt data blocks	Restore and recover the datafile again with user-managed methods, or restore and recover individual data blocks with the RMAN `BLOCKRECOVER` command. This tactic may fix the problem. A data block is corrupted if the checksum verification on the block fails. If `DB_BLOCK_CHECKING` is disabled, a corrupted data block problem may appear as a redo problem. If you must proceed with recovery, then you may want to corrupt the block now and continue recovery, and use RMAN to perform block media recovery later.

If you cannot fix the problem with the methods described in Table 21-2, 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 proceed with media recovery. This option will only succeed if the alert_SID.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 it is important to bring up the database quickly and recover all changes. If you are contemplating this option as a last resort, 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 BLOCKRECOVER command