Understand that this is all secondhand reporting:
I don't believe maxcorrupt was set. It appears that the backup itself
is fine, that the problem is hardware corruption. The hosting company
DBAs are telling me that 'no errors were written into the RMAN logs'
(this is a direct quote). However there are tons of errors (see my
reply to Brian McGraw) in the alert log, and they were not checking for
those errors.
It looks like RMAN is finding corrupted disk blocks when it does the
backup and writing this information to the alert log. Which is fine,
I'm just annoyed that they weren't checking for that, as they are
supposedly experienced RMAN users.
As best as I can determine, we had a massive failure of the disk
subsystem. I had the level 0 backup from Sunday morning restored to
another file system and then ran analyze table validate structure on
the objects with no errors. When we did the same thing on the original
file system, the analyze found corrupted blocks everywhere. A database
with 117 tablespaces and corruption in over 10 datafiles, when the
datafiles are all on the same mount point (don't ask, I don't get to
choose, I'm told "it's SAN, don't worry your little head over I/O
contention") and when that file system mysteriously "disappeared" from
the server for awhile a few hours before corruption started, leads me
to presume massive hardware problems.
But I'm not supposed to be involved in this, I'm just the development
DBA. So how come it's MY problem?
ARGH!!!!!
- Freeman Robert - IL <FREEMANR_at_tusc.com> wrote:
> What do you mean by the "Rman log" rachel? Are you talking about the
> v$backup_corruption view?
>
> From the Oracle RMAN Reference:
>
> If the server session encounters a datafile block during a backup
> that has
> already been identified as corrupt by the database, then the server
> session
> copies the corrupt block into the backup and Oracle logs the
> corruption in
> the control file as either a logical or media corruption. RMAN copies
> the
> block in case the user wants to try to salvage the contents of the
> block.
>
> If RMAN encounters a datafile block with a corrupt header that has
> not
> already been identified as corrupt by the database, then it writes
> the block
> to the backup with a reformatted header indicating that the block has
> media
> corruption.
>
> and then, an interesting note:
>
> RMAN cannot detect all types of block corruption.
>
>
> Of course, if MAXCORRUPT isn't set, the one corruption should kill
> off the
> entire backup as long as that corruption is detected.
>
> Was it the origional backup that was corrupted or was it data after
> it got
> to the tape (because of media corruption/failure)?
>
> RF
>
>
>
> -----Original Message-----
> From: Rachel Carmichael
> To: Multiple recipients of list ORACLE-L
> Sent: 2/26/2003 12:21 PM
> Subject: RE: corrupted block
>
> here's the fun part in this:
>
> this is being handled by the hosting company who manages our
> production
> data center.
>
> apparently rman detects corruption on the restore and writes error
> messages to the alert log, not the rman log. Except the monitoring
> software didn't look for the word "corrupt"
>
>
> --- Stephen Lee <Stephen.Lee_at_DTAG.Com> wrote:
> >
> >
> > > -----Original Message-----
> > >
> > > I'm dealying with the same RMAN not checking corruption -- on
> > 9.2.0.1
> > > and Solaris. and it's a data warehouse.
> > >
> >
> > I've seen it detect corruption, and not detect it. I think it
> > detects some
> > kinds, but not all kinds. It seems to do better with finding it in
> > archived
> > log files than in data files. But that observation is based on a
> > tiny
> > sample of empirical data, so it shouldn't be taken as fact.
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Stephen Lee
> > INET: Stephen.Lee_at_DTAG.Com
> >
> > Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting
> services
> >
> ---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from). You may
> > also send the HELP command for other information (like
> subscribing).
> >
>
>
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Rachel Carmichael
> INET: wisernet100_at_yahoo.com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Rachel Carmichael
INET: wisernet100_at_yahoo.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Wed Feb 26 2003 - 14:48:45 CST
