This was first published on https://blog.dbi-services.com/set-stateapply-off-and-datafile-consistency (2015-09-06)
Republishing here for new followers. The content is related to the the versions available at the publication date

set state=apply-off and datafile consistency

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.

 

One Comment