Standby Database

A standby database can be used to create the target database to ensure that the data is same as the source database before the replication starts. Using standby database for data instantiation is a wise choice when almost every schema of the source database is to be replicated. Once the standby database is ready, select a particular SCN to start replication from and recover the standby database up to that SCN. You can then run the setup wizard of Dbvisit Replicate to configure the replication.

Example

Following example illustrates the method of using standby database as target. The standby database can be created using RMAN or by using Dbvisit Standby. This example explains the method step by step after standby database is created using following environment.

Server/Database	Name
Source database	reptest1
Source server	dbvldemo101 (Linux)
Standby/Target database	reptest2
Target server	dbvldemo102(Linux)
TNS alias for source database	reptest1
TNS alias for target database	reptest2

1. Create the standby database using RMAN or by using Dbvisit Standby

2. Confirm that no transactions are pending on the source database and all the tables to be replicated are idle, get the current SCN.

SQL>select current_scn from v$database;
CURRENT_SCN
-----------
1094745

You can either lock the table or ensure in other ways (like application downtime) that no transactions are pending on the tables as of the SCN because pending and non-committed transactions would be lost.

3. Recover standby database up to that SCN and then activate it.

SQL> recover standby database until change 1094745
ORA-00279: change 1094505 generated at 06/21/2013 17:37:11 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/oraarch/reptest2/1_38_818678256.dbf
ORA-00280: change 1094505 for thread 1 is in sequence #38
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/u01/app/oracle/oraarch/reptest2/o1_mf_1_38_8w7spsss_.arc
Log applied.
Media recovery complete.
SQL> alter database activate standby database;
Database altered.
SQL> alter database open;
Database altered.

4. Now, you can configure Dbvisit Replicate by running setup wizard normally on the source server. Select 'resetlogs' as data instantiation method in step 2 of setup wizard.

Step 2 - Replication pairs
========================================
The second step is to set source and targets for each replication pair. This is usually just choosing the first database as
source and the second one as target, but many more configurations are possible.
Let's configure the replication pair, selecting source and target.
Following databases are described:
1: reptest1 (Oracle) 
2: reptest2 (Oracle) 
Select source database: [1] 
Select target database: [2] 
Will be DDL replication enabled? (If YES, the script will grant more privileges to the Dbvisit Replicate users and enable database-wide supplemental logging): [yes] 
Use fetcher to offload the mining to a different server? (yes/no) [no] 
Would you like to encrypt the data across the network (yes or no) [no]
Would you like to compress the data across the network (yes or no) [no]
How long do you want to set the network timeouts. Recommended range between 60-300 seconds [60]
Lock and copy the data initially one-by-one or at a single SCN? (one-by-one/single-scn/ddl-only/resetlogs) [single-scn] resetlogs 
What data copy script to create? (dp_networklink/dp_exp/exp/ddl_file/ddl_run/none) [none]
Following replication pairs are now configured:
1: reptest1 (Oracle) ==> reptest2 (Oracle), DDL: yes, fetcher: no, process suffix: (no suffix), 
compression: no, encryption: no, network timeout: 60, prepare type: resetlogs, data load: none
Enter number of replication pair to modify it, or "add", or "done": [done]

Make sure to select NONE as the data load option in response to the "What data copy script to create" question, as your baseline data set is already on the target side within the activated standby database - and nothing further needs be transferred across for instantiation.

5. Run the reptest1-all.sh script followed by starting MINE and APPLY processes.

This will require the MINE process to go back in time to start mining from the SCN starting point. You will need archivelogs available from the SCN starting point for MINE to process all the changes.

When target database creation takes a long time the MINE process has to do a lot of catchup work before it can actually start to replicate the current changes.