RE: ORA-01499 even after drop recreating ALL indexes (minus PK, UK)

From: <Christopher.Taylor2_at_parallon.net>
Date: Tue, 29 Jan 2013 16:35:44 -0600
Message-ID: <F05D8DF1FB25F44085DB74CB916678E8857042F87E_at_NADCWPMSGCMS10.hca.corpad.net>



Looks like a BOGUS error after crosschecking a full table scan with an index scan - no rowid differences between the 2 sets of results.

Chris

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

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Christopher.Taylor2_at_parallon.net Sent: Tuesday, January 29, 2013 2:36 PM
To: oracle-l_at_freelists.org
Subject: ORA-01499 even after drop recreating ALL indexes (minus PK, UK)

Ok, so I have to actually chuckle about this since it's got me stumped. I have a theory but need to verify.

I have a missing ROWID in an INDEX so I dropped it and recreated it.

Run analyze table, validate structure - boom. Invalid rowid again.

Drop all indexes other than PK and UK and reanalyze table.

Analyze comes back clean with PK and UK indexes in place. Ok.

Recreate the dropped indexes.

Analyze table.

Bam. Missing Rowid.

Weird thing is, after the index is recreated it has the same data_block_address_file and data_block_address_block entries.

(that is, each time the index is recreated, the offending block is "row not found in index tsn: 16 rdba: 0x05cb87ac")

The RDBA and TSN is always the same. That strikes me as odd, but perhaps a block on the data storage device is bad? But I find it odd that the same index would hit the same block every time.

Chris Taylor
Oracle DBA
Parallon IT&S

--

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

--

http://www.freelists.org/webpage/oracle-l Received on Tue Jan 29 2013 - 23:35:44 CET

Original text of this message