RE: Lost Writes
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <mwf@xxxxxxxx>, <charlottejanehammond@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 6 Aug 2009 10:01:26 -0400
Please note that the latter section is what you'd have to do yourself to
avoid the overhead of DB_LOST_WRITE_PROTECT (materializing first vintage
cached reads in the redo log). Don't really try to do that. After posting I
realized it is not clear I'm making a joke about trying to do it yourself to
avoid the overhead of DB_LOST_WRITE_PROTECT.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Mark W. Farnham
Sent: Thursday, August 06, 2009 9:32 AM
To: charlottejanehammond@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Lost Writes
DB_LOST_WRITE_PROTECT, see manual B28270-03. There is some overhead.
You mentioned you're using RMAN, so it is possible you could have used block
recovery from a backup before the lost write(s) if you have the thread of
redo logs from that point to the present. If you have the thread of redo for
the file from its creation, then you could have also recovered the whole
file from thin air (and the redo logs.)
Now, as you mentioned a required component of generating the problem is that
the i/o subsystem loses the write but tells Oracle it made the write. But
you also note that there was a disk fault. So the disk fault should trigger
verification of the contents of that disk. If it throws faults too often,
then the disk should be retired. What would be worse is if the disk
subsystem lost a write and did not throw any fault. Then you really couldn't
use that i/o subsystem for anything important without implementing a
paranoid scheme for error detection. (Paranoid means "a good dba" in this
context.) If you must use a disk i/o subsystem that is not or never should
have been certified for use with Oracle databases, then the basic paranoid
scheme is to mine your redo log and force a read of each modified block in
Oracle and compare it to a block read in your program from the actual disk
block address. You've got to that to verify that the block (that could still
be in the Oracle cache) from Oracle matches the block on disk. Of course if
there is a delayed block cleanout you might get a false positive that you'd
have to figure out how to resolve.
Better to use disk subsystems that at least throw a fault when they lose a
write, and then to not ignore disk faults.
<snip>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
