Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-02 |
|
|
View PDF |
When media recovery encounters a problem, the alert_
SID
.log
may indicate that recovery can continue if it is allowed to corrupt the data block causing the problem. The alert_
SID
.log
always 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, it reports them in the alert_
SID
.log
. You can use the RECOVER
...
TEST
statement to invoke trial recovery.
See Also:
"Performing Trial Recovery"After you have done these investigations, you can follow the guidelines in Table 21-3 to decide whether to allow recovery to corrupt blocks.
Table 21-3 Guidelines for Allowing Recovery to Permit Corruption
If the problem is . . . | and the block is . . . | Then . . . |
---|---|---|
not isolated |
n/a |
You should probably open the database with the |
isolated |
in the |
Do not corrupt the block, because it may eventually prevent you from opening the database. However, sometimes data in the |
isolated |
index data |
Consider corrupting index blocks because the index can be rebuilt later after the database has been recovered. |
isolated |
user data |
Decide based on the importance of the data. If you continue with datafile recovery and corrupt a block, you lose data in the block. However, you can use RMAN to perform block media recovery later after datafile recovery completes. If you open |
isolated |
rollback or undo data |
Consider corrupting the rollback or undo block because it does not harm the database if the transactions that generated the undo are never rolled back. However, if those transactions are rolled back, then corrupting the undo block can cause problems. If you are unsure, then call Oracle Support. |
See Also:
"Performing Trial Recovery" to learn how to perform trial recovery, and "Allowing Recovery to Corrupt Blocks: Phase 4" if you decide to corrupt blocks