【51CTO綜述】在上一篇文章中我們總整體上看了DB2性能優化的幾大因素，這次我們來關注一下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 的版本要好。