How about that gg_heartbeat_history table?

How about that gg_heartbeat_history table?

Heartbeat tables are used to monitor the lag throughout the data replication cycle. Automatic heartbeats are sent periodically from each source database into the replication streams. These heartbeat records are inserted or updated into the heartbeat table at the target databases. By comparing the timestamps of these heartbeat records, the current and historical lags in each of the replication can be computed.

To compute lag at each point in the replication stream, I want to get information for these columns in the gg_heartbeat_history table:

(a) incoming_heartbeat_ts – source side heartbeat timestamp

(b) incoming_extract_ts – timestamp when extract processed the heartbeat record

(c) incoming_routing_ts – timestamp when data pump read the heartbeat record from the extract trail

(d) incoming_replicat_ts – timestamp when replicat read the heartbeat record from the remote trail

(e) heartbeat_received_ts – timestamp when replicat applied the heartbeat record to the target


With this information, we can now compute the following:


(a) heartbeat_received_ts – incoming_heartbeat_ts = total end-to-end lag
(b) incoming_extract_ts – incomning_heartbeat_ts = cdc extract lag
(b) incoming_routing_ts – incoming_extract_ts = data pump read lag
(c) incoming_replicat_ts – incoming_routing_ts = replicat read lag
(d) heartbeat_received_ts – incoming_replicat_ts = replicat apply lag

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.