Golden Gate Configuration Step By Step

Setting Up Oracle GoldenGate Without Losing Your Mind

GoldenGate is the thing you use when you need data moving between databases in near real-time. It works. Most of the time. The configuration process isn't difficult if you know what you're doing, but there are enough moving parts that things will break if you skip steps. I've been dealing with this for years and I still double-check my parameter files. The first thing you need to decide is your architecture. Are you doing extract to collector to extract, or manager to extract directly to target? The simple topology is easier to debug. The complex one gives you more control but introduces failure points that will bite you at 3 AM.

Golden Gate Configuration Step By Step

Start with the Manager process on both source and target. This is the control plane. You create a mgr.prm file with basic parameters like PORT and DYNAMICPORTLIST, then start it. If you skip this step everything after fails. I've seen people rush through this and spend four hours debugging downstream issues that traced back to a wrong port number in the manager config. Next enable minimal supplemental logging on the source database. This is non-negotiable. Without it GoldenGate can't capture row-level changes properly. The command is straightforward: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA. Then you configure the extract process. You'll define the extract group, point to the trail location, and specify the tables or schemas you want to replicate. The parameter file looks something like this:

EXTRACT ext1
USERID ghadmin, PASSWORD <encrypted>
EXTTRAIL ./dirdat/et
TABLE schema.table_name; After that comes the replicat on the target side. You map source tables to target tables and handle any column mismatches here. This is where most configuration errors surface. If your source and target schemas don't match exactly, you need to use MAP statements with column lists. The checkpoint table is another detail people forget. Create a checkpoint table for each extract and replicat. Without it, recovery after a crash means starting from scratch on the log position, which can mean significant data replay and extended downtime.

Things That Actually Go Wrong

I ran into a problem once where the extract was applying changes fine but the replicat kept abending with ORA-01403 (no data found). The issue was that a DELETE operation on the source was hitting a target row that had already been deleted by a concurrent update. The workaround was setting REPFAIL on the replicat parameter and adding HANDLECONFLICTS with the NOPARAMS option. This didn't fix the underlying race condition but it stopped the constant abends. Another thing nobody warns you about: timezone handling. If your source and target databases are in different timezones, GoldenGate captures timestamps in the source database's local timezone. This causes ordering issues in the trail files. We solved this by converting timestamps to UTC in the extract process using a COLMapper statement. Took about an hour to get right. Common pitfalls: forgetting to start the collector in a multi-hop topology, mismatched character sets between source and target, and not accounting for foreign key constraints on the target that don't exist on the source. All three will cause replication failures that look nothing like the actual problem.

Performance Reality Check

GoldenGate adds overhead. Extract processes consume CPU and I/O on the source database. Replicats consume resources on the target. For high-volume OLTP systems, you're looking at roughly 5-15% additional load during peak replication windows. If your source database is already saturated, this can be the difference between a smooth deployment and a production incident. The big bottleneck is usually the network link between sites. Trail file compression helps, but if you're replicating hundreds of gigabytes per day over a congested WAN, expect lag to creep up during business hours. We saw a setup where the replicat lag climbed to 45 minutes during peak loads because the target database had insufficient IO capacity. Adding SSD storage and increasing parallel apply processes dropped lag to under 2 minutes. There's also the licensing question. GoldenGate licenses are per-socket on the source and target, plus additional charges for certain database platforms. Make sure you understand what you're paying for before you configure anything.

Alternative to Consider

If GoldenGate feels heavyweight for your use case, consider whether CDC solutions built into the database itself might suffice. PostgreSQL has logical replication. SQL Server has native CDC. Oracle Data Guard handles physical standby scenarios. These are simpler to configure but offer less flexibility for cross-platform replication. GoldenGate's strength is when you need heterogeneous database migration or complex filtering and transformation logic between different database platforms. For pure Oracle-to-Oracle replication on the same platform, Oracle's own built-in tools may be sufficient and cheaper. GoldenGate really earns its keep when you're moving data between Oracle and non-Oracle systems, or when you need sub-second latency with minimal impact on the source database.