Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
Table 21-1, "Media Recovery Problems" describes potential problems that can occur during media recovery.
Table 21-1 Media Recovery Problems
Problem | Description |
---|---|
Missing or misnamed archived log |
Recovery stops because the database cannot find the archived log recorded in the control file. |
When you attempt to open the database, error |
This error commonly occurs because:
|
Two possible cases are as follows:
|
|
Logs may be corrupted while they are stored on or copied between storage systems. If |
|
If you enable the parallel redo feature, then the database generates redo logs in a new format. Prior releases of Oracle are unable to apply parallel redo logs. However, releases prior to Oracle9i Release 2 (9.2) can detect the parallel redo format and indicate the inconsistency with the following error message: See Also: Oracle Database Performance Tuning Guide to learn about the parallel redo feature |
|
A datafile backup may have contained a corrupted data block, or the data block may become corrupted either during recovery or when it was copied to the backup. If checksums are being used, then the database signals a checksum error. Otherwise, the problem may also appear as a redo corruption. |
|
Random problems |
Memory corruptions and other transient problems can occur during 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, whether 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. Note that the RESETLOGS
restrictions apply to opening the 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 21-1, "Media Recovery Problems".
The basic methodology for responding to media recovery problems occurs in the following phases:
Try to identify the cause of the problem. Run a trial recovery if needed.
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 21-2.
If you cannot resolve the problem using the methods described in Table 21-2, 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