Page Comparison

...

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 MINE process, which runs against the source database and "mines" the redo logs for changed data.
2. Apply APPLY process, which runs against the target database and applies SQL to the target database.
3. Fetcher FETCHER process (optional), which runs against the source database and send archive and online redo logs to mineMINE.

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 MINE process
2. Apply APPLY process

Dbvisit Replicate 3 tier architecture

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

1. Fetcher FETCHER process
2. Mine MINE process
3. Apply APPLY process

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

The direct impact of the fetcher 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.

...

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 FETCHER process is an optional process and is not shown in above diagram.

...

All the above processes can be on the same server, or on different servers. The Fetcher FETCHER process is an optional process and is not shown in above diagram.
Multiple MineMINE, Apply APPLY and Fetcher 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.