How RMAN Responds to Backup Errors

RMAN detects and responds to two primary types of backup errors: I/O errors and corrupt blocks. This section contains the following topics:

Handling I/O Errors in RMAN Backup: NOT BACKED UP SINCE
Handling Corrupt Datafile Blocks in RMAN Backup: MAXCORRUPT

Handling I/O Errors in RMAN Backup: NOT BACKED UP SINCE

Any I/O errors that RMAN encounters when reading files or writing to the backup pieces or image copies cause RMAN to terminate the backup job in progress. For example, if RMAN tries to back up a datafile but the datafile is not on disk, then RMAN terminates the backup.

If multiple channels are being used, or redundant copies of backups are being created, RMAN may be able to continue the backup without user intervention.

If an error occurs during BACKUP AS BACKUPSET, then RMAN needs to rewrite the backup sets that it was writing at the time of the error. However, for any backup job that creates multiple backup sets, if some backup sets were complete during the error then RMAN retains those backups.

The NOT BACKED UP SINCE option of the BACKUP command backs up only files that are not already backed up since the time specified. You can use this clause after an interrupted backup to resume the backup.

Handling Corrupt Datafile Blocks in RMAN Backup: MAXCORRUPT

When RMAN encounters a corrupt datafile block during a backup, the behavior depends upon whether RMAN has encountered this corrupt block during a previous backup. If the block is already identified as corrupt, then it is included in the backup. If the block is not previously identified as corrupt, then RMAN's default behavior is to stop the backup.

You can override this behavior using the SET MAXCORRUPT command with BACKUP in a RUN block. Setting MAXCORRUPT allows a specified number of previously undetected block corruptions in datafiles during the execution of an RMAN BACKUP command. If RMAN detects more than this number of new corrupt blocks while taking the backup, then the backup job aborts, and no backup is created.

As RMAN finds corrupt blocks during the backup process, it writes the corrupt blocks to the backup with a special header indicating that the block has media corruption. If the backup completes without exceeding the specified MAXCORRUPT limit, then the database records the address of the corrupt blocks and the type of corruption found (logical or physical) in the control file. You can access these records through the V$DATABASE_BLOCK_CORRUPTION view.

Note:

If the backup job aborts because more than MAXCORRUPT corrupt blocks are found, theV$DATABASE_BLOCK_CORRUPTION view is not populated, because the information used to populate the view is only available if a backup is successfully created. In such a situation, you can run BACKUP VALIDATE on the datafiles to be backed up, to populate V$DATABASE_BLOCK_CORRUPTION and use block media recovery to repair the corrupt blocks. See Oracle Database Backup and Recovery Basics for details on using BACKUP... VALIDATE, and "Performing Block Media Recovery with RMAN" for more details on block media recovery.