While working on a client’s GoldenGate 26ai environment, I ran into a NFS-related replication issue that could have been serious, had it happened in production. Here is what happened and how the issue was fixed.
The client’s GoldenGate extract was running on a dedicated server, capturing changes from an Oracle 19c source database. Trail files were written on an NFS. Depending on the configuration, this is officially supported by Oracle, and works rather well.
OGG-02897 / OGG-01668 Input/Output Error
On a Monday morning, however, the extract was ABENDED. The extract had been down since Saturday night, with the following error messages:
2026-06-07T00:19:11.404+0200 ERROR OGG-02897 Oracle GoldenGate Capture for Oracle, EXT.prm: Failed to synchronize trail file. Error detail: Could not sync "PDB1/aa000000009" (error 5, Input/output error).
2026-06-07T00:19:11.404+0200 ERROR OGG-01668 Oracle GoldenGate Capture for Oracle, EXT.prm: PROCESS ABENDING.
The extract was failing with an OGG-02897 error. The OS-level error, errno 5: Input/output error, did not seem to indicate any good news for us. Needless to say that restarting the extract did not fix the issue.
Root Cause Analysis
A firewall upgrade had taken place that Saturday night. The firewall between the GoldenGate server and the NFS server was upgraded, and it briefly went down during the operation.
The real problem was what happened after the firewall came back up: some extracts caught up and managed to restart properly, while other were left in this ABENDED state, unable to restart. For these extracts, I/O operations kept failing even though the network path was healthy again.
Solution: Remount the NFS
The solution was to stop all GoldenGate processes whose trail files were generated on the NFS, including all the processes which were running fine, and then unmount and remount the NFS filesystem.
# Unmount the NFS path
umount /path/to/nfs
# Remount all filesystems defined in /etc/fstab, including the NFS
mount -a
Once that came back up, I restarted the extracts from the adminclient and they all started successfully.
In this case, the firewall upgrade happened during the night with no GoldenGate-aware procedure in place. Next time, a scheduled GoldenGate maintenance spanning over the firewall upgrade window will probably avoid crashing multiple replications during the week-end, or worse.