Dbvisit Replicate Architecture

Dbvisit Replicate 2- or 3-tier architecture

The Dbvisit Replicate architecture is a very flexible architecture and consists of a 2- or 3-tier architecture. The architecture components are as follows:

1. MINE process, which runs against the source database and "mines" the redo logs for changed data.
2. APPLY process, which runs against the target database and applies SQL to the target database.
3. FETCHER process (optional), which runs against the source database and send archive and online redo logs to MINE.

Please see Solutions Diagrams for different flexible configurations and solutions.

Dbvisit Replicate 2 tier architecture

The 2-tier architecture is the default architecture and consists of the following 2 processes:

1. MINE process
2. APPLY process

Dbvisit Replicate 3 tier architecture

The optional FETCHER process can be used to offload the MINE process to another server (downstream MINE). The processes in the 3-tier architecture are:

1. FETCHER process
2. MINE process
3. APPLY process

All 3 processes can be run on different operating systems and are platform independent.

The direct impact of the FETCHER process on the source database is negligible, as it just stores small amount of state data and simple queries regarding current state of archive and online redo logs are issued against this database.

One-way architecture

Dbvisit Replicate one-way has been designed using a simple architecture to enable speed, performance and efficiency. Dbvisit Replicate does not use intermediate queues or messaging to facilitate the replication.

For information on how to setup 1-way replication, please see here

All the above processes can be on the same server, or on different servers. Dbvisit Replicate uses fast Oracle Call Interface (OCI) for direct connections to the database. The FETCHER process is an optional process and is not shown in above diagram.

Two-way architecture

The Dbvisit Replicate two-way architecture is an essence a duplication of the one-way architecture. Each replication from a source to target is a one-way process, but because the replication is going both ways, it is a two x one-way process with the source and target reversed for each process (an inner one-way loop and an one-way outer loop).

Dbvisit Replicate ensures that data that is mined on one database and then replicated to the target database, is not mined again on the target database and replicated back as this would cause an infinite feedback loop.
Dbvisit Replicate does not use intermediate queues or messaging to facilitate the replication.

For information on how to setup 2-way replication, please see Active - Active (2-way replication)

All the above processes can be on the same server, or on different servers. The FETCHER process is an optional process and is not shown in above diagram.
Multiple MINE, APPLY and FETCHER processes are possible for the same replication, enabling simple to complex replication topologies.

Optimistic commit

Dbvisit Replicate (both MINE and APPLY) does not wait for the commit to start replicating. This ensures there is minimal lag in large transactions and there is no need to hold inflight transactions in queues or memory. 

This is similar to how Oracle implements optimistic commit. Oracle also does not wait for the commit to be issued before writing the data to the database files. 

When there is a rollback, then Dbvisit Replicate has to do more work in order to undo the transactions that have been applied, and this is similar to how Oracle works. 

Dbvisit Replicate adheres to autonomous transactions. Transactions that are not committed are not visible to other transactions until they have been committed. So if a large transaction has been replicated, the data is there on the target database but it will not be visible to the outside world until the transaction has been committed on the source database.