Yes, that is what they are about. Proactive monitor looking for corruption at the point of introduction - rather than down the road, later on.

As long as you have a backup and your archives that pre-date the corruption - we can recover from it. That is the rub however, if you don't notice the corruption for six months (no one happened to hit that block until year end for example, running the "close the books" process) - you might not be able to recover as you might not have a six month old backup and all of the archives. The sooner you detect corruption - the higher the probability you have everything you need.

it depends on your needs - else there would just be "the one setting"


You need to understand what they do for you - and what you need as far as data protection and how much you are willing to give extra resource wise to accomplish that.

db lost write protect is for data guard - the rest are for standalone database configurations.

define huge. It is all relative. You need what you need. If your goal is to ensure you detect corruption at the point of introduction - this is a penalty you'll gladly pay.

like you do for redo generation in the first place.
and archiving.
and redo shipping.

You size for it.

I asked Larry Carpenter - author of Oracle Data Guard 11g Handbook (Oracle Press) http://amzn.to/zE82fh

and he said:

<quote>

... it averages about 50 bytes per read block. And those are packed into the redo blocks where there is room, they are not 512 redo blocks all by themselves. So rule of thumb to me would be a 1,000,000 blocks reads would generate around 47MB more redo with it turned on rather than off. ...

</quote>

MOS note 1302539.1 has a good write up, but to explain it briefly:

A- I put "row 1" into a block on the primary, it goes to the standby (via redo) "scn1"
B- I put "row 2" into a block on the primary, it goes to the standby (via redo) "change scn1=>scn2"
C- the *write* of row 2 to disk on the primary is lost, so the block still says "scn1"
D- I put "row 3" into a block on the primary, it goes to the standby (via redo) "change scn1=>scn3"

The standby at that point gets very confused, because "change scn1=>scn3" does align with its view of the block (which is at scn2). It will throw an ora-600 because the primary is basically corrupt.

But notice that "C", the primary is still working just fine. It's *data* is corrupted (we lost a write) but you can query it with no error - you are just getting the wrong results.

But once you hit "D", at that point you are pretty much dead in the water. You have a corrupt primary. And notice when the standby detected it - when we *next* tried to update the block. That could be hours, weeks or months after the lost write occurred. You would probably have to failover to the standby and accept the loss of data.

With "DB_LOST_WRITE_PROTECT" enabled, what we do is that when we *read* data on the primary (not just change it), we add some information to the redo logs reflecting that fact. This can be transmitted to the standby, and so we can detect the lost write potentially much earlier.

You still have to then resolve the issue - MOS note 1265884.1 is the starting place for that.

Well... you *were* going to get a reply.

That's a bit like the "if a tree falls in the forest and no-one is there...does it make sound?" metaphor.

If you've changed a block, then I would assume it is *likely* you will read it reasonably soon (for example, the next backup). However, if for some reason you *never* read that block again until (say) months later, then yes, *that* would be the time you would detect the block corruption...and you'd be in the scenario covered by the MOS note, ie, looking at various options to recover that data.

In the worst case, you'd be looking at Support's assistance to manually fix the blocks...never a pleasant excercise.