this happened 3 times on 3 different archivedlogs in a recent recovery.
Finally customers had to abort the recovery process and then use DUL to
rebuild the database.
About DUL & third party DUL-like tools Refer http://parnassusdata.com/en/emergency-services for more info.
Are you sure that they have write-back caching rather than write-through
caching? If so, how did they enable this? Is this a function of the
hard drive they are using, or some special software they are using?
The reason this is important is that write-back caching is known to corrupt Oracle databases on all platforms, while write-through is safe. The reason is that Oracle has to absolutely guaranteed that when NT claims a write is completed that the data is really on disk. If data that Oracle thinks it has written is still in system memory when NT crashes, then the database will be unrecoverable at that point - the state of the database will be different from what the undo/redo logs claim it should be in.
If you cannot recover the data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.
Parnassusdata Software Database Recovery Team
Service Hotline: +86 13764045638
Leave a Reply