RE: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against

Chris,

This seems surprising to me also. It seems to me that subsequent full backups should have allowed these objects to be recovered. Does the NOLOGGING attribute stay with the index after it has been created? It doesn't, correct?

I never use NOLOGGING because I didn't need to. But your situation seems to be an argument for never using it.

At least you can drop and recreate the index to fix the problem.

Tom

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Joel Garry Sent: Friday, August 19, 2005 1:09 PM
To: oracle-l_at_freelists.org
Subject: Re: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against

Chris Marquez wrote:

>I can NOT believe the if I used NOLOGGING to create and INDEX "long
ago" *and*
had
>many, many subsequent FULL BACKUPS that it could/did effect or error on
a
future recovery?

>Again, we are getting this error after full db recovery on indexes
created
>(NOLOGGING), well before the FULL backup and thus no "NOLOGGING"
objects in any
>of the arch logs applied...what gives?

Believe it. Time bomb sat there since long ago. Nologging operations bypass the redo logs. So they bypass the archived logs. So when you restore the datafile by rolling forward, you invalidate those blocks. So you have to fix them with some other mechanism than recovery. Maybe use force logging if you don't want to run into this again. And all that advice about taking a backup after nologging operations seems pretty misleading, huh?

In the end, surely you realize that you, the DBA, are taking responsibility for _any_ previous nologging operations in the case of restoration?

Joel Garry
http://www.garry.to

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