Oracle triggers agent
Introduction
The Oracle Triggers agent provides Change Data Capture through a robust auditing structure based on database triggers. This approach offers a reliable way to track changes across your Oracle database tables without requiring complex transaction log configurations.
Key Features
-
Trigger-based auditing system
-
Atomic sequence tracking for row-level changes
-
Minimal setup requirements
-
Compatible with older Oracle versions, any edition
-
Built-in JDBC driver connection
How It Works
The Triggers agent tracks record changes using:
-
Database triggers that monitor INSERT, UPDATE, and DELETE operations after commit, in transaction with in-memory buffered rows;
-
A dedicated CDC table within the GLUESYNC schema (user-configurable) that stores:
-
Unique row identifiers for changed records;
-
CRUD action types;
-
Minimal metadata thanks to the change tracking technique.
-
Tecnology under the hood
The triggers business logic that powers the Oracle Triggers agent is based on a per-transaction logic, and only tracks changed row IDs, storing data on a table called CDC where all changed row IDs are stored and their data type is maintained unaltered.
The CDC table is populated by the triggers and managed by the agent.
Supported Versions
The Oracle Triggers agent works on:
-
Any Oracle Database version from 11.2g onwards;
-
Both single-tenant and multi-tenant architectures;
-
Oracle RAC is also supported in this agent;
-
No specific database edition requirements.
Connecting with tnsnames
Oracle environments that rely on tnsnames.ora can integrate with Gluesync using two approaches:
Custom connection string
During the agent configuration wizard, expand the //Advanced// section and provide your full JDBC string. Build it starting from your existing TNS entry, for example:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=your_host)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=your_service_name)))
Choose this method when you must reuse a tnsnames.ora definition or require complex Oracle descriptors.
Connection via SCAN (Single Client Access Name)
You can also connect through Oracle SCAN. A DNS entry (the SCAN) resolves to multiple SCAN listeners running on the cluster, and each listener forwards connections to the least busy database instance that exposes the target service.
When SCAN listeners are configured correctly you do not need the tnsnames.ora file. Populate the standard Gluesync fields instead:
-
Host: SCAN DNS (for example,
//rac-cluster-scan.example.com) -
Port: Listener port (default
1521) -
Service name: Desired service reached via
SERVICE_NAME
This option requires SCAN listeners to be active and properly configured. Review Oracle’s Real Application Clusters documentation for details:
Platform supported features
| Feature | Support | Notes |
|---|---|---|
Target role |
✅ |
Writes to Oracle via the bundled JDBC driver (any edition). |
Source role |
✅ |
Captures changes using trigger-based auditing and the GLUESYNC.CDC table. |
Snapshots |
✅ |
Full snapshots can be run prior to CDC to seed tables. |
CDC |
✅ |
Triggers populate the CDC table with committed INSERT/UPDATE/DELETE events. |
CDC type |
Database triggers + CDC table |
Per-transaction logic queues row IDs and CRUD metadata. |
User defined data types |
✅ |
Supports user defined data types. |
Bulk load |
❌ |
This agent does not currently support bulk loading. |
Source persisted internal cache |
N/A |
CDC table plus Core Hub metadata track state; no extra cache needed. |
Target persisted internal cache |
N/A |
Writes go directly to Oracle via JDBC. |
Driver / connector |
Built-in JDBC driver |
Gluesync embeds the vendor driver with Oracle-specific settings. |
Chains |
N/A |
Not yet supported. |
Truncate operation support (reading) |
❌ |
This agent does not currently support reading incremental changes from Oracle. |
Truncate operation support (writing) |
✅ |
Supports Core Hub “TRUNCATE before snapshot” option for targets. |