Ogg Capture Client Successfully Detached From Goldengate Capture Review
Since the message is informational, why do DBAs search for it? Usually, because it appears before or after an error.
When you encounter the log message "Capture client successfully detached," follow these steps to ensure system health:
1. Verify Process Status
Check the OGG process status via GGSCI. If the detachment was due to a stop command, the status should be STOPPED. Since the message is informational, why do DBAs
GGSCI> STATUS EXTRACT <extract_name>
2. Check for Re-attachment (If applicable) If the detachment was temporary (e.g., a restart), look for the corresponding "Capture client successfully attached" message immediately following the detachment in the Report file.
3. Verify Checkpoints Ensure the checkpoint was updated prior to detachment. This guarantees that when the Extract restarts, it knows exactly where to resume reading. Long-running idle connections may be terminated by firewalls
GGSCI> INFO EXTRACT <extract_name>, SHOWCH
Long-running idle connections may be terminated by firewalls or load balancers. Ensure your IDLETIMEOUT in OGG is set lower than any network idle timeout (e.g., IDLETIMEOUT 10 minutes if firewall times out at 15 minutes).
Do not alert on the message itself. Instead, alert on: INFO EXTRACT <
| Feature | Attached State (“Running”) | Detached State (“Stopped”) |
| --------------------------- | ------------------------------------------------------ | -------------------------------------------------------- |
| Connection to LogMiner | ACTIVE – consuming redo data. | CLOSED – no data flow. |
| Redo Log Retention | LogMiner holds logs needed by the client. | Logs are released for normal recycling. |
| Database Resource Usage | CPU & memory used by LogMiner server. | Minimal – only checkpoint table retained. |
| Extract Process | Running as OS process. | Stopped or in a waiting state (if BEGIN or END use). |
