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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
