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的平均等待時間相差很大，下面就需要詳細的調查網絡問題。