Introduction
While working with Oracle GoldenGate 26ai Microservices Architecture using Integrated Extract with downstream mining, the Extract process was repeatedly moving to the ABENDED state. The unusual part was that neither the Extract report file nor the GoldenGate error log showed any fatal OGG error.
The environment was using a Primary Database, Active Data Guard database, and a downstream mining database where the Integrated Extract was running.
Issue
The Extract showed the following status:
Extract EXTAI Status ABENDED
Log Read Checkpoint Oracle Integrated Redo LogsChecking the GoldenGate logs showed that the Extract was starting successfully.
INFO OGG-01360 EXTRACT is running in Integrated mode.
INFO OGG-02339 Integrated capture successfully attached to
logmining server OGG$CAP_EXTAI.
INFO OGG-00993 Extract group EXTRACT EXTAI started.
INFO OGG-02823 Positioning to SCN 14098709.
INFO OGG-01057 Recovery completed for all targets.There was no OGG error explaining why the Extract subsequently abended.
Checking LogMiner
The downstream mining database alert log showed that LogMiner was successfully processing redo.
LOGMINER: Begin mining logfile for session 7 thread 1 sequence 277
LOGMINER: End mining logfile for session 7 thread 1 sequence 277
LOGMINER: Begin mining logfile for session 7 thread 1 sequence 278
LOGMINER: End mining logfile for session 7 thread 1 sequence 278
LOGMINER: Begin mining logfile for session 7 thread 1 sequence 279
LOGMINER: End mining logfile for session 7 thread 1 sequence 279Real-time downstream mining was also enabled.
TRANLOGOPTIONS INTEGRATEDPARAMS (DOWNSTREAM_REAL_TIME_MINE Y)After enabling it, LogMiner successfully started mining the current redo as well.
LOGMINER: Begin mining logfile for session 7 thread 1 sequence 280,
/data/app/oracle/oradata/MINDB/onlinelog/o1_mf_4_nls0zjsb_.logHowever, the Extract still moved to the ABENDED state.
Finding the Actual Error
Since the GoldenGate logs did not contain the reason, the operating system core dumps were checked.
coredumpctl list | grep -i extract
PID: 12583 (extract)
UID: 54321 (oracle)
GID: 54321 (oinstall)
Signal: 11 (SEGV)
Timestamp: Fri 2026-08-21 11:29:20 IST
Command Line: /data/app/oracle/product/ogg26ai/bin/extract PARAMFILE /ogg/ggma26/GGHUBDEPLOY/etc/conf/ogg/EXTAI.prm REPORTFILE /ogg/ggma26/GGHUBDEPLOY/var/lib/report/EXTAI.rpt
Executable: /data/app/oracle/product/ogg26ai/bin/extract
Control Group: /system.slice/OracleGoldenGate.service
Unit: OracleGoldenGate.service
Slice: system.slice
Storage: /var/lib/systemd/coredump/core.extract.54321.<masked>.12583.<masked>.zst (truncated)
Size on Disk: 8.4M
Message: Process 12583 (extract) of user 54321 dumped core.
Module /data/app/oracle/product/ogg26ai/bin/extract without build-id.
Stack trace of thread 12583:
#0 0x000055f631dd2370
_ZN3ggs5gglib8ggocicpp13ORAConnection16isCloudAvailableEPNS0_9ggunicode7UStringE
(/data/app/oracle/product/ogg26ai/bin/extract + 0x7d2370)
ELF object binary architecture: AMD x86-64
This showed that the Extract process was repeatedly crashing with SIGSEGV.
SIGSEGV /data/app/oracle/product/ogg26ai/bin/extractThe core dump details were then checked.
coredumpctl info <pid>The actual error was:
Signal: 11 (SEGV)
Process (extract) dumped core.
Stack trace:
ggs::gglib::ggocicpp::ORAConnection::isCloudAvailable(...)This explained why no fatal OGG error was available in the report file or GoldenGate error log. The Extract process was crashing at the operating system level instead of performing a normal GoldenGate ABEND.
GoldenGate Version
The affected environment was running:
Oracle GoldenGate Capture for Oracle
Version 23.26.1.0.0Since LogMiner and downstream mining were working correctly and the Extract executable was repeatedly crashing with the same SIGSEGV, I’ve decided to upgrade Oracle GoldenGate.
Resolution – In My Case as a Trial
Oracle GoldenGate was upgraded from version 23.26.1.0.0 to 23.26.3.0.0.
After the upgrade, the same Integrated Extract was started again without recreating it. The Extract remained running successfully and transactions started flowing to the target through the Integrated Replicat.
The Replicat statistics confirmed that all 10 test records were successfully replicated.
2026-08-22T01:58:59.144+0530 INFO OGG-01680 Oracle GoldenGate Delivery for Oracle, REPAI.prm:
Start of statistics at 2026-08-22 01:58:59.
Integrated Replicat statistics:
Total transactions 1.00
Redirected 0.00
Replicated procedures 0.00
DDL operations 0.00
Stored procedures 0.00
Datatype functionality 0.00
Operation type functionality 0.00
Event actions 0.00
Database compatibility 0.00
Direct transactions ratio 0.00%
Replicating from PDB1.AVUKWEB.EMPLOYEES to TGPDB.AVUKWEB.EMPLOYEES:
*** Total statistics since 2026-08-22 01:57:50 ***
Total inserts 10.00
Total updates 0.00
Total deletes 0.00
Total upserts 0.00
Total discards 0.00
Total operations 10.00
End of statistics.The final GoldenGate status also confirmed that both Integrated Extract and Integrated Replicat were running successfully.
OGG (...) 10> info all
Program Status Group Type Lag at Chkpt Time Since Chkpt
EXTRACT RUNNING EXTAI INTEGRATED 6d:14:06:59 00:00:04
REPLICAT RUNNING REPAI INTEGRATED 00:00:00 00:00:09
OGG (...) 11>Conclusion
The Integrated Extract was repeatedly ABENDING without any fatal OGG error because the Extract executable itself was crashing with SIGSEGV Signal 11 in the ORAConnection isCloudAvailable function. The operating system core dump was therefore critical in identifying the actual problem.
Upgrading Oracle GoldenGate from 23.26.1.0.0 to 23.26.3.0.0 resolved the issue. After the upgrade, the existing Integrated Extract and Replicat remained running, and the test confirmed that all 10 records were successfully replicated to the target without any discards.
