Misconception: After activating a standby, the primary requires re-copying to become the standby

 

Jeremiah Wilton

jwilton@speakeasy.net

 

When switching to a standby database, there are two basic scenarios.  In one scenario, the switchover is undertaken in an emergency, and due to the unavailability of the primary host or the storage, the final one or two redologs are not available, and therefore cannot be applied to the standby.  In such a case, the standby must be activated after incomplete recovery, without applying the last changes from the primary.  This scenario is extremely rare.

The second, and much more likely scenario, is that the switchover is undertaken as a planned event, to perform maintenance on the primary host, or in an emergency event that does not preclude access to the most recent couple redologs. In such a scenario, complete recovery of the standby up to the point that the primary was stopped is both possible and advisable.  By opening the standby without resetlogs as of that point in time, it is possible to immediately press the primary database into service as a standby without re-copying the database.

When you fail over to a standby, you shut down the primary, apply all the archived redologs to the standby, then copy all the online logs and the controlfile from the primary to the standby.  People who use incremental checkpoints (FAST_START_MTTR_TARGET in 9i, FAST_START_IO_TARGET in 8i) must do a 'create controlfile reuse database <blah> noresetlogs' at this point.  Other people don't have to.

Finally, you ‘recover database’ to get the last one or two online logs and open the standby "noresetogs."  The standby just picks up the chain of SCNs where the primary left off.

The old primary can be immediately pressed into service as a standby.  Just generate a standby controlfile on the new primary, copy it into place on the old primary and start it up as a standby database.

You can go back and forth in this way as many times as you want.  One database just picks up the chain of SCNs where the last one left off.  You never get a divergence of changes between the two.

It is worth noting that in 9i, they have an "automated" graceful failover mechanism for standby databases.  I have not yet tested this feature to determine if it is any different from the method described here.