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

Once again, this list has proven amazingly beneficial. We recently had a hardware failure of some sort ( cause of the failure is still being 'negotiated') and several blocks were corrupted. At this point, I think I have found and recovered the corrupt areas, but I started reading this thread and ran a few extra queries, discovering that 8 tables and lots of indexes are currently set to nologging. There were also 17 files that reported unrecoverable changes from way back when.

I can't think of ANY reason to do this and was totally stunned to find it. Does forcing logging at the system level cover this? Anybody ever heard of a good justification for it?

Robyn

On 8/23/05, BobMetelsky <bobmetelsky_at_comcast.net> wrote:
> Hi Tom, I appreciate your response , my comments inline
>
> >
> > If you are running in NOARCHIVELOG mode, you *always* have to backup
> > your database daily to be able to recover it to when you backed it up -
> > you do not get any recovery option other than that.
>
> Yes, I understand that, I do weekly cold backups
> >
> > If you are running in NOARCHIVELOG mode and you turn logging on, you
> > must perform a backup immediately to be able to perform point in time
> > reovery from that point forward.
>
> Ok, at this point I have a cold backup which has objects created with
> NOLOGGING (even though the database was in NOARCHIVELOG),
> in other words these segments are "marked" in the dictionary as being
> created with LOGGING=N
>
> Q? - from that point on - will recovery *ever* complain about corrupt
> blocks which were created *before" the backup?
> Note the database is in NOARCHIVE, and at a time in the "future" will
> archiving turned on
>
> Q? - How does the segment get marked/reset LOGGING= ? in the
> dictionary,or block header?
> Im guessing this would be how the problem comes to haunt you. IOW this
> is how Oracle would "know" if the segment was affected by NOLOGGING, and
> I would think this needed to be reset somehow.
>
> The original poster was surprised how long the problem stayed dormant ,
> I'm thinking he must have done backups during that time frame....?
>
> so, my mis understanding is with the dictionary / block header flags
>
> My understanding or your reply is that the database can be rolled
> forward from the last backup, which is what I would expect.
> Although if I wanted to recover from point in time I would risk this
> situation of corrupt blocks.
> Using NOLOGGING I could only roll forward from the last backup
>
> Thanks
> bob
> >
> > So the lesson learned here is to either create an object in the normal
> > way (with archiving enabled) or use the NOLOGGING option and always
> > schedule a backup to protect what you just created.
> --
> http://www.freelists.org/webpage/oracle-l
>

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