FreeLists / oracle-l / RE: RMAN fails because of corrupt block in seemingly free space in SYSTEM

[Job Miller <jobmiller@xxxxxxxxx>]

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@xxxxxxxxxxxxxxx wrote:
       

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com