1. The top pane shows the capture log latency. This is the amount of time that capture is behind the DB2 log.

    Note that if the DB2 system is lightly loaded, the log latency may appear higher than it really is. The log latency value shown is the time difference between the current time and the time of the last syncpoint that Capture has read. If DB2 is not processing updates, it does not write any log records, so the time of the last syncpoint record remains constant.

    This value is calculated by subtracting MONITOR_TIME from SYNCHTIME in the IBMSNAP_CAPMON table.

  2. The second pane shows capture throughput as a running graph of the number of rows per second being sent to the CD tables. The average throughput is a running average over the last 1000 time intervals. If the refresh interval is 10 seconds, then this is the average over the last ~3 hours.

    Next to the average is the throughput trend. This is an indicator on how the average over the last 30 intervals relates to the larger average. If the trend shows as an arrow pointing up, the throughput is increasing. If the trend is an arrow pointing down, the throughput is decreasing.

    This value is calculated by fetching CD_ROWS_INSERTED from the IBMSNAP_CAPQMON table and dividing the value by the number of seconds that has passed since the last row was fetched. If the value is 0, then the no activity message is shown.

    Note that if the throughput alternately shows zero rows, and then a value, the issue may be that MONITOR_INTERVAL is less than COMMIT_INTERVAL. The CD_ROWS_INSERTED value is only non zero after capture commits the rows.