在DB2数据库HADR监控中发现，每天有一段时间，有很多应用处于commit active状态，对应用性能有影响
成都做网站、网站制作的关注点不是能为您做些什么网站，而是怎么做网站，有没有做好网站，给创新互联公司一个展示的机会来证明自己，这并不会花费您太多时间，或许会给您带来新的灵感和惊喜。面向用户友好，注重用户体验，一切以用户为中心。
猜测可能是两种原因造成
日志写的慢
网络通信慢
到底是哪个原因那？用监控数据来说话。
以每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的平均等待时间相差很大，下面就需要详细的调查网络问题。
