517.Which of the following are true concerning block media recovery? (Choose all that apply.)
A. Any gap in archive logs ends the recovery.
B. If a gap in archive logs is encountered, RMAN will search forward for newer versions of the blocks that are not corrupt.
C. Uncorrupted blocks from the flashback logs may be used to speed recovery.
D. The database can be in NOARCHIVELOG mode.
E. None of the above.
Answer: BC
答案解析：
參考：http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmblock.htm#BRADV89784
Like data file media recovery, block media recovery cannot generally survive a missing or inaccessible archived log, although it attempts restore failover when looking for usable copies of archived redo log files, as described in "Restore Failover". Also, block media recovery cannot survive physical redo corruptions that result in checksum failure. However, block media recovery can survive gaps in the redo stream if the missing or corrupt redo records do not affect the blocks being recovered. Whereas data file recovery requires an unbroken series of redo changes from the beginning of recovery to the end, block media recovery only requires an unbroken set of redo changes for the blocks being recovered.
Note:
Each block is recovered independently during block media recovery, so recovery may be successful for a subset of blocks.When RMAN first detects missing or corrupt redo records during block media recovery, it does not immediately signal an error because the block undergoing recovery may create one later in the redo stream. When a block is re-created, all previous redo for that block becomes irrelevant because the redo applies to an old incarnation of the block. For example, the database creates a new a block when users drop or truncate a table and then use the block for other data.
Assume that media recovery is performed on block 13 as depicted in Figure 19-1.
Figure 19-1 Performing RMAN Media Recovery
Description
of "Figure 19-1 Performing RMAN Media Recovery"After block recovery begins, RMAN discovers that change 120 is missing from the redo stream, either because the log block is corrupt or because the log cannot be found. RMAN continues recovery assuming that block 13 will be re-created later in the redo stream. Assume that in change 140 a user drops the table employees stored in block 13, allocates a new table in this block, and inserts data into the new table. At this point, the database formats block 13 as a new block. Recovery can now proceed with this block even though some redo preceding the recreation operation was missing.
The following prerequisites apply to the RECOVER ... BLOCK command:
The target database must run in ARCHIVELOG mode and be open or mounted with a current control file.
If the target database is a standby database, then it must be in a consistent state, recovery cannot be in session, and the backup must be older than the corrupted file.
The backups of the data files containing the corrupt blocks must be full or level 0 backups and not proxy copies.
If only proxy copy backups exist, then you can restore them to a nondefault location on disk, in which case RMAN considers them data file copies and searches them for blocks during block media recovery.
RMAN can use only archived redo logs for the recovery.
RMAN cannot use level 1 incremental backups. Block media recovery cannot survive a missing or inaccessible archived redo log, although it can sometimes survive missing redo records.
Flashback Database must be enabled on the target database for RMAN to search the flashback logs for good copies of corrupt blocks.
If flashback logging is enabled and contains older, uncorrupted versions of the corrupt blocks, then RMAN can use these blocks, possibly speeding up the recovery.
The target database must be associated with a real-time query physical standby database for RMAN to search the database for good copies of corrupt blocks.
