Using the RESETLOGS Option to Instantiate Data with an Activated Standby Database

Problem Description

This article explains how to use RESETLOGS option to Instantiate Data with an Activated standby database.

Solution

The basic approach to using the RESETLOGS option to instantiate data in a Dbvisit Replication configuration with an activated Standby database is outlined in the following user guide article:

https://dbvisit.atlassian.net/wiki/display/ugd7/Standby+Database

But some additional specifics which you may find helpful:

Prior to this we used Dbvisit Standby on the test servers (was already running there) to create a new, second standby database (with different db_unique_name) as outlined in the following blog post. In doing so we kept the  existing standby database intact, but used the CSD functionality of Dbvisit Standby to do the "hard work" of generating the new standby database, which we were going to activate, as our new target database. You could choose some other method for this if you like, although Dbvisit Standby does make the process really easy, including creating the standby database manually yourself:

http://blog.dbvisit.com/how-to-set-up-multiple-standby-databases-with-dbvisit-standby/

So once that was installed and configured and CSD had been run to generate the new standby database then we ran Dbvisit Standby a few times (log ship and apply), to ensure it was up to date with the primary, before making sure nothing was happening on source and securing the current_scn (which was easy in our case as it was a test system and no one else was on this).

We then "locked" the standby database (a feature available in the Dbvisit Standby product) to recover only to this SCN using the method/functionality outlined in this blog post:

http://blog.dbvisit.com/dbvisit-standby-part-1-recover-to-specific-scn-or-timestamp/

Of course you don't have to do this - and could perform manual recovery, but this is a nice feature of Dbvisit Standby we wanted to make use of here.

The next step was then to activate the fresh standby database using Dbvisit Standby. And after this we created a new tnsnames entry on both source and target to point to this freshly activated standby database (which was now an open/read-write database in its own right).

Following on from that we set about creating a new Replicate configuration from scratch. See the example here:

https://dbvisit.atlassian.net/wiki/display/ugd7/Step+by+Step+Configuration+Example

The key in working through that process was to use the RESETLOGS option for the prepare type. Then simply follow the usual Dbvisit Replicate configuration steps outlined through to completion, and all should be well.

Mike Donovan March 23, 2015 11:27