18 Performing Block Media Recovery

Overview of Block Media Recovery

This section explains the purpose and basic concepts of block media recovery.

Basic Concepts of Block Media Recovery

In most cases, the database marks a block as media corrupt and then writes it to disk when the corruption is first encountered. No subsequent read of the block will be successful until the block is recovered. You can only perform block recovery on blocks that are marked corrupt or fail a corruption check.

You perform block media recovery with the RECOVER ... BLOCK command. By default, RMAN searches the flashback logs for good copies of the blocks, and then searches for the blocks in full or level 0 incremental backups. When RMAN finds good copies, it restores them and performs media recovery on the blocks. Block media recovery can only use redo logs for media recovery, not level 1 incremental backups.

See Also:

Oracle Database Backup and Recovery Reference for RECOVER ... BLOCK syntax

Identification of Corrupt Blocks

The V$DATABASE_BLOCK_CORRUPTION view displays blocks marked corrupt by database components such as RMAN commands, ANALYZE, dbv, SQL queries, and so on. The following types of corruption result in rows added to this view:

• Physical corruption (sometimes called media corruption)

  The database does not recognize the block: the checksum is invalid, the block contains all zeros, or the block header is fractured.

  Physical corruption checking is enabled by default. You can turn off checksum checking by specifying the NOCHECKSUM option of the BACKUP command, but other physical consistency checks, such as checks of the block headers and footers, cannot be disabled.

• Logical corruption

  The block has a valid checksum, the header and footer match, and so on, but the contents are logically inconsistent. Block media recovery cannot repair logical block corruption.

  Logical corruption checking is disabled by default. You can turn it on by specifying the CHECK LOGICAL option of the BACKUP, RESTORE, RECOVER, and VALIDATE commands.

The database can detect some corruptions by validating relationships between blocks and segments, but cannot detect them by a check of an individual block. The V$DATABASE_BLOCK_CORRUPTION view does not record this type of corruption.

Missing Redo During Block Recovery

Like datafile media recovery, block media recovery cannot generally survive a missing or inaccessible archived log, although it will attempt 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 datafile 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 become a newed block later in the redo stream. When a block is newed all previous redo for that block becomes irrelevant because the redo applies to an old incarnation of the block. For example, the database can 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 the following figure.

Figure 18-1 Performing RMAN Media Recovery

Description of "Figure 18-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 in the hope that block 13 will be newed 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 newing operation was missing.

Prerequisites for Block Media Recovery

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.

• The target database must not be a standby database.

• The backups of the datafiles 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 datafile 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.

Recovering Individual Blocks

Typically, block corruption is reported in the following locations:

• Results of the LIST FAILURE, VALIDATE, or BACKUP ... VALIDATE command

• The V$DATABASE_BLOCK_CORRUPTION view

• Error messages in standard output

• The alert log

• User trace files

• Results of the SQL commands ANALYZE TABLE and ANALYZE INDEX

• Results of the DBVERIFY utility

• Third-party media management output

For example, you may discover the following messages in a user trace file:

ORA-01578: ORACLE data block corrupted (file # 7, block # 3)
ORA-01110: data file 7: '/oracle/oradata/trgt/tools01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 235)
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'

In the following procedure, you identify the blocks that require recovery and then use any available backup to perform the restore and recovery of these blocks.

To recover specific data blocks:

1. Obtain the datafile numbers and block numbers of the corrupted blocks.

   Note that the easiest way to locate trace files and the alert log is to connect SQL*Plus to the target database and execute the following query:

   SELECT NAME, VALUE 
   FROM   V$DIAG_INFO;
   

2. Start an RMAN session on the target database and make sure the database is mounted or open.

3. Run the SHOW ALL command to make sure that the appropriate channels are preconfigured.

4. Run the RECOVER ... BLOCK command at the RMAN prompt, specifying the file and block numbers for the corrupted blocks.

   Example 18-1 recovers two blocks.

   Example 18-1 Recovering Blocks by Using All Available Backups

   RECOVER 
     DATAFILE 8 BLOCK 13 
     DATAFILE 2 BLOCK 19;
   

   You can also specify various options to control RMAN behavior. Example 18-2 indicates that only backups with tag mondayam will be used when searching for blocks. You could use the FROM BACKUPSET option to restrict the type of backup that RMAN searches, or EXCLUDE FLASHBACK LOG to restrict RMAN from searching the flashback logs.

   Example 18-2 Recovering Blocks from a Backup with a Specific Tag

   RECOVER 
     DATAFILE 8 BLOCK 13 
     DATAFILE 2 BLOCK 199
     FROM TAG mondayam;
   

Recovering All Blocks in V$DATABASE_BLOCK_CORRUPTION

In this scenario, RMAN automatically recovers all blocks listed in the V$DATABASE_BLOCK_CORRUPTION view.

To recover all blocks logged in V$DATABASE_BLOCK_CORRUPTION:

1. Start a SQL*Plus session on the target database and query V$DATABASE_BLOCK_CORRUPTION to determine whether corrupt blocks exist. For example, execute the following statement:

   SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;
   

2. Recover all blocks marked corrupt in V$DATABASE_BLOCK_CORRUPTION.

   The following command repairs all physically corrupted blocks recorded in the view:

   RECOVER CORRUPTION LIST;
   

   After the blocks are recovered, the database removes them from V$DATABASE_BLOCK_CORRUPTION.