Skip to main content

How to Enable Oracle Golden Gate Trail File Encryption (Bidirectional Setup)


Introduction: Why Your GoldenGate Trails Need Encryption

If you're running Oracle GoldenGate in production, your trail files are essentially the heartbeat of your data replication. They contain captured transactions, metadata, and complete before/after images of your data changes. Without encryption, these files are vulnerable—whether sitting on shared storage, captured in backups, or transmitted across networks.

In this comprehensive guide, I'll walk you through implementing AES256 encryption for Oracle GoldenGate trail files in a bidirectional replication setup. We'll cover both local trail storage encryption and network transmission security between two hosts.

What You'll Achieve

By the end of this tutorial, you'll have:

  • Encrypted trail files written to disk (data at rest protection)
  • Encrypted network transmission between source and target systems
  • Bidirectional encryption working seamlessly in both directions
  • Minimal performance impact while maintaining compliance readiness

The Business Case for Trail Encryption

Before diving into the technical steps, let's understand what encryption delivers:

Confidentiality: Raw row data, including sensitive IDs, timestamps, and business flags remain protected

Compliance Ready: Supports requirements from GDPR, SOX, PCI-DSS, and HIPAA frameworks

Defense in Depth: Adds another security layer beyond OS permissions and network segmentation

Performance Friendly: AES256 is optimized and introduces minimal overhead for most workloads

Our Test Environment

For this guide, we're using:

  • Two hosts: test-03 and test-06
  • GoldenGate Version: 21c (installed at /opt/app/ogg21c)
  • Schema: test_schema with table1 and table2
  • Replication: Bidirectional (test-03 ↔ test-06)

Prerequisites: What You Need Before Starting

Make sure you have these ready:

✅ GoldenGate 21c installed and functional
✅ Wallet directory created at /opt/app/ogg21c/dirwlt
✅ Working USERIDALIAS entries in credential store
✅ Time synchronization (NTP) active on both hosts
✅ Backup of existing wallet directory
✅ SSH access between hosts for secure file transfer
✅ Existing replication working without encryption (we'll add encryption to running processes)

Pro Tip: Take a performance baseline before making changes so you can measure any impact.

Phase 1: Setting Up Encryption (test-03 → test-06)

Step 1: Create the Wallet and Master Key (on test-03)

The wallet stores your encryption keys securely. Let's create it on the source system.

Connect to GGSCI on test-03:

$ cd /opt/app/ogg21c
$ ./ggsci

Create and configure the wallet:

GGSCI> create wallet
GGSCI> open wallet
GGSCI> add masterkey
GGSCI> info masterkey

You should see output confirming:

Masterkey Name: OGG_DEFAULT_MASTERKEY
Version 1 Status Current

Verify the masterkey version:

GGSCI> info masterkey version 1

Important: Check your GLOBALS file and ensure it contains:

MASTERKEYNAME OGG_DEFAULT_MASTERKEY

Remove any accidental numeric entries like MASTERKEYNAME 1 if present.

Step 2: Securely Transfer the Wallet to test-06

The wallet file (cwallet.sso) must exist on both hosts for bidirectional replication. Transfer it securely:

scp /opt/app/ogg21c/dirwlt/cwallet.sso ogguser@test-06:/opt/app/ogg21c/dirwlt/

Set proper permissions on test-06:

ssh ogguser@test-06 "chmod 600 /opt/app/ogg21c/dirwlt/cwallet.sso && chown ogguser:ogggrp /opt/app/ogg21c/dirwlt/cwallet.sso"

Security Note: Never rename this file. GoldenGate expects exactly cwallet.sso.

Step 3: Stop Replication Processes

Stop processes in the proper order to prevent data loss:

On test-03 (source):

GGSCI> stop EXT_CAPTURE
GGSCI> stop PMP_FORWARD

On test-06 (target):

GGSCI> stop REP_APPLY

Replace these names with your actual Extract, Pump, and Replicat process names.

Step 4: Configure Extract for Trail Encryption (test-03)

Edit your Extract parameter file and add ENCRYPTTRAIL AES256 before the EXTTRAIL line.

Example Extract parameter (EXT_CAPTURE):

EXTRACT EXT_CAPTURE
SETENV (TNS_ADMIN="/opt/app/ogg21c/instantclient")
SETENV (NLS_LANG=AMERICAN_AMERICA.AL32UTF8)

USERIDALIAS gg_source DOMAIN OracleGoldenGate
ENCRYPTTRAIL AES256
EXTTRAIL /oggdata/trails/ta

WARNLONGTRANS 5m, CHECKINTERVAL 300
CHECKPOINTSECS 1

LOGALLSUPCOLS
UPDATERECORDFORMAT COMPACT
REPORTCOUNT EVERY 15 MINUTES, RATE

TABLE test_schema.table1;
TABLE test_schema.table2;

What This Does: ENCRYPTTRAIL AES256 encrypts trail files written to local disk.

Step 5: Configure Pump for Network Encryption (test-03)

Edit your Pump parameter file and add ENCRYPT AES256 to the RMTHOST line.

Example Pump parameter (PMP_FORWARD):

EXTRACT PMP_FORWARD
RMTHOST test-06, MGRPORT 7709, TCPBUFSIZE 1000000, TCPFLUSHBYTES 1000000, ENCRYPT AES256
RMTTRAIL /oggdata/trails/tb
PASSTHRU

REPORTROLLOVER AT 00:00
REPORTCOUNT EVERY 15 MINUTES, RATE

TABLE test_schema.table1;
TABLE test_schema.table2;

What This Does: ENCRYPT AES256 encrypts data transmitted over the network to the remote host.

Key Difference to Remember:

  • ENCRYPTTRAIL = Disk encryption (data at rest)
  • ENCRYPT AES256 = Network encryption (data in transit)

Step 6: Configure Replicat for Decryption (test-06)

Edit your Replicat parameter file on test-06 and add DECRYPTTRAIL near the top.

Example Replicat parameter (REP_APPLY):

REPLICAT REP_APPLY
SETENV (TNS_ADMIN="/opt/app/ogg21c/instantclient")

DECRYPTTRAIL
USERIDALIAS gg_target

REPORTROLLOVER AT 00:00
REPORTCOUNT EVERY 15 MINUTES, RATE

MAP test_schema.table1, TARGET test_schema.table1;
MAP test_schema.table2, TARGET test_schema.table2;

What This Does: DECRYPTTRAIL tells Replicat to decrypt incoming trail data.

Step 7: Start Processes and Validate

Start processes in the correct order:

GGSCI> start EXT_CAPTURE
GGSCI> start PMP_FORWARD
GGSCI> start REP_APPLY
GGSCI> info all

Check process status—all should show RUNNING.

Step 8: Verify Encryption is Active

Check the report logs for each process. Look for these key indicators:

In Extract report:

INFO OGG-25209 Retrieved master encryption key OGG_DEFAULT_MASTERKEY version 1 with state Active.
INFO OGG-25851 Using encryption profile 'LocalWallet'.

In Replicat report:

INFO OGG-05520 Input trail file encryption: AES256.

These messages confirm encryption is working correctly.

Phase 2: Enabling Reverse Direction (test-06 → test-03)

Now that encryption works in one direction, let's enable it for the reverse flow.

Step 9: Configure Reverse Extract (test-06)

Stop the reverse Extract on test-06:

GGSCI> stop EXT_REVERSE

Add ENCRYPTTRAIL AES256 to the Extract parameter file on test-06 (same pattern as Step 4).

Step 10: Configure Reverse Pump (test-06)

Stop the reverse Pump on test-06:

GGSCI> stop PMP_REVERSE

Add ENCRYPT AES256 to the RMTHOST line pointing to test-03 (same pattern as Step 5).

Step 11: Configure Reverse Replicat (test-03)

Stop the reverse Replicat on test-03:

GGSCI> stop REP_REVERSE

Add DECRYPTTRAIL to the Replicat parameter file on test-03 (same pattern as Step 6).

Step 12: Start Reverse Processes

GGSCI> start EXT_REVERSE
GGSCI> start PMP_REVERSE
GGSCI> start REP_REVERSE

Step 13: Validate Reverse Direction

Check report logs for the same encryption indicators mentioned in Step 8.

Good news: You don't need to recreate the wallet—cwallet.sso is already present on both hosts!

Verification Checklist

Use this checklist to ensure everything is configured correctly:

Component What to Verify Expected Result
Extract (both hosts) Report shows trail encryption OGG-05520 Input trail file encryption: AES256
Pump (both hosts) RMTHOST includes ENCRYPT Parameter file contains ENCRYPT AES256
Replicat (both hosts) Decrypts successfully OGG-05520 message in report
Master Key Active and consistent OGG_DEFAULT_MASTERKEY version 1 Active
Wallet File Exists with secure permissions ls -l cwallet.sso shows -rw-------
Performance No abnormal lag lag extract and lag replicat remain stable

Troubleshooting Common Issues

Issue: Replicat Abends with Decryption Error

Cause: Missing DECRYPTTRAIL parameter

Solution: Add DECRYPTTRAIL to Replicat parameter file and restart

Issue: "Master Key Not Found" Error

Cause: Wallet file missing or incorrect permissions

Solution:

  • Verify cwallet.sso exists in /opt/app/ogg21c/dirwlt
  • Check permissions: chmod 600 cwallet.sso
  • Verify ownership: chown ogguser:ogggrp cwallet.sso

Issue: Pump Sends Plaintext but Replicat Expects Encrypted Data

Cause: Missing ENCRYPT AES256 on RMTHOST line

Solution: Update Pump parameter file with ENCRYPT AES256 and restart

Best Practices for Production

1. Backup Your Wallet

cp /opt/app/ogg21c/dirwlt/cwallet.sso /backup/cwallet.sso.$(date +%Y%m%d)

2. Automate Log Monitoring

Set up alerts to detect missing encryption signatures in logs. Parse for OGG-05520 messages.

3. Document Your Configuration

Maintain a replication runbook documenting all encryption settings and wallet locations.

4. Plan for Key Rotation

Periodically rotate master keys:

GGSCI> add masterkey

Then perform controlled restarts to activate the new key version.

5. Separate Encrypted and Plaintext Trails

Never mix encrypted and plaintext trail files in the same directory without a clear naming convention.

If You Need to Rollback

Should you need to remove encryption:

  1. Stop all processes
  2. Remove ENCRYPTTRAIL, ENCRYPT AES256, and DECRYPTTRAIL from parameter files
  3. Restart processes
  4. Archive existing encrypted trail files separately—don't append plaintext to encrypted trails

Performance Considerations

In most environments, AES256 encryption introduces minimal overhead:

  • CPU Impact: Typically 2-5% increase
  • Throughput: Negligible impact on replication lag
  • Network: Encryption may slightly reduce effective bandwidth, but modern systems handle this easily

Recommendation: Establish a performance baseline before encryption, then monitor for 48 hours after implementation.

What's Next?

Now that you have encrypted GoldenGate replication running bidirectionally, consider these enhancements:

Security Hardening:

  • Implement MGR port TLS using SECURITY options
  • Enable audit logging for wallet access
  • Set up automated wallet backups

Performance Optimization:

  • Benchmark records/second before and after encryption
  • Fine-tune parallelism settings if needed
  • Monitor long-term trends for capacity planning

You've successfully implemented end-to-end AES256 encryption for Oracle GoldenGate trail files in a bidirectional setup! Your replication data is now protected both at rest (trail files on disk) and in transit (network transmission between hosts).

The three key parameters that made this possible:

  • ENCRYPTTRAIL AES256 – Encrypts local trail files
  • ENCRYPT AES256 – Encrypts network transmission
  • DECRYPTTRAIL – Decrypts incoming trail data

This pattern is repeatable across multiple replication configurations and provides a solid foundation for compliance requirements while maintaining the performance GoldenGate is known for.

Remember: the success of this implementation hinges on proper wallet management, consistent parameter configuration across all components, and validation through GoldenGate's built-in log messages.


Labels:

Comments

Post a Comment

Popular posts from this blog

🚀 Automating Oracle Database Patching with Ansible: A Complete Guide

Oracle database patching has long been the bane of DBAs everywhere. It's a critical task that requires precision, expertise, and often results in extended maintenance windows. What if I told you that you could automate this entire process, reducing both risk and downtime while ensuring consistency across your Oracle estate? 💡 In this comprehensive guide, I'll walk you through a production-ready Ansible playbook that completely automates Oracle patch application using OPatch. Whether you're managing a single Oracle instance or hundreds of databases across your enterprise, this solution will transform your patch management strategy! 🎯 🔥 The Challenge: Why Oracle Patching is Complex Before diving into the solution, let's understand why Oracle patching is so challenging: 🔗 Multiple dependencies : OPatch versions, Oracle Home configurations, running processes ⚠️ Risk of corruption : Incorrect patch application can render databases unusable ⏰ Downtime requirements : Da...
Post a Comment
Read more

Oracle RAC Switchover & Switchback: Step-by-Step Guide

 Ensuring business continuity requires regular Disaster Recovery (DR) drills. This guide covers the Switchover and Switchback process between Primary (DC) and Standby (DR) databases . Pre-checks Before Performing Switchover Before starting the activity, ensure there are no active sessions in the database. If any are found, share the session details with the application team, get their confirmation, and terminate the sessions. Primary Database Name: PRIMARY Standby Database Name: STANDBY  Identify Active Sessions set lines 999 pages 999 col machine for a30 col username for a30 col program for a30 compute sum of count on report break on report select inst_id,username,osuser,machine,program,status,count(1) "count" from gv$session where inst_id=1 and program like 'JDBC%' group by inst_id,username,osuser,machine,program,status order by 1,2; select inst_id,username,osuser,machine,program,status,count(1) "count" from gv$session where inst_id=2 and program lik...
Post a Comment
Read more

Mastering Oracle RAC with SRVCTL Commands

Oracle Real Application Clusters (RAC) provide high availability, scalability, and manageability for databases. One of the most powerful tools for managing RAC databases is srvctl , a command-line utility that allows administrators to control various database services. This blog explores essential srvctl commands to help you efficiently manage Oracle RAC environments. 1. Checking Database Configuration and Status  List all available databases on the host:                  srvctl config database   Check the status of a specific database and its instances:                    srvctl status database -d <database_name>   Retrieve detailed status information about a database, including its instances and states:                    srvctl status database -d <database_name> -v 2. Stopping and Starting Databases   ...
Post a Comment
Read more