Configure Dbvisit Replicate : Basic

Although Dbvisit Replicate tries to be as simple to use as possible, replication is nevertheless a complicated process. It is thus recommended to allocate enough time and testing resources to familiarize with Dbvisit Replicate before using it for mission critical tasks.

We therefore recommend a simple step-by-step approach to Dbvisit Replicate. 
An example step-by-step approach may be:

1. Ensure the target database exists and has the users created you want to replicate to. See 3 part blog series http://blog.dbvisit.com/back-to-basics-with-dbvisit-replicate-part-i/
2. Start small and simple: set up replication of just a handful of tables, Oracle-to-Oracle, on simple test environment, planning no conflicts. Use SCOTT or other familiar schema.
3. Learn how to set up this simple replication using the setup wizard and how to rerun the setup scripts if needed. The setup scripts are created by the setup wizard. Rerunning the scripts will drop and recreate the replication configuration.
4. Learn how to use the command console, monitor replication progress. Monitor log files on disk, check disk space utilization.
5. Learn how to setup automatic monitoring – email notifications, SNMP (if desired), direct SQL queries (if desired). Integrate with your existing monitoring tools. Setup your monitoring tools to check that processes are running or to check errors in log files.
6. Make your setup more complicated, heading towards your desired configuration – add more tables, setup and test conflict handling, change target database (MySQL/MS SQL), test DDL replication, 2-way replication, RAC.
7. Setup your desired configuration on a test environment and test it thoroughly.
8. Setup your desired configuration on your production environment.

Plan enough time to analyze impacts of replication on your application. These impacts apply to any replication technology and are not specific to Dbvisit Replicate;

1. Replication is not disaster recovery technology and cannot replace proper backups.
2. Data is replicated in transaction-consistent manner, but lags behind the source (although this is minimal with Dbvisit Replicate).
3. If the data is changed at target database by other means than replication, conflicts can occur. This is more prominent in case of two-way replication.
4. The data is replicated using standard SQL and thus triggers must be taken into consideration. See special chapters how to set what triggers to fire.

Example environments:

1. Using a single virtual Linux machine as a test system is a good recommended approach. Oracle can be the source database and MySQL can be the target database. Please see step-by-step instructions in section Oracle → MySQL replication setup example on how to configure this environment.