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