Re: Production problem: Fuzzy standby database

From: KRIUSHIN, Andrey <>
Date: Sat, 18 Jul 2009 17:47:23 +0400
Message-ID: <>


I remember the discussion on fuzzy files recovery back in 2006. Here is the URL

George, I think you are a little bit optimistic. Can not imagine any structure in the
server code (X$-) or in database/flashback logs/block change tracing files, were one
can find any label/mark showing that "all blocks in the files ..." in fuzzy mode are pulled
out of it. The only mark i'm aware of - the end of thread redo.

Which means you've performed complete recovery, and there are no other changes
left to apply. For example, you've copied current online redo "on the fly" (with a possibility
of corruption), or made a shutdown before such a copy... And even probaly then started up
the instance again... The important point is, that such a redo will have a last redo block in
it. The next one would be either zero or will contain older (sequence number?) redo

Charles, you are in danger right now,

             as you'll fail to activate your standby in usual way, unless you have all the redo (including the current one) from the production. Even in this
case you'll need to emulate "manual switchover", i.e. put current redo in place,
recover database (including that current redo) and then recreate the controlfile.

            This is working scenario (at least in 9iR2 and 10g).

There is still some hope to avoid "flood of blood": switchover.   Indeed, it applyes ALL of the redo from production to the standby, and, hopefully,
resets the fuzziness sign as well. Though I've not tested this scenario personally.
You should experiment yourself.


Johnson, George wrote:
> If I can ask, how were the file backups taken? If you do simple copy or
> split mirror type backups and forget to "begin backup", it does this,
> block SCNs in the files cause the files to go "fuzzy", the answer is to
> keep on applying redo to until you pull all blocks in the files forward
> out of fuzzy mode.

Received on Sat Jul 18 2009 - 08:47:23 CDT

Original text of this message