GoldenGate Extract Abends with "Unable to lock file" Error For Trail File
Applies to:
Oracle GoldenGate - Version: 9.5.0.16 and later [Release: 9.5.0 and later ]
Information in this document applies to any platform.
Symptoms
Extract abends, reporting "Unable to lock file" response from Server/Collector.
Cause
Network outages that last longer than the time the TCP/IP stack is configured to retransmit unacknowledged packets may result in "orphan" TCP/IP connections on the RMTHOST system. Since the local system has closed the connections and the "RST" packets were lost due to the network outage, no packets (data or "control") will ever be sent for these connections.
Since the RST packets were not delivered to the RMTHOST, the TCP/IP stack will not present an error to the Server/Collector process The Server/Collector process will continue to wait, passively, forever, for new data that will never arrive because the Extract process on the other system is no longer running.
As of v10.4, Server/Collector locks the trail file to prevent multiple processes from writing to the same trail file, so new Server/Collector processes are unable to lock the trail files.
A second cause for this symptom is that the remote server was rebooted and the Network-Attached Storage (NAS) device where the target trails reside did not detect and was not notified of the reboot, so the locks acquired prior to the reboot are still considered to be in force.
Solution
The best solution is to ensure that Server/Collector processes will detect when they have become "orphans" and terminate themselves; this will release the lock, release other resources used by the process, and enable a new Server/Collector process to do recovery processing as directed by EXTRACT.
Beginning with version 10.4.0.29 (on the target system - this is the version of Server/Collector), the "-w " option instructs the Server/Collector to terminate if it doesn't receive any checkpoint information from EXTRACT within "" seconds. For example:
RMTHOST 192.168.10.1, MGRPORT 7809, PARAMS "-w 40"
This tells the Server/Collector to terminate if it doesn't receive any checkpoint information for more than 40 seconds.
Under normal circumstances, EXTRACT will send checkpoint information at least every 10 seconds (or whatever interval is specified by the CHECKPOINTSECS parameter in the EXTRACT parameter file). If the network connection is broken, the Server/Collector will detect that is has not received any checkpoint information for longer than the specified interval and terminate.
Also available since v10.4.0.29, but less desirable, the "RMTHOST UNLOCKEDTRAILS" option (or "RMTHOST PARAMS -UL" option, or "UNLOCKEDTRAILFILES" in the GLOBALS parameter file) disables this protective mechanism.
Note: When two or more processes write to the same trail file, data corruption and loss of data integrity may result.
RFE 9425192 requests the implementation of a heartbeat mechanism between the Extract and Server/Collector processes, to enable the Server/Collector to detect that the TCP/IP connection has been lost and terminate within a reasonably short time. Transient, recoverable network problems, such as when a router is rebooted, may last longer than the value specified for the "-w " option described above, causing the Server/Collector to terminate "too soon" - EXTRACT will recover by starting a new Server/Collector process.
In the absence of either RFE 9425192, the "-w " option, or the "UNLOCKEDTRAILS" option, it is necessary to kill the orphan Server/Collector processes to recover from this situation.
In the case where the NAS was unaware that the system had been rebooted, the best long-term solution is to contact the NAS vendor, who might be able to provide an utility program that can be run early in the system startup process to notify the NAS that it should release all locks owned by this system. The following procedure might offer a short-term work-around:
1. Stop all REPLICAT processes that read the trail file.
2. Stop the target MGR process.
3. Rename the trail file that cannot be locked.
4. Copy the trail file to a new file with a different name than the original trail file.
5. Rename the copy of the trail file to the original trail file name.
6. Repeat steps 2-5 for each trail file that can't be locked.
7. From the shell, kill the server (collector) process that was writing to the trail. ie Check on OS level for orphan processes, e.g. on unix style OS's: ps -ef | grep server
If any such orphan servers exist, e.g.:
oracle 27165 1 0 11:20 ? 00:00:00 ./server -p 7840 -k -l /opt/oracle/gg/ggserr.log
Then: kill 27165 (or, kill -9 27165) (for this particular case)
8. Start MGR.
9. Start the REPLICAT processes.
10. Re-start the extract that abended and gave this error message.
Note that this may not work, depending on the NAS and the way it keeps track of advisory file locks acquired using fcntl( F_GETLK ).

RMTHOST 192.168.10.1, MGRPORT 7809, PARAMS "-w 40"

oracle 27165 1 0 11:20 ? 00:00:00 ./server -p 7840 -k -l /opt/oracle/gg/ggserr.log
Then: kill 27165 (or, kill -9 27165) (for this particular case)