Back to Basics With Dbvisit Replicate Part IV

Open

We have now reached Step 3 of the Setup Wizard. PreSteps, Step 1 and Step 2  were already covered. In Step 3 we will start to choose which schemas and table we wish to replicate. Step 3 - Replicated tables The third step is to choose the schemas and tables to be replicated. If the databases are reachable, the tables are checked for existence, datatype support, etc., schemas are queried for tables. Note that all messages are merely hints/warnings and may be ignored if issues are rectified before the scripts are actually executed. Following tables are defined for replication pairs:

You can use a space or a comma to separate entries or as you may have learned in the scripting blog you can use a pointer to a text file. You are given the option to add multiple schemas or multiple tables.  And of course you are given a second chance if you want to add more. Please enter list of all individual tables to be replicated. Enter schema name(s) only to replicate all tables in that schema. Use comma or space to delimit the entries.

PL/SQL objects are not replicated by default.  You will have to specify the schemas for those PL/SQL objects.   Dbvisit does not replicate triggers.  Dbvisit will replicate the DDL for    alter/drop procedures/functions and packages. Dbvisit will NOT replicate the initial creation of these PL/SQL objects. To replicate changes of PL/SQL objects in schema(s), please enter the schemas to be replicated. Note that specifying any entry will cause additional privileges to be granted to dbvrep. Enter through a comma or space-delimited list.

Next there is an options section that contains some powerful features.  The first  question will ask if you want to exclude any tables from the schema level replication.  For example you may want to replicate 99 out of 100 tables for schema SCOTT.  Rather than list all 99 tables you can just enter SCOTT as seen above.  Then here you would save SCOTT.SALGRADE and that table would NOT be replicated.  Following that exceptions question is a question asking if you would like to rename the schemas for example you may be going from SCOTT schema to SCOTT_TEST schema on the target. Filtering comes next.  By default all DML changes will be replicated from the source to the target.  However there are times that you may only want certain rows from some tables sent over to the target.  This is where filtering comes in.  You can specify if you want certain DML to be filtered and if so by what column.  This is great if you have multiple reporting databases and only want a subset of data in each.  And lastly in that section we have the Audit feature.  This question will only appear if you have listed tables, it will NOT work at the schema level. The audit feature will turn every DML statement into an insert.  It will also add some metadata information if you so desire.  This is a very powerful tool that will typically allow you to load into a staging table and then let an ETL (Extract, Transform and Load) Utility take it from there and place the data into a data warehouse.  I will discuss the Audit feature in greater detail in a future blog. You can also specify some advanced options:

After these advanced options we have the summary with the new information added.  Once again it gives you a chance to edit if you want to change anything after your review. Following tables are defined for replication pairs:

Step 3 is now done and we will move on to the final step, Step 4 in our next blog, which is about configuring the replication processes for each replication.