Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Data instantiation can be done by creating a target database using the RMAN restore and recover command.This method is more suitable for data instantiation when almost every schema of the source database is to be replicated, and the source and target database databases are both Oracle. Once the target instance is ready, select a particular SCN to start replication from and restore and recover the target database up to that SCN. You can then run the setup wizard of Dbvisit Replicate to configure replication. 

...

Following is a step-by-step illustrative example of using RMAN restore and recover command for data instantiation before configuring Dbvisit Replicate. Following The following environment is used in this example.

...

3. Backup archivelogs, these backups are used to restore target database up to the SCN 1007088SCN 1009189.

No Format
bgColorCCC
RMAN> backup archivelog all;
Starting backup at 01/07/2013:14:02:41
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=41 device type=DISK
channel ORA_DISK_1: starting compressed archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=2 RECID=1 STAMP=819637105
input archived log thread=1 sequence=3 RECID=2 STAMP=819637137
input archived log thread=1 sequence=4 RECID=3 STAMP=819640946
input archived log thread=1 sequence=5 RECID=4 STAMP=819640961
channel ORA_DISK_1: starting piece 1 at 01/07/2013:14:02:42
channel ORA_DISK_1: finished piece 1 at 01/07/2013:14:02:45
piece handle=/backups/rman/REPTEST1_05odlek2_1_1 tag=TAG20130701T140242 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 01/07/2013:14:02:45

...

No Format
bgColorCCC
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 (NETWORK_QUALITY) - Please specify your network type (LAN or WAN). Autoconfigures timeouts, use of compression etc. [LAN] 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: LAN60, prepare type:
resetlogs, data load: none
Enter number of replication pair to modify it, or "add", or "done": [done]

...

Note
  • This will require the Mine 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 MINE to process all the changes.
  • When target database creation takes a long time the Mine MINE process has to do a lot of catchup work before it can actually start to replicate the current changes.

...