In Part I of this series we discussed the install process and some pre-requisites for installing Dbvisit Replicate. In Part II we talked about Step 1 of the setup wizard: describing databases. One thing I mentioned was the common pitfall of not having TNSNAMES.oraset up correctly. Today, we are going to discuss Part III which is Step 2 of the install process: “Replication Pairs”.
After hitting enter in Step 1 it will bring you to, you guessed it, Step 2. The first question will ask you which database you want to be the source and which one you pick for the target. It is very typical to set up the SOURCE database first and the TARGET database second. However, the process is flexible and it does not have to be this way.
Step 2 - Replication pairs ======================================== The second step is to set source and targets for each replication pair. Let's configure the replication pair, selecting source and target. Following databases are described: 1: SDB11 (Oracle) 2: TDB11 (Oracle) Select source database:  Select target database: 
The next series of questions are pretty simple and straightforward.
Do you want to replicate DDL? One note on this: TRUNCATE TABLE replication is on by default and will be replicated even if you hit no. You will have to set a parameter to turn this off. We know we're talking about a DDL and not a DML, but we also know that people treat it as a DML.The key takeaway is you can always turn it off.
Fetcher is an optional process that allows you to move the MINE process off to another machine. The fetcher ships the redo logs in real-time over to another machine. This a powerful feature that probably deserves a blog in its own right, shout out to our team working hard behind the scenes :)
Encryption and compression are the next two questions and they are self-explanatory. Do you want to encrypt the data as it goes across the network? Alternatively, do you want to compress the data as it goes across the network? Each feature will depend on your network bandwidth and security requirements. You may see increased CPU utilization when turning these options on. The last question is regarding network timeouts. This is how long the MINE process will wait for a response from the other side. If you have a flaky network, the number should be higher.
The next series of questions are about the starting point for MINE. I went over the options about how to pick an initial starting point in an earlier blog, have a look at When No Locks Are A Good Thing for more information.
Lock and copy the data initially one-by-one or at a single SCN? one-by-one : Lock tables one by one and capture SCN single-scn : One SCN for all tables ddl-only : Only DDL script for target objects resetlogs : Use SCN from last resetlogs operation (standby activation, rman incomplete recovery) no-lock : Do not lock tables. Captures previous SCN of oldest active transaction. Requires pre-requisite running of pre-all.sh script (one-by-one/single-scn/ddl-only/resetlogs/no-lock) [single-scn]
The next part deals with instantiation. There are a few choices here. dp_networklink is, as the name says, a Data Pump Link. No export datafile is created and the data is streamed from the source to the target using the Oracle Data Pump. Dbvisit will create the script (APPLY.sh) that has all of the relevant info in it. You can, of course, modify this script as you see fit. You will also have to create the network link. Dp_exp is similar as it is the Data Pump with a datafile. The choice of exp is the ‘old school’ method of export/import. Once again, Dbvisit will create the APPLY.sh script for you to examine and then run.
DDL_file will create a DDL script (APPLY.sql) but will not populate that table with data. In fact, we suggest that you look at this script before running it and make sure everything in there is as you want it. Load is a feature specific to Dbvisit Replicate. When you choose the load method, Dbvisit will go ahead and grab all of the data from those tables (as of the SCN that MINE will start at) and replicate it. Think of it doing a select * from table_name to grab that data. It can be slower than the other options but the neat thing is that you don’t have to do anything, it automatically runs in the background, when the MINE/APPLY processes start. If you choose this option, it will ask you if you want to keep the target tables there or recreate them when the load starts. Although it is not super fast, it is a great and easy way to copy the whole table over to the target database without having to run anything else.
Finally, you see a review of the replication pair with all of the options that you have chosen and with a chance to edit it if you would like to.
Following replication pairs are now configured: 1: SDB11 (Oracle) ==> TDB11 (Oracle), DDL: yes, fetcher: no, process suffix: (no suffix), compression: no, encryption: no, network timeout: 60, prepare type: single-scn, data load: load_create Enter number of replication pair to modify it, or "add", or "done": [done]
I know you are keen to know when you can enter table and schema information in! You will be happy to know that it is covered in the next blog in this series :) In the meantime, have a look at our User Guides for more information.