RE: Block corruption again

From: CRISLER, JON A <JC1706_at_att.com>
Date: Thu, 29 Dec 2011 19:57:40 +0000
Message-ID: <9F15274DDC89C24387BE933E68BE3FD315B1D2_at_MISOUT7MSGUSR9D.ITServices.sbc.com>



On what Chris is saying- there is a known problem on 11gR1 where objects can get corrupted if you are in a Data Guard environment, and do a switchover and then switchback. Generally it seems to affect indexes, and it will also cause ORA-01555 errors. Rebuilding the index solves the problem until you put in a patch. You should also look into putting in the parameters to enforce a more strict level of block checking.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Taylor, Chris David Sent: Thursday, December 29, 2011 8:31 AM To: 'howard.latham_at_gmail.com'; 'Jiang, Lu'; 'oracle-l_at_freelists.org' Subject: RE: Block corruption again

Seems to me if this was a hardware problem, and all the datafiles are on the same LUN, then block corruptions would be occurring in more than 1 file.

Being that this is an index datafile, I would assume that it only contains index segments so it might be worthwhile tracking down which index contains the corrupted block.

What version of Oracle are you running, and is there anything special about this database (Dataguard configuration etc etc)?

Chris Taylor
Sr. Oracle DBA
Ingram Barge Company
Nashville, TN 37205

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

CONFIDENTIALITY NOTICE: This e-mail and any attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender immediately and delete the contents of this message without disclosing the contents to anyone, using them for any purpose, or storing or copying the information on any medium.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Howard Latham Sent: Wednesday, December 28, 2011 1:52 PM To: Jiang, Lu; oracle-l_at_freelists.org Subject: RE: Block corruption again

Check and replace hardware

Sent from my Windows Phone
From: Jiang, Lu
Sent: 28/12/2011 19:46
To: oracle-l_at_freelists.org
Subject: Block corruption again
Hi all,
I just got a corrupt block again, had fixed a block corruption in a same index file two weeks ago. Don't know why this happened twice in such a sort period.

I tried rman validate and dbverify to detect the corruption, but rman validate did not report any data corruption while dbverify did.

Could anyone shed any light on this?

Thanks,
Lu

The following is the output from rman validate and dbverify.

Using backup validate:

RMAN> backup check logical validate datafile 'F:\ORACLE\ERPPROD\DB\APPS_ST\DATA\A_TXN_IND01.DBF'; Starting backup at 28-DEC-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fnochannel ORA_DISK_1: backup set complete, elapsed time: 00:00:25
Finished backup at 28-DEC-11

Using dbverify:

dbv FILE=F:\ORACLE\ERPPROD\DB\APPS_ST\DATA\A_TXN_IND01.DBF FEEDBACK0 Corrupt block relative dba: 0x06426321 (file 25, block 156449) Bad check value found during dbv: .......
DBVERIFY - Verification complete

Total Pages Examined         : 393216
Total Pages Processed (Data) : 2782
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 93966
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 19301
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 277166
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Highest block SCN            : 1326171528 (0.1326171528)

Looks rman validate did not ddetect any data corruption while dbverify did.

--

http://www.freelists.org/webpage/oracle-l
--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Thu Dec 29 2011 - 13:57:40 CST

Original text of this message