Deciding Whether to Allow Recovery to Corrupt Blocks: Phase 3

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 `RESETLOGS` option. This response is important for stuck recovery problems, because stuck recovery can be caused by the operating system or a storage system losing writes. If an operating system or storage system suddenly fails, it can cause stuck recovery problems on several blocks.
isolated	in the `SYSTEM` tablespace	Do not corrupt the block, because it may eventually prevent you from opening the database. However, sometimes data in the `SYSTEM` tablespace is unimportant. If you must corrupt a `SYSTEM` block and recover all changes, contact Oracle Support.
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 `RESETLOGS`, then the database is consistent but loses any changes made after the point where recovery was stopped.
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.