Block corruption nologging

Question

Hi,
Db :11.2
Some of the blocks are corrupted on the database.It shows nologging in corruption_type column in  v$database_block_corruption.
It's a test envirnoment,archive not enabled.
Should i restore old backup? or any other way to solve it.
Reagards,
Raj

Answer 1

NOLOGGING corruption seems to be a largely misunderstood phenomenon.
Normally, all data changes are logged to the redo log.  Oracle logs the "change vectors" to the redo log.  In the event of a corruption, you restore the datafile from a backup, and then apply archivelogs to the datafile, to apply all the changes from the time of the backup until the time of the corruption.  The idea is, you're "playing back" the transactions that were recorded in the redo logs.  Oracle will apply all changes from all archived redo logs, and then all changes from the online redo logs.  In this way, you can recover up to the last committed transaction.
Now, in the event of a NOLOGGING operation, Oracle does *not* record your change in the redo log.  Instead, it only writes extent invalidation records.  During normal operation, this is ok, as NOLOGGING changes are written directly to the datafile.  But, what happens if you do a recovery, from a backup taken *before* the NOLOGGING operation?  Well, when the archived redo log is applied, and it gets to the point where the NOLOGGING operation took place, there's no data recorded in the redo log.  Instead, it writes those extent invalidation records.  So, there's no error at recovery time, but then, when you try to access data in that block, you get an ORA-26040 "Data was loaded using the NOLOGGING option".  Oracle has no choice, cause the data is simply not available.
So, the only real solution is to reload the data.  If it's an index, it's easy, simply rebuild the index.  If it's a table, it may be more problematic.  You'll need to truncate the table, and reload the data.  If it's a partitioned table, you should be able to only truncate and reload the affected partition(s).
Finally, how to avoid this situation in the future?  Well, all you need to do is make sure you schedule a backup *after* you complete your NOLOGGING data loads.  Keep in mind, in a NOLOGGING data load is written directly to the datafiles, so if you take a backup after the NOLOGGING load is complete, then you'll have that data in the datafiles that were backed up.  No need to apply those logs w/ the NOLOGGING extent invalidation records, cause they will be older than the datafiles.
Hope that's clear,
-Mark