Monitoring replication in the Db2 console
You can monitor the status of your replication sets and tables, and keep track of latency, throughput, and other activity.
Live monitoring graphs display on the details page for each replication set. They provide high-level monitoring information, and details about replication latency and throughput. You can change the time period for the statistics by clicking the time indicators at the top of the page.
Performance data is reported by the replication programs in Db2 tables every 10 seconds and is retained for seven days by default. The data is refreshed in the console dashboard every 30 seconds.
- High level - Consistency point
- The high-level status summary on the left is labeled with the replication set name. It shows the
Consistency point of transactions at the target for the active tables in the
replication set, which helps you determine how caught up replication at the target is with respect
to database activity at the source. It is the source commit time for which all transactions to that
point have been applied to the target.
The graph also shows whether the replication set is active, and then breaks down activity by table to show which tables in the set are active, which have errors, and the status of target table loading activity.
- Average Latency
-
After you start a replication set, you can view the latency of replication, or the time that it takes for transactions to be replicated from the source to the target database. The end-to-end latency is the average time per transaction between commit at the source by the application and commit at the target by the replication process. The details page for each replication set depicts latency with a multicolored graph that gives you an at-a-glance view of the different types of replication latency:
- Queue latency
- The average elapsed seconds between the time that messages are put on the send queue and the time that the target apply program gets them from the receive queue. This statistic includes the time that transactions were waiting in the receive queue of the target system, and is not necessarily a reflection of network performance.
- Capture latency
- The average elapsed milliseconds between the time transactions were committed to the source table by the application and the time the transactions were put on the transmission queue for transport to the target. It indicates the performance of the log capture process. Note that if you suspend replication, this number is high on restart because the capture process is reading older logs.
- Database latency
- The average elapsed milliseconds per transaction between the time that the first row change for a replicated transaction was applied at the target database and the time that the transaction was committed at the target database. This statistic indicates the performance of Db2 at the target system.
- Apply latency
- The average elapsed milliseconds that it takes the replication programs at the target to read transactions and commit them to target tables. This statistic includes the database latency.
- Throughput
-
Throughput is the number of insert, update, and delete operations per second that were applied to the target for all tables in the replication set. The data is sampled every 30 seconds, and computed by the replication program every 10 seconds. The graph breaks down throughput into two categories:
- Target throughput
- The number of rows per second that were applied at the target during the sampling interval.
- Source throughput
- The number of rows per second that were sent from the source during the sampling interval.