How RMAN Responds to Backup Errors

How RMAN Responds to I/O Errors During Backup

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 BACKUP AS BACKUPSET creates more than one complete backup set and an error occurs, then RMAN needs to rewrite the backup sets that it was writing at the time of the error. However, it retains any backup sets that it successfully wrote before terminating.

The NOT BACKED UP SINCE option of the BACKUP command restarts a backup that partially completed, backing up only files that did not get backed up.

How RMAN Responds to Corrupt Blocks During Backup

RMAN copies datafile blocks that are already identified as corrupt into the backup. If RMAN encounters datafile blocks that have not already been 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 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.