Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

The loosely coupled architecture of Dbvisit Replicate allows for many flexible configurations and different solutions. 

Here are examples of the different solutions available with Dbvisit Replicate. Click on each diagram to bring up better resolution.

One-way replication solution

This diagram shows the regular Dbvisit Replicate one-way architecture.

Two way replication solution

This diagram shows the regular Dbvisit Replicate 2-way or master to master architecture.

One to many replication solution

This diagram shows the Dbvisit Replicate one to many replication. Note: the target databases can be different databases and different operating systems.

Dedicated server solution

This diagram shows Dbvisit Replicate using a dedicated server running the Mine and Apply processes. 

CDC/Audit BI solution

This diagram show the Dbvisit Replicate CDC/Audit for Real-Time Data Warehousing solution where every change to the source database is recorded as a separate entry into a staging table ready to be loaded into a Data Mart or Data Warehouse.

Data distribution solution

This diagram shows the Dbvisit Replicate solution for replicating data to different remote databases and back. This solution can be used for achieving High Availability (HA) across different regions.

Zero down time migration solution

This diagram show the Dbvisit Replicate solution for providing zero-down-time migrating for migrating databases or platforms from one version to another with little or no downtime.

Partially supported OS solution

This diagram shows the Dbvisit Replicate solution for replicating data from an older Operating System that may supported running the Dbvisit Replicate software. This solution uses NFS to mount the redo and archive logs onto a dedicated Mine server.

Notes:

  1. The NFS shares on the Mine server has to "look" the same as on the Source Site. So the redo and archive locations have to be in the same location on the Mine Server as on the Source Site. This is because the Mine process on the Mine Server connects to the source database to obtain the redo and archive log locations from Oracle and will expect to find the redo and archive logs in the same location on the Mine server. Note that on Linux and Unix this can be achieved with soft links.
  2. The setup wizard is run from the Mine Server. Ensure the Mine server has a tnsnames.ora with a connection string to both the source and target databases.

Offloading reporting solution

This diagram shows Dbvisit Reporting to offload running reports onto a dedicated database. This reporting database is being kept up to date in real-time.

  • No labels