RE: ORA-1578...block corrupted...error is normal...a block...had a NOLOGGING...operation performed against
- From: "Sudhi" <sudhi@xxxxxxxxxxxxx>
- To: <Brandon.Allen@xxxxxxxxxxx>, "'Jared Still'" <jkstill@xxxxxxxxx>
- Date: Wed, 24 Aug 2005 03:51:53 +0530
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.
Other related posts: