DB2 性能優化快速入門

李越 ([email protected]), 軟體工程師, IBM

王飛鵬 ([email protected]), 軟體工程師, IBM

狄浩 ([email protected]), 軟體工程師, IBM

張蓉蓉 ([email protected]), 軟體工程師, IBM

DB2 性能優化概述

IBM 為社群提供了 DB2 免費版本 DB2 Express-C，它提供了與 DB2 Express Edition 相同的核心資料特性，為建構和部署應用程式奠定了堅實的基礎。

DB2 性能優化是一件較為複雜的綜合性的工作 , 需要對問題的根源作全方位的探索和思考。同時也需要較深厚的資料庫管理經驗與優化知識。這對于初學者來說可能有些勉為其難。但是在很多情況下，随着 DB2 資料庫中的資料量的不斷增長或者使用者數的激增，資料庫系統的性能會顯著下降，而此時快速定位性能上的瓶頸則至關重要。下面簡要地介紹一下 DB2 的調優的一些因素和工具，以及一些原理，使初學者對性能優化能夠有一個大緻的了解。

DB2 的性能優化可以從三個方面分析：記憶體，CPU 和 I/O 。

記憶體因素

在記憶體方面，主要是考慮緩沖池 (BUFFERPOOL) 的使用。緩沖池是一片用來緩沖從磁盤上讀取的資料和索引的記憶體區域，這些資料和索引資訊在緩沖池中進行運算後最終還要寫回磁盤。緩沖池的頁面大小有四種 (4K,8K,16K,32K)，分别對應四種不同頁面大小的表空間。緩沖池的大小決定了能夠從磁盤上緩沖資料的容量大小。當然緩沖池也不是越大越好，緩沖池過大可能會導緻連接配接資料庫的時間過長，因為在連接配接資料庫時要為資料庫的緩沖池配置設定記憶體空間。可以通過計算緩沖池的命中率來評估緩沖池的使用效率：緩沖池命中率 =(1-(( 資料實體讀 + 索引實體讀 )/( 資料邏輯讀 + 索引邏輯讀 ))) *100%，緩沖池命中率越大說明緩沖池的使用效率高。緩沖池命中率太小說明緩沖池太小應當調大。其中的資料實體讀，索引實體讀以及資料邏輯讀和索引邏輯讀都可以從緩沖池的快照中擷取。

在記憶體方面要考慮的另外幾個重要因素是排序堆 (SORTHEAP)，鎖清單 (LOCKLIST), 日志緩沖區 (LOGBUFSZ) 。排序堆在查詢結果帶有排序選項而沒有相關索引對應時将會被使用，排序堆太小會産生排序溢出 (Overflowed), 那些在排序堆中裝不下的排序資料将會溢出到一個臨時表中，這會使性能下降。與 SORTHEAP 參數相關的是 SHEAPTHRES_SHR 和 SHEAPTHRES，SHEAPTHRES_SHR 限制了一個資料庫中共享排序的最大記憶體，SHEAPTHRES 限制了私有排序的最大記憶體。 LOCKLIST 指的是一個資料庫中用來存放鎖的記憶體空間，當這個參數設得過小會導緻在鎖用光這部分資源後導緻鎖更新（即多個行鎖轉化為一個表鎖來釋放出更多的資源）。這會導緻系統的并行性下降，很多應用連接配接出現挂起，使得系統的性能衰退。是以盡可能調大 LOCKLIST 參數，這裡需要指出 LOCKLIST 指的并不是鎖的個數，而是以資料庫頁為機關的一片記憶體區域（在 32 位系統中每個鎖需要 96 個位元組，鎖上加鎖的話每個鎖則需 48 個位元組。在 64 位系統中每個鎖需要 128 個位元組，鎖上加鎖的話每個鎖則需 64 個位元組）。與 LOCKLIST 參數對應的是 MAXLOCKS 參數，MAXLOCKS 定義的是一個百分數，它指定了一個應用程式所能占用的最大的鎖空間占 LOCKLIST 的比例。日志緩沖區 (LOGBUFSZ) 指的是日志在寫到磁盤以前用于緩沖的一片記憶體空間，這樣可以減少寫日志帶來的過多的 I/O 。

從版本 9 以後 DB2 推出了一個新特性自調節記憶體管理器 (STMM: Self Tuning Memory Manager), 這個特性使得很多記憶體參數如前面所述的 SORTHEAP，LOCKLIST，LOGBUFSZ 等進行自動調節，當資料庫參數 SELF_TUNING_MEM 設為 ON, 這些參數設為 AUTOMATIC 即可以進行自動調整。這樣可以節省很多人工調整的時間。

CPU 因素

關于 CPU 因素首先是考慮 DB2 優化器 (OPTIMIZER) 對通路計劃 (ACCESS PLAN) 的分析與優化。一般來說，一條 SQL 在執行時首先會被解析，然後進行語義分析，進而重寫 SQL, 優化器會對重寫過的 SQL 進行基于成本的分析最終選擇最有效的通路計劃。最終生成可執行代碼（執行計劃）來執行這條語句。查詢通路計劃的工具有很多，既有圖形化工具 Visual Explain，也有指令 db2exfmt 來格式化解釋表 (Explain tables) 中的資料生成 ACCESS PLAN 。還有指令 db2expln 查詢 ACCESS PLAN 。

在 DB2 裡的優化級别分為九級，預設是第五級，級别越高優化器分析得程度越深。這個級别有資料庫配置參數 DFT_QUERYOPT 決定。并不是級别設得越高性能越好，因為對于一些較為簡單的 SQL 語句，如果優化級别過高那麼花在優化 SQL 上的時間就會過長，而執行時間相對來說很短，有些得不償失。在選擇通路計劃時，索引掃描的效率往往會比表掃描要高，是以索引的優化也是值得注意的。正确的建立索引會使查詢性能大幅度的提高。

在 DB2 中連接配接 (JOIN) 分為三種：嵌套循環連接配接 (nest-loop join), 合并連接配接 (merge-join), 散清單連接配接 (hash-join) 。一般來說效率最低的是嵌套循環連接配接，這種連接配接采用的是笛卡兒集，進行多次循環周遊得到結果。而合并連接配接和散清單連接配接隻進行一次循環周遊，相對來說效率較高。其中散清單連接配接可以采用多個等式做為條件而合并連接配接隻能采用單個等式作為條件。但是在有索引掃描的情況下嵌套循環連接配接效率則更高。當優化級别等于零時，連接配接隻能采用嵌套循環連接配接， 當優化級别大于等于 1 時，連接配接可以采用合并連接配接。當優化級别大于 5 時連接配接可以采用散清單連接配接。散清單連接配接要求 SORTHEAP 比較大，因為要為生成散清單準備空間。

在考慮 CPU 因素時還要考慮 CPUSPEED 這個參數，這個參數标明了 CPU 的運作速度，它會幫助優化器評估最好的通路計劃。一般來說這個參數設為 -1，優化器将自動計算 CPU 的速度。另外運用多分區的特性可以把一個資料庫分布到多台機器上，這樣可以充分利用多台機器的 CPU 的資源對應用程式的事務進行并行處理，進而提高資料庫的性能。

I/O 因素

關于 I/O 因素要考慮以下幾個方面：首先是磁盤的 I/O, 為了能夠最大化磁盤的 I/O 可以把資料，索引以及日志分别放在不同的硬碟上。因為在一個事務中資料和索引可能需要同時通路，而在事務送出時，資料和日志要同時寫入磁盤，而且有可能索引也要同步維護，是以将它們放在不同的硬碟上可以使它們的讀寫并行運作，進而不緻使磁盤成為瓶頸。同時選擇資料庫管理表空間 (DMS) 要比系統管理表空間 (SMS) 性能要好，因為讀寫 SMS 需要經過作業系統的 cache 再到緩沖池，而可以采用裸裝置的 DMS 則不需要。但是 DMS 相對 SMS 來說維護起來較麻煩。

其次要考慮的是日志檔案的大小，當資料庫在寫事務日志時當一個日志檔案寫滿後會轉向另外一個日志檔案，這種日志檔案的切換會造成作業系統上的開銷。是以應當盡量将日志檔案大小（LOGFILSIZ）設得大一些，這樣可以減少日志檔案切換的次數。但是日志檔案過大難免會造成一些空間的浪費。

同時也要考慮到隔離級别的因素，在 DB2 中隔離級别分成 4 級：可重複的讀，讀穩定性，遊标穩定性和未送出的讀。這四種級别逐個降低。越高的隔離級别越能保證資料完整性，但卻會降低并發性，是以應當綜合權衡後做出決定。隔離級别可以通過如下指令來改變：

CHANGE ISOLATION TO=CS|RR|RS|UR

在連接配接方面還要考慮到代理和連接配接的關系，這也會影響到資料庫的并發性，具體資訊可以參考資源部分。

最後要考慮的還是關于多分區的特性。在多分區資料庫中，一個請求首先傳到協調分區，然後由協調分區将請求細分成多個部分發送到其他分區，這樣資料可以在各個分區進行并行讀寫，實作 I/O 最大化。

性能優化相關工具

在 DB2 中有很多和性能優化相關的工具和指令，下面簡單地介紹幾種：

• SNAPSHOT : 這是 DB2 擷取資料庫資訊快照的一種方法。它能夠擷取在資料庫中關于緩沖池，鎖，排序以及 SQL 等等資訊。 DBA 可以通過擷取這些資訊來對資料庫中的各元件進行評估來分析問題的瓶頸。
• DB2PD : 這個指令是用來分析資料庫的目前狀态，它帶有很多參數。可以用來分析應用程式，代理，記憶體塊，緩沖池，日志及鎖狀态等資訊。
• RUNSTATS : 這個指令是用來收集資料庫中資料的最新統計資訊，并更新到系統表中。更新統計資訊将會促使優化器選擇更加符合實際的高效的通路計劃，進而提高工作效率。
• REORG : 這個指令用來重新整理資料庫中資料和索引的碎片，使其在實體上可以得以按一定規則排列，這樣可以加快檢索的速度。
• DB2DART : 這個指令是一個資料庫的分析和報告工具，它用來檢查表空間，索引以及資料庫結構的正确性，分析在性能問題上的一些原因。
• DB2SUPPORT : 這個指令用來收集 DB2 和作業系統的所有相關資訊并生成一個壓縮檔案，可傳送給優化人員進行分析。

還有一些 DB2 中其他的檔案可以用來分析性能問題，比如說診斷日志，追蹤檔案等。一些第三方的工具也可供參考，如“ tivoli monitor for db2 ”， QUEST 等等。

其他性能因素

• XML 的優化： 在 DB2 V9 以後引入了純 XML 的資料類型，這是一種層次型資料類型。這和傳統的關系型資料類型不一樣，在 V9 以前 DB2 存儲 XML 資料使用 CLOB 資料類型，應用程式在存取 XML 資料的時候必須先要解析 XML 再使用其資料。而在純 XML 類型中，可以直接讀取其中的元素，這樣性能會有較大的提高。另外針對純 XML 還有 XML 的索引，也會增大存取的性能。
• 作業系統： 資料庫存在于作業系統之上，作業系統的性能将直接影響到資料庫的運作效率，是以優化作業系統也是優化資料庫的一個重要過程。在作業系統級别上可以對記憶體進行優化，比如說對系統共享記憶體，信号量以及虛拟記憶體的設定等等都可以影響到資料庫的性能。同時在磁盤的分布上也會影響到資料庫 I/O 效率。
• 網絡： 網絡将會影響到資料庫的 I/O 性能，當資料通過網絡在用戶端和伺服器端進行傳送時，網絡上出現瓶頸會導緻資料庫 I/O 性能顯著下降。是以選擇優良的網絡裝置以及配置良好的網絡環境對資料庫性能相當重要。同時也要考慮到防火牆的因素，有時防火牆會阻擋來自某些 IP 的資料包。

DB2 性能問題分類與分析思路

DML 性能問題

DML(Data Manipulation Language) 包括了查詢，增加，删除和更新紀錄等操作。首先看一下查詢的性能問題，在查詢一張表或多張表的聯合查詢時有時反應時間會比較長，這使得使用者難以忍受。針對這種問題，可以通過下述方法來分析：

• 在查詢的連接配接或條件子句中的相關字段是否加了索引。 ( 關于 SQL 的優化可以參見 SQL 優化相關文章，本文不再贅述 ) 。
• 察看緩沖池的大小，緩沖池太小會造成很多資料不能讀到緩沖池而直接從硬碟上讀取，造成很大的瓶頸。另一方面關于緩沖池預取的設定，一般能将預取大小 (PREFETCHSIZE) 設定為區段大小與容器個數的積，這樣可以最大利用到預取的并行性。
• 在查詢中涉及到 order by 字句時，如果排序的字段沒有設定索引那麼排序将會用到記憶體中的排序堆 (sortheap) 。如果排序堆過小會造成排序溢出到硬碟上 (Overflowed) 造成性能衰退。
• 同時還要考慮到 RUNSTATS/REORG 因素。 RUNSTATS 指令可以更新表中的統計資訊。當表中的資料經過頻繁的增删改後其相應的統計資訊會發生變化，而優化器選擇執行計劃的時候是根據這種統計資訊來計算的，是以運作 RUNSTATS 此時顯得尤為重要。 REORG 可以整理資料存儲的實體結構，也能減少資料掃描的時間，提高查詢的性能。
• 從存儲方面應當注意的是選取裸裝置的 DMS 要比 SMS 性能要好，因為它少了一層檔案系統的緩沖而直接通路緩沖池。
• 學會使用 optimize for n rows 子句，它可以提高前面 n 條記錄的顯示速度。這樣可以使使用者能夠先快速檢視這 n 條記錄，然後再看其他紀錄。減少了使用者的等待時間。
• 物化查詢表 (MQT) 也是提高查詢性能的一種手段，它可以将經常用到的查詢結果集存儲到一張中間表中，在查詢時減少了資料檢索的時間。
• 在架構上采用 MPP 或 SMP 也是提高查詢或寫操作性能的手段。
• 針對複雜查詢時可以将資料庫配置參數 DFT_QUERYOPT( 預設查詢優化類 ) 的值設得高一些（7 或 9），針對簡單查詢可以将它設得低一些 (3 或 5)，因為設定越高優化器所作的分析就越深入，耗費在生成計劃上的時間就越多。
• 針對 C/S 結構的查詢可以将查詢語句寫在伺服器端生成存儲過程來減少資料的網絡傳輸以及用戶端的壓力。而經過編譯的存儲過程執行得更加高效。
• 還要考慮到隔離級别與鎖的因素，隔離級别越高越能保證資料的完整性，但同時會減弱并發性。這一點需要權衡需求而定。
• 網絡因素也不可忽視，将資料庫伺服器參數 RQRIOBLK 設為 65534 可以相應地提高網絡吞吐量。（預設值 32767）
• 最後需要考慮的是資料庫的結構，在某些情況下，在某些表中增加一些備援字段雖然犧牲了一些空間和維護成本，但是在查詢時可以減少很多連接配接操作，這樣可以大大提高查詢性能。就是用空間換取時間。

接下來看一下增删改的性能優化方法：

• 首先是索引因素，在做增删改時資料庫會對表中的索引做相應的修改。這會消耗一定的資源，是以在保證資料完整性的前提下可以先将索引删除，待到增删改結束後再重建這些索引。這也會節省一些時間。将索引和資料放在不同的硬碟上也可以增加寫操作的并行性。
• 其次要考慮日志因素，在資料寫操作的同時，資料庫系統也在維護着事務日志，是以應盡量減少日志維護的代價。将 auto commit 設為 false，可以減少送出的次數（同時也減少了寫日志的次數）。增大 LOGBUFSZ,LOGFILSZ 可以減少重新整理日志的次數以及日志檔案切換的次數。或者将表的屬性改為” ACTIVATE NOT LOGGED INITIALLY ” , 這樣可以屏蔽表的日志操作，以提高寫操作的性能，但是失去事務日志的表的資料很難修複，這一點需要權衡。
• 将日志和資料分别放在不同的硬碟上也可以增加寫操作的并行性。
• 在插入記錄時采用 APPEND MODE 可以消除 DB2 尋找表中間的空餘空間的時間而直接插到表尾，進而提高插入的性能。
• 關于并行性的因素，采用 MPP 模式可以使用并行處理的方式增加寫操作的性能。将容器分散在不同的硬碟上也可以增加寫操作的性能。
• 還要考慮到限制和觸發器的影響，在寫操作時應當盡量避免表中有限制和觸發器。在保證資料完整性的前提下可在頻繁大批量寫操作時先将限制或觸發器去除，完畢後重建。
• 和查詢一樣，寫操作同樣要考慮到隔離級别和鎖的因素（參見查詢優化部分）。
• 在 insert 語句中包括多行可以減少客戶機 - 伺服器通信次數，提高插入性能。如：insert into table1 values (1, ’ a ’ ),(2, ’ b ’ ),(3, ’ c ’ ) 。
• 還有一個需要考慮的因素是 DB2 V95 在 UNIX 上的采用線程模型，在作業系統中的開銷變小，使得寫操作性能要比之前的 DB2 的版本要好。

DB2 實用程式的性能優化

先來看一下如何提高備份操作的性能：

• 提高資料庫配置參數 UTIL_HEAP_SZ 的大小，這個記憶體區域用來為備份和恢複操作提供緩沖。
• 減少整庫備份，多采用表空間備份需要的表空間。
• 減少完全備份，多采用增量備份或 DELTA 備份。
• 增加備份指令中的 PARALLELISM 參數來增加備份的并行性（增加線程或程序）。
• 增加備份指令中的 BUFFER 參數值。
• 增加備份的目标目錄，最好能将多個目錄放在不同的硬碟上，這樣可以增加備份的并行程度。

再來看一下如何提高恢複操作的性能：

• 和備份操作一樣，需要增大資料庫配置參數 UTIL_HEAP_SZ 的大小。
• 增加恢複指令中的 BUFFERS 參數值。
• 增加恢複指令中的 PARALLELISM 參數來增加備份的并行性（增加線程或程序）。
• 容器分布于不同的硬碟上也可以使恢複操作加快（提高并行性）。
• 采用 SMP 模式來激活多代理來增加恢複操作的并行性。

提高導入操作（import）的性能 :

• import 操作類似 insert 操作，是以很多方法可以參見 insert 的調優步驟。
• 添加 compound=x 選項可使導入操作批量進行而減少了網絡的通信量。
• 增加 COMMITCOUNT 的值已減少 LOG 的 I/O 次數。
• 啟用緩沖區插入，對 db2uimpm 程式包使用 INSERT BUF 選項重新綁定到資料庫。在 import 以前執行指令: db2 bind db2uimpm.bnd insert buf

提高導出操作 (export) 的性能：

• Export 操作類似 select 操作，是以很多方法可以參見 select 的調優步驟。
• 将 export 操作導出的檔案放在與資料和日志不同的硬碟上以減少 I/O 的競争。

提高載入操作 (load) 的性能：load 操作中日志的寫操作比 import 要少，是以 load 的性能比 import 要好很多，下面還是看看如何更好地提高 load 的性能。

• 在多分區環境下，db2 load 會進行并行裝載，性能會大幅度提高。
• 添加 buffer 參數可以增加裝載過程中的緩存空間，提高性能。

并發連接配接時的性能考慮

一般來說在連接配接數較少情況下，db2 的性能會比較穩定。因為這時連接配接的應用所産生的請求比 db2 代理池中所能産生的協調代理少，這時基本上能夠滿足每一個請求都能夠被及時的協調代理所響應處理。 在連接配接集中器激活（MAX_CONNECTIONS > MAX_COORDAGENTS）的情況下，如果連接配接數超過了協調代理，這時連接配接所過來的請求就會進入隊列等候協調代理服務，并發的連接配接數提高了，但是某些連接配接的性能就會顯著下降。此時應當考慮激活分區間并行 (SMP) 或多分區（MPP）特性來增加 I/O 的并行性以及多個 CPU 的并行運算。

案例分析

查詢優化案例

接下來這裡從一個試驗來看一下 DML 操作過程中優化的詳細步驟和具體資料。首先看一個查詢優化的例子，下面是試驗中的建表語句：

CREATE TABLE MCLAIM.T1_DMS ( C11 VARCHAR (10) NOT NULL , C12 VARCHAR (15) NOT NULL , C13 VARCHAR (20) NOT NULL , CONSTRAINT C11_PK PRIMARY KEY ( C11) ) IN DMS_Space; CREATE TABLE MCLAIM.T2_DMS ( C21 VARCHAR (15) NOT NULL , C22 VARCHAR (25) NOT NULL , C23 VARCHAR (30) NOT NULL , CONSTRAINT C21_PK PRIMARY KEY ( C21) ) IN DMS_Space; CREATE TABLE MCLAIM.T3_DMS ( C31 VARCHAR (10) NOT NULL , C32 VARCHAR (25) NOT NULL , C33 VARCHAR (35) NOT NULL , CONSTRAINT C31_PK PRIMARY KEY ( C31) ) IN DMS_Space;

最初的環境沒有優化，表空間類型 SMS 表空間，查詢的表中沒有索引，sortheap 過小等等。在這種情況下執行下列查詢語句：

select C12 from TESTOPT.T1_SMS,%SCHEMA%.T2_SMS,%SCHEMA%.T3_SMS where substr(C12,1,10)=substr(C21,1,10) and C22=C32 order by C12 asc

在沒有優化的情況下得到的總的執行時間是 653 秒，而經過優化後得到總的執行時間是大概是 15 秒左右。在優化中采用了如下優化步驟：

1. 選擇 DMS 表空間。
2. 添加索引：

   CREATE UNIQUE INDEX INDEX_C12 on T1_DMS (C12 ASC); CREATE UNIQUE INDEX INDEX_C22 on T2_DMS (C22 ASC); CREATE UNIQUE INDEX INDEX_C32 on T2 _DMS (C32 ASC);

3. 增大 sortheap 的大小
4. 執行 runstats
5. 選擇适當的優化級别
6. 改進表結構，增加備援字段。以空間換時間：

   ALTER TABLE T1 ADD C12_Red VARCHAR(10); ALTER TABLE T2 ADD C21_Red VARCHAR(10); UPDATE T1 SET C12_Red=SUBSTR(C12,1,10); UPDATE T2 SET C21_Red=SUBSTR(C21,1,10);

   查詢語句變成：

   select C12 from TESTOPT.T1_DMS, TESTOPT.T2_DMS, TESTOPT.T3_DMS where C12_Red=C21_Red and C22=C32 order by C12 asc

圖 1. 查詢操作優化示意圖

從圖中可以看出選擇好的表空間類型 ( 資料庫管理表空間 ) 和添加索引會對性能有很大的改善作用。而添加備援字段對性能的改進作用最大。當然這會涉及表結構的變化，是需要在資料庫設計階段考慮的因素。同時代價是增加磁盤的占用空間。

寫入操作優化

接下來是一個寫操作的例子（插入）。下面是試驗的腳本：

CONNECT TO FFTEST; CREATE SCHEMA TESTOPT; DROP TABLE TESTOPT.T3; CREATE TABLE TESTOPT.T3 ( C31 VARCHAR (10) NOT NULL , C32 VARCHAR (15) NOT NULL , CONSTRAINT C31_A CHECK ( C31 LIKE 'A%' or C31 LIKE 'a%')); CREATE INDEX TESTOPT.INDEX_C31 on TESTOPT.T3 (C31 ASC); ALTER TABLE TESTOPT.T3 ADD CONSTRAINT C31_A CHECK (substr(C31,1,1)= ’ a ’ or substr(C31,1,1)= ’ A ’ ) ALTER TABLE TESTOPT.T3 APPEND OFF; CONNECT RESET;

最初的表沒有優化，含有索引，限制等因素，插入 4 萬條記錄大約花了 68 秒鐘，而最終優化後插入 4 萬條記錄隻需 6 秒鐘。如下是優化步驟：

1. 去除索引。
2. 去除限制。
3. 在 insert 語句中包括多行。
4. 采用 Append 模式
5. 屏蔽表的日志操作。
6. 采用并行寫操作。
7. 采用嚴格的隔離級别。

圖 2. 插入操作優化示意圖

從圖中可以看出減少索引和限制可以大幅度提高插入性能，而将多條插入語句合并成一行産生的效果更加明顯。

性能調優注意事項

• 為了得到高性能将緩沖池調得過大，導緻資料庫連不上。這對沒有經驗的使用者來說可能是個災難，這意味着資料庫可能要重建。最初我們曾經犯過這樣的錯誤。現在可以通過調節 DB2 注冊參數 DB2_OVERRIDE_BPF 來設定緩沖池的大小，進而能夠再次連接配接資料庫。當然最好将 STMM 激活，使記憶體能夠自動調整。
• 往往忽視 runstats 和 reorg 的作用，我們發現不止一個的性能問題，都是由于優化器選擇了錯誤的 access plan 導緻系統整體性能下降。而對外顯示的則不光是 SQL 執行慢，同時也能會表現出 I/O 瓶頸或系統響應時間長。這往往會誤導我們去分析其他地方。但究其根源，很多時間是由于優化器的錯誤。這些問題往往在重新執行 runstats 和 reorg 之後就解決了。是以這兩個指令也要特别注意。
• 在進行資料加載的時候往往忽略了索引因素，導緻性能加載性能下降。我們遇到過這樣的一個例子，一張表導入 1000 條記錄花了 5 分鐘，檢查了很多配置找不到原因，最後發現這張表上有 1 個主鍵，還有 4 個外鍵。将他們删除後重新導入隻花了幾秒鐘。是以在進行 load 或者是 insert 的時候盡量将主外鍵或相關索引删除，加載完成後重建相關索引。主外鍵盡量通過加載程式來保證它的資料完整性。這一點往往會被忽略，是以在加載資料前先檢查一下所有表的索引狀态及引用關系。
• 在修改 db2 參數的時候，一次最好修改一個參數，然後看看效果，在調節其他參數。否則一次多個參數，調好了也沒弄清楚是哪個參數起的作用。下次還得全部來一遍。還要注意，并非所有參數都是越大越好，有時可能會适得其反。
• 注意索引的試用，優化好的索引對查詢語句性能的提高往往會産生數十倍的性能改進。是以，調優前可以先察看一下相關語句的索引利用情況。這可以通過察看 SQL 語句和執行計劃，看一下已有索引是否被利用起來了或是否需要建立新的索引。這往往比 DB2 系統調優更重要。但切記考慮插入操作，索引也會降低插入的性能。這一點要綜合考慮。
• 由于 XML 資料可以跨頁存儲，在設計 XML 資料庫時要盡可能的使用較大的資料頁，這樣可以避免 XML 資料跨頁查詢，以提高查詢性能。
• 采用表分區：有這樣一個例子：客戶有一張表的資料量非常大，每天都會産生大約 30 萬條記錄，同時每天都會删除五天前的記錄，是以此表大概有 150 萬條記錄，現在客戶在每天的第一次查詢時要重新對表進行索引（因為晚上會産生很多資料，是以新增加的資料都沒有建索引），導緻響應非常慢！對于這種問題，後來采用了表分區，用 6 個分區表來分别裝載原來 6 天的資料。是以查詢和插入都隻涉及一張表，是以響應速度得到大幅度提高。
• 了解 CHNGPGS_THRESH 參數，是緩沖池寫日志的閥值。有一個例子，在建立索引時比較慢，經過檢查發現 CHNGPGS_THRESH 參數過大，造成每次寫日志的時候資料量過大，造成 I/O 瓶頸，适當減小這個參數值，可以增加寫日志的次數，但數減少每次寫日志的資料量，這對于大緩沖池裡的大表上建立索引時很有效的。
• 在導入資料時盡量采用 load, 少用 import, 我們做過統計，用 import 花費 10 分鐘的資料，用 load 大概隻需要 1 分鐘，這大大提高了工作效率。
• 注意 db2diag.log 的大小，當這個檔案很大的時候，資料庫的所有操作，包括停啟 db2 都會特别的慢，有時甚至挂起。是以要經常看看這個檔案的大小，過大時最好删掉，重新開機 db2 。當然 DIAGLEVEL 不要設得太高，除非為了診斷某個問題獲得更多資訊，一般預設的 3 足夠了。

複雜的應用環境中的性能優化 (DB2 Performance Expert)

現在的生産環境都是非常複雜的，性能問題涉及到了應用程式，應用伺服器，資料庫，網絡等各種因素。要從複雜的環境中迅速定位性能的瓶頸非常困難。下面介紹一個非常有用的工具可以幫助使用者解決這個難題。這個工具就是 IBM 的 DB2 Performance Expert 。運用 DB2 Performance Expert V3.2 可以很快的找到系統的性能瓶頸。如下圖所示：

圖 3. 系統響應時間分布圖

從這個截圖可以看出目前應用程式（灰色部分）和資料庫（黑色部分）占用了很大的比例，是系統瓶頸所在。而下圖則較長的描述了資料庫的一些狀态資訊。

圖 4. 資料庫重要名額資訊圖

從上圖可以看出，排序溢出很大 ( 到了 100%)，說明 sortheap 需要調整，緩沖池 IBMDEFAULTBP 的命中率很低（隻有 69.5%），說明緩沖池太小，需要調大。是以在分析系統性能問題是使用 DB2 Performance Expert 是一個不錯的選擇。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/15082138/viewspace-605271/，如需轉載，請注明出處，否則将追究法律責任。

轉載于:http://blog.itpub.net/15082138/viewspace-605271/