Capturing Database Changes HVR provides two mechanisms to capture database changes. These mechanisms are log-based capture and trigger-based capture. This table compares their benefits;   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