性能優化概述
DB2 的性能優化可以從三個方面分析：內存，CPU 和 I/O 。DB2 性能優化是一件較為復雜的綜合性的工作 , 需要對問題的根源作全方位的探索和思考。同時也需要較深厚的數據庫管理經驗與優化知識。這對於初學者來說可能有些勉為其難。但是在很多情況下，隨着 DB2 數據庫中的數據量的不斷增長或者用戶數的激增，數據庫系統的性能會顯著下降，而此時快速定位性能上的瓶頸則至關重要。下面簡要地介紹一下 DB2 的調優的一些因素和工具，以及一些原理，使初學者對性能優化能夠有一個大致的了解。
在內存方面，主要是考慮緩沖池 (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 因素首先是考慮 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 可以把數據，索引以及日志分別放在不同的硬盤上。因為在一個事務中數據和索引可能需要同時訪問，而在事務提交時，數據和日志要同時寫入磁盤，而且有可能索引也要同步維護，所以將它們放在不同的硬盤上可以使它們的讀寫並行運行，從而不致使磁盤成為瓶頸。同時選擇數據庫管理表空間 (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 的數據包。
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 的版本要好。
先來看一下如何提高備份操作的性能：
- 提高數據庫配置參數 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 秒左右。在優化中采用了如下優化步驟：
- 選擇 DMS 表空間。
- 添加索引：
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);
- 增大 sortheap 的大小
- 執行 runstats
- 選擇適當的優化級別
- 改進表結構，增加冗余字段。以空間換時間：
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
從圖中可以看出選擇好的表空間類型 ( 數據庫管理表空間 ) 和添加索引會對性能有很大的改善作用。而添加冗余字段對性能的改進作用最大。當然這會涉及表結構的變化，是需要在數據庫設計階段考慮的因素。同時代價是增加磁盤的占用空間。
接下來是一個寫操作的例子（插入）。下面是試驗的腳本：
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 秒鍾。如下是優化步驟：
- 去除索引。
- 去除約束。
- 在 insert 語句中包括多行。
- 采用 Append 模式
- 屏蔽表的日志操作。
- 采用並行寫操作。
- 采用嚴格的隔離級別。
從圖中可以看出減少索引和約束可以大幅度提高插入性能，而將多條插入語句合並成一行產生的效果更加明顯。
- 為了得到高性能將緩沖池調得過大，導致數據庫連不上。這對沒有經驗的用戶來說可能是個災難，這意味着數據庫可能要重建。最初我們曾經犯過這樣的錯誤。現在可以通過調節 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 可以很快的找到系統的性能瓶頸。如下圖所示：
從這個截圖可以看出目前應用程序（灰色部分）和數據庫（黑色部分）占用了很大的比例，是系統瓶頸所在。而下圖則詳細描述了數據庫的一些狀態信息。
從上圖可以看出，排序溢出很大 ( 到了 100%)，說明 sortheap 需要調整，緩沖池 IBMDEFAULTBP 的命中率很低（只有 69.5%），說明緩沖池太小，需要調大。所以在分析系統性能問題是使用 DB2 Performance Expert 是一個不錯的選擇。