DB2 集群工作方式介紹

DB2 是同時兼備高擴展性和高可用性的數據庫集群，同時對于應用是透明的。無論是連接到數據庫的哪個成員，應用都無需任何更改，對于應用來說，可以認為它僅僅是連接到單個的數據庫。DB2 工作負載均衡特性幫助數據庫更好的充分利用資源。但是畢竟 DB2 是一個數據庫集群，運用的技術遠比單機版數據庫復雜。同時新技術的運用對性能帶來什么樣的影響，以及如何去監控和應對，都是用戶在使用 DB2 集群后亟需解決的問題。

首先從 DB2 集群的架構出發，下面這張圖顯示了 DB2 集群所使用到的產品和比較重要的技術。DB2 使用了 IBM 的 TSA（Tivoli System ）集群軟件整合所有資源，并自動化所有資源的行為，從而搭建整套的集群環境。

圖 1. DB2 集群的架構

DB2 集群成員

DB2 集群可以有多個成員（member）組成，每個成員都可以看成是一個能夠提供完全數據庫服務的節點。任何應用只需要連接到一個成員即為連接到整個數據庫，所以在 DB2 集群里面有多少成員對于應用是透明的。

DB2 集群的自動工作負載均衡能將工作負載均衡到多個數據庫成員上，從而充分利用成員的硬件資源，滿足高性能的需求。DB2 集群的高擴展性能夠幫助用戶通過增加成員來滿足更高性能的需求。

DB2 集群 CF

在 DB2 集群里面，成員之間的協作是由 CF（Cluster Caching ）幫助完成的。在數據庫成員和 CF 之間有高速網絡相連（ 網絡），成員和 CF 之間通過 RDMA（遠程內存直接訪問）的方式交互數據，這種技術跳過了網絡協議所需要的交互，是非?？斓?。CF 主要管理整個數據庫集群的通信，控制全局鎖和全局緩沖池等。可以說 CF 就是 DB2 集群的大腦，它對于性能會有很大的影響。

DB2 集群網絡

在 DB2 集群里面，成員和 CF 需要兩種高速網絡互聯： 網絡和高速以太網。如果網絡出現問題或者擁擠，會對性能有影響。

DB2 集群共享存儲

DB2 是使用共享存儲的數據庫集群。所有數據庫的存儲需要連接到所有成員和 CF。DB2 會在存儲上創建 GPFS 文件系統。GPFS 文件系統是一種高速的共享文件系統，它同樣是一個文件系統集群，具有高可用性和易擴展性，易管理性等。成員的 CPU，內存等可以通過增加新的硬件資源或者增加成員等方式來滿足。但是存儲這邊就沒有那么簡單，所以需要監控存儲的利用率確定是否遇到瓶頸而導致性能問題。

關于硬件資源的所帶來的性能影響，例如內存不夠，網絡擁擠，磁盤 IO 瓶頸等，這些可以通過系統的監控工具來確定。非集群 DB2 數據庫可能遇到的性能問題和解決方法，在 DB2 集群同樣適用。下面會就 DB2 集群本身的特點所帶來的性能問題做一些探討。

探討數據庫成員的工作負載

DB2 自動工作負載均衡是數據庫集群里面對性能非常有幫助的一個特性。DB2 支持連接級別和事務級別的工作負載均衡。這個兩種級別的負載均衡可以在 DB2 客戶端配置啟用，DB2 客戶端就會從數據庫集群獲取所有成員的負載信息，然后根據負載信息來確定下一個連接或者事務運行到負載低的數據庫成員上，從而達到負載均衡的效果。所以 DB2 性能課題之一就是如何用好自動負載均衡特性，解決成員節點出現瓶頸的性能問題。

圖 2. 自動工作負載均衡

監控 DB2 集群成員負載信息

DB2 提供了工具直接查看 DB2 集群成員的負載信息。db2pd 是 DB2 提供的一個功能強大和豐富的工具，占用資源少，速度快。db2pd 可以查看數據庫級別的負載信息。

清單 1. 查看 DB2 集群成員的負載信息

如清單中所示，當前有連個數據庫成員 和 ，它們提供了 Non-SSL 端口連接，每個成員的負載信息是看 這一項。這個數值越大，這個成員上的負載就越輕。如果這個成員出現異常不能工作，那么它的 就會是 0。

清單 2. 異常成員的負載信息

數據庫成員 被終止后，它的 值變為 0. 如果其他的成員 比較小，而某個成員的 是 100，說明這個成員是完全空閑的。

分配 DB2 集群成員負載

分配應用工作負載均衡到 DB2 集群各成員有兩種方式，一種是使用自動工作負載均衡特性，另一種是自定義應用連接到指定的數據庫成員。

如何啟用自動工作負載均衡特性可以參考作者的另外一篇文章《如何部署 DB2 工作負載均衡特性》或者其他資料。這里探討一下在使用了自動工作負載均衡之后的行為。數據庫的負載信息一直在變化，客戶端什么時候會感受到這個變化呢？客戶端從數據庫服務器獲取了服務器列表的負載信息，然后儲存在本地。一段時間間隔后，客戶端會重新獲取當前的服務器負載信息，更新本地的服務器列表。這個時間間隔如果比較長，那么客戶端對服務器負載信息的反應就不會很敏捷，自動工作負載均衡的效果就會受到一定的影響。但是如果這個時間間隔設置的太短，那么收集服務器負載信息的工作就會變的頻繁，相應的開銷也會變大。所以這里需要考慮的是估算一個比較合適的時間間隔。這個時間間隔由客戶端配置參數 控制。

清單 3. .cfg（）

DB2 客戶端可以使用 .cfg 配置文件來配置 參數。對于 JAVA 應用，JDBC 驅動里面也有這個參數。這個參數的默認配置是 30 秒，也就是 DB2 客戶端每 30 秒從數據庫服務器獲取負載信息并更新本地保存的服務器列表。

另一種方式就是不使用自動的負載均衡，而是應用指定使用哪個數據庫成員?？蛻舳似迷O置（Client ）就是這樣一種工作方式。如果用戶了解自己的應用負載狀況，那么就可以合理的安排應用去連接數據庫成員，從而利用所有成員的資源。例如用戶可以把負載高的成員上的應用連接到其他負載低的成員。這種方式對用戶要求比較高。

探討 DB2 集群全局緩沖池（GBP）技術

DB2 集群里面 CF 扮演了很重要的角色，其中之一就是引入了全局緩沖池的概念。全局緩沖池是 CF 加載的一部分內存區，顧名思義是緩沖整個集群的數據庫數據。那么與此對應，每個數據庫成員自己的緩沖池就稱為本地緩沖池（LBP）。下面通過一個例子來看 LBP 和 GBP 的關系。

圖 3. 查詢數據（GBP 和 LBP）

上圖所示，在 member 1 上有個應用想要訪問 page 501 里面的數據，這個時候 member 1 的本地緩沖池并沒有這個數據，但是 CF 的全局緩沖池里面是有的。那么 Member 1 就會通過 RDMA 的方式直接訪問 CF 獲取這個數據，并放置到本地緩沖池中。在上面這個例子中，如果 CF 的全局緩沖池沒有 page 501，那么 member 1 需要從本地磁盤讀取。因為 RDMA 是直接物理訪問對方內存，比從本地磁盤讀取還要快很多。所以如果需要訪問的數據能在全局緩沖池里找到，那么訪問的性能會更好。

監控全局緩沖池的性能指標

本地緩沖池有命中率的概念，命中率越高，那么說明需要訪問的數據在內存里發現的比率越高，相應的性能就會越好。對于全局緩沖池來說也是一樣，成員需要訪問的數據在 GBP 里面發現的次數越多，說明從磁盤讀取的次數越少，也是性能會更好。所以監控 GBP 就是監控它的命中率。DB2 提供了 表函數提供這些信息。

清單 4. 使用 的方法

使用 db2 命令運行上面的語句，會得到所有緩沖池有關 GBP 的命中率。

圖 4. 調用 表函數結果

從上面的命令輸出結果來看，GBP 的命中率都比較低。如果是因為 GBP 的內存不夠大而引起很多的 paging，那么增大 GBP 的大小會有助于提高緩沖池的命中率，從而提高查詢的性能。

探討 DB2 集群全局鎖管理（GLM）技術

DB2 集群里數據庫成員之間的鎖機制是由 CF 的 GLM 管理的。與緩沖池類似，數據庫成員本地是有鎖機制的，也就是內存里的 塊。但是本地鎖只能管理本地資源的交互。如果多個數據庫成員同時需要更改同一頁內的數據，就會產生競爭，為了保持數據的一致性，這種行為就需要鎖的控制。來看一個例子。

圖 5. 更新數據（GBP 和 GLM）

在這個例子中，所有 4 個 member 的 LBP 中都有 page 501. 這個時候 member 1 想要更改 page 501 里面的數據。它就需要向 CF 的 GLM 請求這個 page 的鎖。member 1 更新完這個數據，顯然其他 member 的 LBP 里面的 page 501 就過時了，CF 會自動的使用 RDMA 技術把所有其他 member 的 LBP 里的 page 501 設置為無效。這樣一旦其他 member 還需要訪問這個 page 的數據，就不會使用無效的 LBP 的內容，而是從 CF 獲取更改過的新的內容。整個過程，GLM 的鎖機制保持了數據一致性。如果 member 1 從 GLM 獲得了關于 page 501 的鎖并沒有釋放，其他 member 還要更改 page 501 里的其他內容的話，也需要向 CF 申請鎖，CF 就會告知此 page 鎖已被 member 1 使用，請等待 member 1 釋放。這個時候就會出現鎖等待。這是需要監控的性能指標之一。如果 member 1 一直不釋放鎖，那么其他 member 上的應用會因為一直等不到這個鎖而產生鎖超時而失敗。鎖超時的次數也是需要監控的。member 之間的鎖是 page 這個級別的，如果 GLM 比較小，同一 table 的 page 鎖需求又比較多，就可能引起鎖升級，也就是這張表的所有 page 鎖升級成整張表的表級鎖，其他的 member 甚至無法訪問其他 page 的數據，這會影響并發性，帶來更差的性能。所以全局鎖的鎖升級次數也是需要關注的。

監控全局鎖管理（GLM）的性能指標

正如上文所述，我們需要監控與全局鎖管理相關的鎖等待，鎖超時，鎖升級等相關性能指標。DB2 提供了多個表函數可以列出全局鎖管理的這些監控元素。這里使用其中一個表函數 MT 來示范。這個表函數會收集當前數據庫的 PACKAGE CASH 里面的信息，返回為一張表，可以被 SQL 語句直接調用。

清單 5. 調用 MT 表函數

在調用 MT 返回的眾多信息中，案例里面查詢了 ，L,, 等與全局鎖管理相關的監控元素。

：因為鎖被其他 member 占用而等待的次數。次數越多說明并發性受影響越大。

L：等待其他 member 占用的鎖的時間。時間越多說明并發性受影響越大。

：因為等待其他 member 占用的鎖而產生的超時次數。事務會因此失敗而回滾。

：全局鎖升級的次數。鎖升級會導致并發性的嚴重降低。

這個表函數對于在查詢當前一段時間的系統性能問題是否是因為全局鎖而引起非常有效。因為 Package Cache 的大小是有限的，所以早些時間運行的 SQL 語句可能已經被擠出這個內存塊，就不會被這個表函數返回。DB2 還提供了其他一些針對不同對象的表函數，也能反饋這些全局鎖的信息。例如 ，， 等等。

解決全局鎖的性能問題

已經從上文中獲取到了引起全局鎖問題的 SQL 語句，相應的也定位到了相關的應用。現在的問題是已什么樣的思路去解決性能指標所示的這些問題。

首先還是從全局鎖的產生原因來看。全局鎖是 member 之間的鎖，也就是在不同的 member 上運行的應用需要訪問同一個表的相同 page 內的數據。一種解決的方式就是將這些應用安排到同一個 member 上運行，就不存在 member 間競爭的問題。這種方式可以通過設置客戶機偏好的方式。前提是定位到是哪些應用有沖突，單個 member 的系統資源是否足以運行這些應用。

另外一種方式是在應用的事務中加入更多的 Commit。提交越頻繁，鎖就釋放的比較快，相應的減少鎖沖突的幾率。

如果某些全局鎖無法避免，但是應用會經常因為鎖超時而回退。這對終端用戶會有很大的影響。這個時候可是適當增加鎖超時設置的時間。這個時間可以通過更改數據庫參數 。這個值如果是 -1，將永不超時。

最后看看全局鎖升級的問題。全局鎖升級的原因一般是因為全局鎖使用的內存不夠，只能把多個頁級別的鎖升級為單個表級別的鎖來減少內存開銷。所以解決全局鎖升級的辦法是適當增加 CF 里面這個內存的大小。這個大小由數據庫參數 控制。

探討 DB2 集群 Page 行為

上一章節描述了多個 member 訪問同一 page 會產生鎖等待的問題?，F在來討論與此相關的數據庫的另外一個行為 -Page （數據頁回收）。先通過一個例子來了解 Page 是如何發生的：

假設有兩個數據庫成員 M1 和 M2。M1 和 M2 想要同時去更行相同數據頁里面的兩個不同的行。

1. M1 正在更新數據頁 P1 里面的行 R1. 它被授以 P1 的獨占鎖。

2. M2 想要更新 P1 里面的行 R2。它像 CF 請求相同的數據頁 P1 上的獨占鎖并等待。

3. CF 看到 M1 已經占用了這個數據頁的獨占鎖，CF 會向 M1 發送一個回收此頁的請求。在此期間，M2 一直等待。

4. M1 處理這個數據頁回收請求并把數據頁寫回到 CF 的 GBP 中，然后釋放這個數據頁。這個時候 M1 仍然占用著它原有的關于這個表的行級鎖。

5. CF 授權 M2 能使用這個數據頁。M2 從 GBP 里面把這個數據頁讀到本地并繼續處理。

從 M2 申請數據頁到從 GBP 獲取到它，這個時間會被計算到應用的運行時間里面，也是數據庫性能中重要的一塊。我們需要監控這種行為對性能帶來的影響。

監控 Page 行為

DB2 提供了 INFO 表函數來提取相關的信息。這里需要關心的是什么表經常發生這樣的行為，這種行為消耗了多少時間。這種行為發生在哪個數據庫成員上。

清單 6. 調用 INFO 表函數

上述的這個方法可以找出數據頁回收而消耗的時間最多的表。 返回等待的時間，單位是毫秒。

解決 Page 性能問題

Page 其實還是全局鎖的問題。解決的思路和前述的解決全局鎖問題差不多。對于 Page 的監控能夠更直觀的發現時間消耗了多少，從而定位系統的性能問題多大程度與此相關。

DB2 集群環境性能調優總結

我們已經討論了相對于單節點的數據庫，DB2 集群環境里面用到的新的技術和事務的處理過程。探討了這些新的數據庫內容對于性能所帶來的影響以及怎么去應對。但是數據庫集群的性能問題受多方面因素影響，用戶需要不僅從 DB2 集群環境新的技術角度，還是要從系統資源的角度，從單數據庫節點調優的角度去處理數據庫的性能問題。