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

Thanks Jared, I'll do some more tests to see if I can figure out exactly what's going on. I suspect that the direct-insert is minimally logged as it says in the documentation, but perhaps there is still a signifcant amount from dictionary updates due to block splits and other recursive activity, and when you recover, the direct-inserted blocks are corrupt, but the select statement you ran for the regular (non-direct, logged) insert did not need to touch those corrupt blocks so it completed just fine - but if you forced a full index scan, you would see the corruption.  

[Sudhi]

As I understand from the recovery point of view, 'nologging' was supposed to be used for data loads which doesn't need to be recovered. A nologging operation in the redo stream just contains the list of blocks "touched" and an additional redo which when applied marks them as "soft corrupt".  

>From the set of operations, a update or delete will always be logged. A
nologging insert will definitely make some changes to the set of undo blocks the tx is using. The changes done to these undo blocks always gets recorded. All recursive changes have to be logged.  

Either from 8 or 8i whenever a block which has undergone a nologging operation is queried, we should see ora-26040 and versions before that used the traditional ora-1578.  

Thanks,

-Sudhi.

Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.

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