| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
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 |
| 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:
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 |
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 theBLOCKRECOVER command |
