DB2 HADR性能分析

在DB2数据库HADR监控中发现，每天有一段时间，有很多应用处于commit active状态，对应用性能有影响

猜测可能是两种原因造成

1. 日志写的慢
   

2. 网络通信慢

到底是哪个原因那？用监控数据来说话。

以每5秒钟一次的频率，运行下面的SQL

INSERT INTO temp1 select CURRENT_TIMESTAMP, LOCK_WAIT_TIME ,LOG_DISK_WAIT_TIME,TOTAL_COMMIT_TIME from TABLE(MON_GET_WORKLOAD('',-2)) AS t;

一起运行的还有下面的这个SQL

INSERT INTO temp2 select CURRENT_TIMESTAMP,LOG_WRITE_TIME,LOG_WRITES,LOG_HADR_WAIT_TIME,LOG_HADR_WAITS_TOTAL from table(mon_get_transaction_log(-1)) as t;

表函数的监控，得到的是一个累积值，想办法得到每5秒钟的差值，就可以看到哪一段时间内，数据发生了异常

来自表temp1的数据

TIMESTAMP / LOCK_WAIT_TIME /LOG_DISK_WAIT_TIME/TOTAL_COMMIT_TIME
17:39:16,  0,               2,                  3,
17:39:21,  0,               2,                  2,
17:39:26,  0,               2,                  2,
17:39:31,  0,               4,                  4,
17:39:37,  0,               2,                  2,
17:39:42,  0,               9,                  9,
17:39:47,  0,               3,                  3,
17:39:52, 79,              99,                 99,  <====
17:39:58,  0,               3,                  3,
17:40:03,  0,               2,                  2,
17:40:08,  1,               4,                  4

LOG_DISK_WAIT_TIME和日志写时间，还可能和HADR通信时间相关，在HADR环境下，SYNC或者NEARSYNC模式，Primary端的transaction需要获得Standby端的确认信息以后才能Commit，这个地方就涉及到了HADR的通信。

下一步就要看对于一个transaction，日志写平均需要多长时间，HADR通信需要多长时间

来自表temp2的数据

Log write Time per IOs = LOG_WRITE_TIME(把日志写到磁盘上的时间，单位是微妙） / LOG_WRITES (日志写的次数）
AVG HADR Wait time   = LOG_HADR_WAIT_TIME (等待HADR把日志发送完成的时间)/ LOG_HADR_WAITS_TOTAL (总等待次数)

TIMESTAMP /Log write Time per IOs /AVG HADR Wait time
17:39:16, 0.310,                  0.041
17:39:21, 0.298,                  0.042
17:39:26, 0.308,                  0.040
17:39:32, 0.302,                  0.072
17:39:37, 0.294,                  0.042
17:39:42, 0.342,                  0.805<===
17:39:47, 0.326,                  0.058
17:39:52, 0.334,                  0.485<===
17:39:57, 0.344,                  0.064
17:40:02, 0.299,                  0.046

通过数据可以看到日志写的时间，没有发生多大的变化，但是HADR的平均等待时间相差很大，下面就需要详细的调查网络问题。