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:
- Mine process, which runs against the source database and "mines" the redo logs for changed data.
- Apply process, which runs against the target database and applies SQL to the target database.
- Fetcher process (optional), which runs against the source database and send archive and online redo logs to mine.
Dbvisit Replicate 2 tier architecture
The 2-tier architecture is the default architecture and consists of the following 2 processes:
- Mine process
- Apply process
Dbvisit Replicate 3 tier architecture
The 3-tier architecture is used to offload the mine process to another server (downstream mine). The processes in the 3-tier architecture are:
...
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.
...
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).
...
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.
...