.
\nIn a standby database (or in any database you recover) do you think the recovery uses buffer cache? And when you stop the apply in a standby database, do you think the datafiles are in a consistent state? We know the answer, but want to prove it. This is the kind of question you may have, as I did last Friday morning in the train with Ludovico Caldara when going to the Paris Oracle Meetup.
\n
\nHere is the buffer cache status summary in a Data Guard standby database instance:
\nSQL> select status,count(*) from v$bh group by status;\n \nSTATUS COUNT(*)\n---------- ----------\nfree 1473\nmemory 2\nmrec 4846\nThe MREC status is the status of the blocks where redo from recovery is applied. It’s a current version of the block for recovery purpose only.
\nLet’s see what happens when we stop the apply:
\n\nDGMGRL> edit database demo12 set state=apply-off;\nSucceeded.\nThe alert.log shows that the data files are in a consistent state, which is similar to a checkpoint:
\n\nRecovery interrupted!\nRecovered data files to a consistent state at change 5683001\nAnd here is the buffer cache:
\n\nSQL> select status,count(*) from v$bh group by status;\n \nSTATUS COUNT(*)\n---------- ----------\nfree 6344\nAll my MREC blocks have become free, as with any checkpoint.
\nIt’s exactly what we expected, but sometimes I just want to prove it to myself because there can be bugs, implementation oddities, or simply something that I overlooked. Now I’m conviced: the physical standby data files are consistent after an apply-off.
\n", "protected": false } }