|
Atul,
Using "_OFFLINE_ROLLBACK_SEGMENTS" or
"_CORRUPTED_ROLLBACK_SEGMENTS" might allow you to open the database, but there
is an almost absolute certainty that you will hopelessly corrupt
the data in the database in doing so. So this is not a solution, this
is the absolute very LAST resort.
Instead, using these parameters usually means
that you will be initiating a complete dump all of the data out of
this database in order to load it into a "fresh" new uncorrupted
one. Please do NOT consider using these parameters unless you've
exhausted all other possibilities, and absolutely do NOT use them without
logging a SEV-1 TAR and having an Oracle Support analyst on the phone
throughout.
The danger of these parameters is that just about everyone
has heard about them, but very few clearly understand how they work and the
implications. Roughly put, the "_OFFLINE_ROLLBACK_SEGMENTS" parameter
means that Oracle will attempt to determine whether the transaction has been
committed or rolled back. If it can, it will put things right. If it
can't, Oracle will just simply commit the transaction. Of course, it may
have been that the transaction was never committed, thus corruption.
Roughly, the "_CORRUPTED_ROLLBACK_SEGMENTS" parameter means that the rollback
segment in question is hopeless, and Oracle will simply commit any uncommitted
transaction that were using it. Again, this is very scary...
---
The best solution to data block corruption?
Data block corruption should first be treated exactly like
media failure. That is, exactly like a failed disk drive. Restore an
older copy of the datafile from a backup that occurred prior to the detection of
the corruption, and recover forward until a complete recovery has been
performed.
But first, before doing even that, please verify that the
database block indicated is really corrupt. The ALTER SYSTEM DUMP DATAFILE
<file#> BLOCK <block#> command will make a symbolic dump of the
block to a ".trc" file in your USER_DUMP_DEST directory. The error message
has the "file#" and "block#" values in it, so please use those then examine the
resulting ".trc" file. If it truly is corrupt, there will some obvious
indication the ".trc" file (i.e. it'll say "corrupted").
Then, please backup the datafile in question before
restoring over it, just out of caution. Or, if you know how, rename the
datafile and restore it from backup to the new location. Either way, don't
wipe out the datafile with the corruption if you can help it...
Hope this helps...
-Tim
|
- Re: rbs oracle data block corrupted Danisment Gazi Unal (ubTools)
- Re: rbs oracle data block corrupted Nikunj Gupta
- RE: rbs oracle data block corrupted Tim Gorman
- RE: rbs oracle data block corrupted Atul Kumar Srivastav
- Re: rbs oracle data block corrupted Danisment Gazi Unal (ubTools)
