I'm not aware of the MAXCORRUPT parameter. There were two blocks involved. We think it was caused by an incompatibility between an OS driver and some piece of new storage hardware. The symptoms were that any query (including an export) that scanned table would be going along then suddenly get an object does not exist error. dbv correctly identified the blocks. rman not only didn't detect them, but backed up and restored the corruption.
It was originally filed as a severity 1 TAR. The TAR people promptly reassigned it to severity 2, then did absolutely nothing with it. After I figured out a solution, I waited another day to see if anything would ever be done with the TAR. It wasn't, so I called back and talked to a supervisor. I let her know what the situation was, and was told that this would be referred to the rman group -- a statement on which I have bet no money. > -----Original Message----- > > Stephen > RMAN ignored your corrupted block? Ya gotta tell us more man! We're > relying on it to catch everything. Did you have the > MAXCORRUPT parameter > set? > -- 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).
