RE: RMAN fails because of corrupt block in seemingly free space in SYSTEM
- From: Job Miller <jobmiller@xxxxxxxxx>
- To: Mark.Bobak@xxxxxxxxxxxxxxx, Uldis.Pavuls@xxxxxxxxxxxxxxx, rshamsud@xxxxxxxxxxxx
- Date: Wed, 3 Jan 2007 10:03:36 -0800 (PST)
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
Other related posts:
