| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN fails because of corrupt block in seemingly free space in SYSTEM
the snippet of docs to support the approach Mark suggested on the backup side:
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.
you are able to extract information about this corruption in those views now though right? despite the fact that you haven't completed a backup with maxcorrupt > 0. Doesn't this sound like that info isn't populated unless it completes?
Job
Uldis.Pavuls_at_tietoenator.com wrote:
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jan 03 2007 - 12:03:36 CST
 |
 |