Managing Timeout Issues in GoldenGate

GoldenGate operations may experience a load wait situation when propagating changes into a log-based cache group, which could lead to a timeout.

The timeout can happen under the following conditions:

• The cache group is in a paused autorefresh state and changes are being propagated into it.
  • Log-based cache groups must be loaded before they can be propagated into. These waits and log messages are designed to notify users of the issue.
  • The daemon log shows the following message:

    Autorefresh was not able to acquire lock on one of the cache groups.

• The operation being propagated by GoldenGate is more recent than the ongoing dynamic loads.
  • This wait ensures cache instance consistency and is necessary for correctness.
  • The daemon log displays the following message with the details of the affected table and SCNs:

    GoldenGate connection waiting for pending dynamic loads.

In both cases, the daemon log periodically issues warnings about long waits. Additionally, the loadWait statistic increments each time there is a wait when propagating a change to a parent table row.

Similar to other long-running operations, these can eventually time out. If the timeout errors are not managed by the Replicat, it may cause the Replicat to terminate and result in error TT5988, "GoldenGate autorefresh operation has exceeded the timeout_desc timeout [timeout_secs secs].info" .

The timeout will trigger based on the lowest defined connection-level timeout between LockWait (lock timeout) and SQLQueryTimeout. For details, see LockWait and SQLQueryTimeout in the Oracle TimesTen In-Memory Database Reference.