By Franck Pachot

.
In 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.

Here is the buffer cache status summary in a Data Guard standby database instance:


SQL> select status,count(*) from v$bh group by status;
 
STATUS       COUNT(*)
---------- ----------
free             1473
memory              2
mrec             4846

The 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.

Let’s see what happens when we stop the apply:


DGMGRL> edit database demo12 set state=apply-off;
Succeeded.

The alert.log shows that the data files are in a consistent state, which is similar to a checkpoint:


Recovery interrupted!
Recovered data files to a consistent state at change 5683001

And here is the buffer cache:


SQL> select status,count(*) from v$bh group by status;
 
STATUS       COUNT(*)
---------- ----------
free             6344

All my MREC blocks have become free, as with any checkpoint.

It’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.