文 | 劉漢檳

大數據量和高吞吐是銀行內容管理系統長期設計的核心問題，本文通過內容管理系統在農信銀行后督系統的設計和實現實例 (基于 DB2V97 數據庫)，描述對于內容管理系統如何針對每天大約 400 萬個圖片、可能存放 15 年達到 2PB 文件規模的大數據量系統進行數據模型設計、表分區以及壓縮的具體設計實現，以及系統在高并發下一些實際問題的處理，系統上線后吞吐量和性能得到了客戶的認可，可以為類似的銀行系統提供重要的參考。

前言

本文是對使用 IBM 內容管理系統為平臺的廣東農信銀行客戶后督系統的分析和介紹，以及對大數據量和高吞吐的基于 DB2 數據庫的 IBM Content Manager 系統的一些設計上的分析以及一些實際問題的解決，系統在調優后性能和吞吐量滿足的客戶的需求，可以作為類似系統的參考，但是要注意，每一個系統都有自己獨特的需求和實際情況，本文無法涵蓋您在系統建設過程中的所有問題。

另外，將來實際系統中在數據量達到一定量級時，可能會碰到新的難題，我們希望能和客戶一起協作解決并將經驗分享給大家。第 2 部分，我們將著重介紹實例問題和分析解決的辦法供類似系統參考。

對于實例系統中出現的與性能和高并發相關的關鍵問題的分析和解決

在客戶的實際后督生產系統中，在系統工程師的努力下，經過了對網絡、存儲、DB2、WAS、TSM 和 CM 的調優以后，依舊在高吞吐和為此設計的高并發的系統中發現了兩個棘手的問題，嚴重影響了性能，并造成了一些 CM 孤兒數據 (Orphan data) 很難被處理，這些問題雖然不一定會在每個系統中都出現，但一旦出現解決起來耗時耗力，在客戶和 IBM 支持人員的協作下，問題得到了圓滿的解決，本文借此機會感謝所有參與解決這些問題的客戶和 IBM 支持人員，并將問題和分析解決的思路共享出來，可以供有類似問題的高吞吐高并發內容管理系統參考。

問題一. 啟用遷移后資源數據庫占用 CPU 達到 100%

此時 I/O，網絡資源都很充足，根據對動態 SQL 語句的監控，發現大量并發操作會執行同一條語句。

清單 1. 造成 CPU100%問題的 SQL

此語句的訪問計劃 (Access plan) 雖然使用了如下的索引 TRAN_ID_X1，但是訪問的行數巨大并造成了巨量的邏輯讀，經過分析是造成 CPU 資源占用過大的根本原因。

清單 2. 調優前訪問計劃

分析 RMTRANSACTIONS 表可以發現此表是 VOLATILE 類型的表，并且有三個索引：

主鍵索引包含 (OBJ_COLLID, OBJ_ITEMID, OBJ_VERSION, OBJ_LIBRARYID, TRANSACTION_DATE) 字段。

索引 TRAN_TMP_ID_X0包含 (OBJ_TMP_COLLID, OBJ_TMP_ITEMID, OBJ_TMP_VERSION) 字段。

索引 TRAN_ID_X1包含 (TRANSACTIONID, TRANSACTION_DATE, PROCESSTIMEOUT) 字段。

根據清單 1 內動態 SQL 語句的寫法，訪問執行計劃可能使用兩種路徑，路徑 1 就是現在清單 2 中使用的索引 TRAN_ID_X1，路徑 2 就是在或 (or) 條件中使用主鍵索引和索引 TRAN_TMP_ID_X0。

由于 RMTRANSACTIONS 表是 VOLATILE 類型的表，VOLATILE 代表這個表是變動非常頻繁的表，統計信息已經不能正確反映實際的數據量，DB2 在表的查詢時候只要有滿足條件的索引，會忽略統計信息，優先使用索引，這個表的特點就是資源數據庫有事務發生時候會記錄相應的事務記錄，事務結束后會刪除相應的記錄。

所以一般情況下記錄很少或者為 0，當打包遷移發生時，會在短時間內有大量事務產生，記錄數可能在 0 到幾萬條之間頻繁變化，非常符合 VOLATILE 表的特性，而且這三個索引都有期望的 SQL 語句會經常使用，索引的設計和定義也沒有問題。那么問題出在哪呢?

我們結合遷移的場景仔細分析這個 SQL 語句，會發現，索引 TRAN_ID_X1(TRANSACTIONID, TRANSACTION_DATE, PROCESSTIMEOUT) 影響的查詢條件是 TRANSACTIONID<>?，業務的含義是尋找有沒有其他的 TRANSACTIONID 和現在要使用的是否有相同的。

對于一個遷移事務，對應的表內應該沒有相同的 TRANSACTIONID 或者至多一條，所以在這個<>? 的條件中，將會在索引掃描后對基礎表做全表掃描去匹配剩下的條件 (比如 OBJ_ITEMID) 等，這樣一來，使用這個索引的結果就是做了一次索引的全掃描加上全表掃描，這樣就會造成大量的行讀，這樣我們就分析出來錯誤的根本原因是在客戶的現場環境中對于 RMTRANSACTIONS 這張 VOLATILE 表沒有找到最優的訪問計劃，實際上數據分析的結果應該是選用路徑 2 的訪問計劃，這樣索引掃描的結果應該是幾乎為 0 的記錄數，也就基本沒有任何表掃描。

由于是 VOLATILE 表，此表本身統計信息長期為 0 不具備參考價值，優化器有可能會根據系統的各個條件選取路徑 1 或者路徑 2，我們測試的系統中都選擇了高效的路徑 2，但是客戶的實際系統中還是有一定的可能選擇路徑 1，即使選用路徑 1 這個問題也不一定都能暴漏出來，只有遷移的并發吞吐達到一定的量級 (比如每秒遷移超過 1000) 才可能會呈現出來，DB2 本身也對這種極少可能發生的訪問路徑選取異常設計了解決方案。問題分析出來以后，剩下的就是使用 DB2 提供的 OPTPROFILE 的方案去強制為清單 1 的 SQL 指定路徑 2 的索引方案。

下面是建立 OPTPROFILE 的步驟：

1.創建 SYSTOOLS.OPT_PROFILE 表

2.創建 PMR35104.PROF1.xml，包含 SQL 的 GUIDELINE

3.創建文件 profiledata，內容為”PMR35104″,”PROF1″,”PMR35104.PROF1.xml”

4.將 profiledata 裝載到 systools.opt_profile 表中;

5.檢查 SQL 語句是否走了新的索引。

6.檢查 db2exfmt_alan_exfmt_opt.out 文件，查看執行計劃是否如清單 3 所示。

清單 3. 調優后訪問計劃

從清單 3 左下部分中我們可以看到，查詢的訪問計劃已經轉而使用我們希望的主鍵索引和索引 TRAN_TMP_ID_X0 做索引查詢。

由于資源數據庫的應用是部署在 WAS 上的，在 DB2 服務端設置完后，需要對 WAS 端進行設置，使得 WAS 連接數據庫的應用使用 PMR35104.PROF1。

圖 1. WAS 應用 OPTPROFILE

添加定制屬性：

屬性名：optimizationProfile

屬性值：PMR35104.PROF1

定制完成后，需要重啟 WAS 服務器。

結論：在使用了 DB2 的 OPTPROFILE 的方法之后，進行測試后發現開啟單個 WAS 集群應用服務器后數據庫服務器的 CPU 使用率在 5%左右，4 個應用服務器同時啟動后，CPU 使用率大約在 20%左右，網絡的吞吐量能達到 400-500MB/秒, 遷移數量每個應用服務器都為 800 筆/秒左右，完全能滿足客戶的業務需求。

問題二. CM 裝載存在孤兒數據

如前文所述，客戶系統中每天白天需要裝載 400 萬圖片項，有 10 臺客戶端上載程序同時工作上傳，每臺客戶機有 10 個進程同時上載，也就是總共有 100 個進程同時上載文檔圖片，并且使用 4 組 WAS ND 集群服務器，每個集群包含 4 個節點。

在批量上載過程中，每導入幾千萬的數據，總會有一些孤兒數據產生，經過分析，這些孤兒數據產生的原因是，產生問題的幾條數據，每條數據對于同一個上載任務，有時間很近的兩條上載任務向資源服務器發出請求，雖然由于主鍵約束系統會拒絕其中的一條，但實際進入的一條時間戳會產生不一致，檢驗工具會把這條數據標記為孤兒數據。

經過診斷分析，CM 本身不會對同一條上載記錄做重復上載命令，最終認定是由于 RM 使用集群，IHS 使用安裝時默認的轉發功能導致，建議將 IHS 上的重新轉發功能取消。具體表現為同一個請求在一個節點上執行超時(默認為 60 秒)，IHS 可能將該請求轉發不同的節點上，而不同節點上的數據信息不一致，導致 CM 報錯并產生臟數據(包括孤兒數據)。對 WAS 的具體修改如下：

修改 IHS 的配置文件 plugin-cfg.xml，將其中的 ServerIOTimeout=”60″ 、PostBufferSize=”64&Prime;修改為 ServerIOTimeout=”300″ 、PostBufferSize=”0″。這樣設置表示，IHS 上的請求在 300 秒內沒有收到 WAS 的響應，不會自動進行轉發，會報超時錯誤。

修改 WAS 應用服務器的 ServerIOTimeout 參數(讀/寫超時)的值為 0，即讀寫超時時不轉發請求。

圖 2. WAS 修改讀寫超時

修改 CM 庫數據庫 ICMNLSDB 的 ICMSTSYSCONTROL.MAXTXDURATION 字段，默認是 86400(24 小時)，將其修改為較小值，IBM 建議不低于 7200 (2 小時)。該值表示 CM 事務執行的間隔等待時間。(update ICMSTSYSCONTROL set MAXTXDURATION = 7200 where LIBRARYSERVERID = 1)

結論：通過優化后的性能測試驗證，該設置起效，CM 多線程并發裝載再沒有出現臟數據。 小結 通過本文第 2 部分的介紹，我們可以了解 CM 高吞吐高并發實例系統中幾個特殊疑難問題的分析和解決方法。