Products > Realtime Data Integration > Change Data Capture

Log-Based Capture and Trigger-Based Capture

HVR has two methods for Change Data Capture: log-based capture and trigger-based capture. Log-based capture means that HVR watches the DBMS logging system for changes. The implementation is completely unobtrusive because HVR only needs read-permission to the redo and archive files and avoids accessing the DBMS locking system. If HVR falls a long way behind (perhaps it was disabled for some reason) then it will go back to reading from the redo archive files before reading right up to current point in the redo files. This architecture guarantees low latency and a zero overhead on the production system.

Changes Applied as SQL Statements

Once extracted from the DBMS logging system the physical records are converted into logical changes and sent over the network. They are applied as SQL statements to each target database, which could be Oracle, SQL Server or Ingres.

But sometimes trigger-based capture can suit a replication problem better than log-based. The following table compares the change data capture mechanisms.

	Log-based Capture	Trigger-based Capture
Mechanism	Normally HVR reads from on-line logging. For Oracle this means redo log files and for Ingres this means the Ingres log file. If HVR falls behind it jumps back to archived logging. This means the archive-redo files for Oracle and journal files for Ingres. HVR only uses read access to DBMS files; it avoids the database locking system. Physical logging records are converted to logical changes before being sent over the network.	Each replicated table has a pair of HVR capture tables. Every change is written into one of these capture tables by a HVR database trigger. The replication job constantly ‘toggles’ these triggers so that they write into a different pair of capture tables. This toggling avoids contention with locks held by end-user and also protects transaction atomicity. The replication job then processes all changes queued in the capture tables, exploiting the bundling to maximize throughput. Finally the job truncates the capture queue tables and starts a new toggle.
Special Replication Properties	Only plain capture for specified tables, but special replication properties are still available on integrate side.	Various capture-side properties available including; Collision handling for bi-directional replication. Row capture-restrictions and horizontal partitioning. Injection of business logic into capture triggers.
Overhead	Zero.	Approximately 3% for interactive systems, increasing to 15% for batch work.
Replication Latency	Less than 1 second.	About 1 minute.