Overview
In a GoldenGate 19c environment, one of the EXTRACT processes abended with a TCP/IP error while all other EXTRACT processes were running normally. This post walks through the exact error, the diagnosis process, and how the issue was resolved — along with preventive recommendations to avoid recurrence.
Environment Details
| Component | Detail |
|---|---|
| GoldenGate Version | Oracle GoldenGate 19c (Classic Architecture) |
| Source Database | Oracle 12.1.0.2 |
| Source Server | ogg-source01.example.com |
| Manager Port | 8910 |
| Abended Process | EXTRACT EXTR0001 |
The Problem
During routine monitoring, the GoldenGate process status showed:
EXTRACT ABENDED EXTR0001 CLASSIC
EXTRACT RUNNING EXTR0002 CLASSIC
EXTRACT RUNNING EXTR0003 CLASSIC
EXTRACT RUNNING EXTR0004 CLASSIC
Only EXTR0001 had abended while the other three EXTRACT processes were running normally.
Reading the Report File
The first step was to view the EXTRACT report file from GGSCI:
GGSCI> VIEW REPORT EXTR0001
The relevant portion of the report showed:
2026-04-14 12:38:41 INFO OGG-02820 Positioning to (Thread 1) Sequence 230,424,
RBA 34,213,904, SCN 459.4,134,390,557.
2026-04-14 12:38:41 INFO OGG-02824 Positioned to (Thread 1) Sequence 230,424,
RBA 34,213,904, Apr 14, 2026 10:07:59 AM.
Source Context :
SourceModule : [ggnet.tcprtn]
SourceID : [../gglib/ggnet/tcprtn.c]
SourceMethod : [opt_negotiate(int, errmsg_t &)]
SourceLine : [4739]
2026-04-14 12:38:41 ERROR OGG-01224 TCP/IP error 79 (Connection refused),
endpoint: ogg-target02:8910.
2026-04-14 12:38:41 ERROR OGG-01668 PROCESS ABENDING.
Two important observations from this output:
- The EXTRACT successfully positioned in the source redo logs at the correct SCN — this ruled out any issue with the source database or archived logs.
- The abend happened at
opt_negotiate— the GoldenGate TCP-level handshake between the EXTRACT and the remote Manager.
Error Breakdown
OGG-01224 TCP/IP error 79 (Connection refused)
endpoint: ogg-target02:8910
| Element | Meaning |
|---|---|
| OGG-01224 | GoldenGate TCP/IP communication failure |
| Error 79 | ECONNREFUSED — socket connect actively rejected |
| opt_negotiate | Protocol negotiation phase (post-TCP, pre-trail write) |
| Port 8910 | GoldenGate Manager port on the remote server |
“Connection refused” (errno 79) means the TCP SYN packet reached the remote server but the connection could not be completed — a transient error commonly seen in GoldenGate environments.
Diagnosis Steps
Step 1 — View the EXTRACT Report
The first step was to read the report file and identify the exact error:
GGSCI> VIEW REPORT EXTR0001
The error pointed to OGG-01224 TCP/IP error 79 (Connection refused) at the opt_negotiate stage — meaning the EXTRACT successfully read the source redo logs but failed when attempting to communicate with the remote GoldenGate Manager.
Step 2 — Check EXTRACT Status
GGSCI> INFO EXTRACT EXTR0001, DETAIL
GGSCI> INFO ALL
This confirmed only EXTR0001 had abended while the remaining EXTRACT processes were running normally.
Root Cause
OGG-01224 TCP/IP errors are among the most commonly encountered errors in GoldenGate environments. They are often transient in nature — caused by brief network interruptions, a momentary spike in system load, or a short-lived instability in the GoldenGate Manager communication layer. In many cases, no deep investigation is required; the EXTRACT simply needs to be restarted after waiting a short period for the underlying condition to clear.
The other EXTRACT processes (EXTR0002, EXTR0003, EXTR0004) were unaffected, confirming the issue was isolated and transient.
Resolution
After waiting briefly for the transient condition to clear, the abended EXTRACT was restarted:
GGSCI> START EXTRACT EXTR0001
GGSCI> INFO EXTRACT EXTR0001, DETAIL
The EXTRACT came up immediately and resumed processing without any data loss or position reset.
Post-Recovery Verification
-- Confirm all processes running
GGSCI> INFO ALL
-- Check lag is reducing
GGSCI> LAG EXTRACT EXTR0001
-- Confirm records are flowing
GGSCI> STATS EXTRACT EXTR0001
Key Takeaways
1. OGG-01224 TCP/IP errors are common and often transient.
These errors are frequently seen in GoldenGate environments and do not always indicate a serious underlying problem. A brief network hiccup, momentary system load, or a short instability in the Manager communication layer can trigger this error. In many cases, waiting a short time and restarting the EXTRACT is all that is needed.
2. The opt_negotiate method is the first GoldenGate-level handshake.
After the TCP connection is established, GoldenGate negotiates capabilities via opt_negotiate. A failure at this stage is typically transient and clears on its own after a retry.
3. Multiple EXTRACTs can fail independently.
When one EXTRACT abends while others continue running, the issue is isolated. Do not assume a global outage — check each process individually.
4. Add AUTORESTART to Manager params.
To reduce downtime on similar future occurrences, configure Manager to auto-restart key processes:
-- In mgr.prm
AUTORESTART EXTRACT *, RETRIES 5, WAITMINUTES 2, RESETMINUTES 60
Diagnostic Checklist for OGG-01224 TCP/IP Errors
[ ] View EXTRACT report: GGSCI> VIEW REPORT <extract_name>
[ ] Note the SourceMethod — is it opt_negotiate or during data transfer?
[ ] Check if other EXTRACTs are running (INFO ALL)
[ ] If error is transient: wait briefly, then START EXTRACT <name>
[ ] If error persists: test port reachability (telnet <rmthost> <mgrport>)
[ ] If error persists beyond a retry: escalate for network/firewall checks
[ ] Verify RMTHOST/MGRPORT in EXTRACT param file (VIEW PARAMS <name>)
[ ] Check for encryption mismatch if opt_negotiate consistently fails
[ ] Add AUTORESTART in mgr.prm to handle future transient failures automatically
References
- Oracle GoldenGate Documentation — docs.oracle.com
- MOS Note 966227.1: OGG Troubleshooting TCP/IP Errors In Open Systems (My Oracle Support login required)
About the Author
Syed Anwar Ahmed is an Oracle Apps DBA with extensive production experience managing Oracle RAC, E-Business Suite, and GoldenGate replication environments. He shares practical DBA knowledge from real-world incidents on his blog and is an Oracle ACE Apprentice candidate.
Leave a comment