性能優(yōu)化概述

DB2 的性能優(yōu)化可以從三個方面分析：內(nèi)存，CPU 和 I/O 。DB2 性能優(yōu)化是一件較為復雜的綜合性的工作 , 需要對問題的根源作全方位的探索和思考。同時也需要較深厚的數(shù)據(jù)庫管理經(jīng)驗與優(yōu)化知識。這對于初學者來說可能有些勉為其難。但是在很多情況下，隨著 DB2 數(shù)據(jù)庫中的數(shù)據(jù)量的不斷增長或者用戶數(shù)的激增，數(shù)據(jù)庫系統(tǒng)的性能會顯著下降，而此時快速定位性能上的瓶頸則至關(guān)重要。下面簡要地介紹一下 DB2 的調(diào)優(yōu)的一些因素和工具，以及一些原理，使初學者對性能優(yōu)化能夠有一個大致的了解。

內(nèi)存因素

在內(nèi)存方面，主要是考慮緩沖池 (BUFFERPOOL) 的使用。緩沖池是一片用來緩沖從磁盤上讀取的數(shù)據(jù)和索引的內(nèi)存區(qū)域，這些數(shù)據(jù)和索引信息在緩沖池中進行運算后最終還要寫回磁盤。緩沖池的頁面大小有四種 (4K,8K,16K,32K)，分別對應四種不同頁面大小的表空間。緩沖池的大小決定了能夠從磁盤上緩沖數(shù)據(jù)的容量大小。當然緩沖池也不是越大越好，緩沖池過大可能會導致連接數(shù)據(jù)庫的時間過長，因為在連接數(shù)據(jù)庫時要為數(shù)據(jù)庫的緩沖池分配內(nèi)存空間?？梢酝ㄟ^計算緩沖池的命中率來評估緩沖池的使用效率：緩沖池命中率 =(1-(( 數(shù)據(jù)物理讀 + 索引物理讀 )/( 數(shù)據(jù)邏輯讀 + 索引邏輯讀 ))) *100%，緩沖池命中率越大說明緩沖池的使用效率高。緩沖池命中率太小說明緩沖池太小應當調(diào)大。其中的數(shù)據(jù)物理讀，索引物理讀以及數(shù)據(jù)邏輯讀和索引邏輯讀都可以從緩沖池的快照中獲取。

在內(nèi)存方面要考慮的另外幾個重要因素是排序堆 (SORTHEAP)，鎖列表 (LOCKLIST), 日志緩沖區(qū) (LOGBUFSZ) 。排序堆在查詢結(jié)果帶有排序選項而沒有相關(guān)索引對應時將會被使用，排序堆太小會產(chǎn)生排序溢出 (Overflowed), 那些在排序堆中裝不下的排序數(shù)據(jù)將會溢出到一個臨時表中，這會使性能下降。與 SORTHEAP 參數(shù)相關(guān)的是 SHEAPTHRES_SHR 和 SHEAPTHRES，SHEAPTHRES_SHR 限制了一個數(shù)據(jù)庫中共享排序的最大內(nèi)存，SHEAPTHRES 限制了私有排序的最大內(nèi)存。 LOCKLIST 指的是一個數(shù)據(jù)庫中用來存放鎖的內(nèi)存空間，當這個參數(shù)設得過小會導致在鎖用光這部分資源后導致鎖升級(即多個行鎖轉(zhuǎn)化為一個表鎖來釋放出更多的資源)。這會導致系統(tǒng)的并行性下降，很多應用連接出現(xiàn)掛起，使得系統(tǒng)的性能衰退。所以盡可能調(diào)大 LOCKLIST 參數(shù)，這里需要指出 LOCKLIST 指的并不是鎖的個數(shù)，而是以數(shù)據(jù)庫頁為單位的一片內(nèi)存區(qū)域(在 32 位系統(tǒng)中每個鎖需要 96 個字節(jié)，鎖上加鎖的話每個鎖則需 48 個字節(jié)。在 64 位系統(tǒng)中每個鎖需要 128 個字節(jié)，鎖上加鎖的話每個鎖則需 64 個字節(jié))。與 LOCKLIST 參數(shù)對應的是 MAXLOCKS 參數(shù)，MAXLOCKS 定義的是一個百分數(shù)，它指定了一個應用程序所能占用的最大的鎖空間占 LOCKLIST 的比例。日志緩沖區(qū) (LOGBUFSZ) 指的是日志在寫到磁盤以前用于緩沖的一片內(nèi)存空間，這樣可以減少寫日志帶來的過多的 I/O 。

從版本 9 以后 DB2 推出了一個新特性自調(diào)節(jié)內(nèi)存管理器 (STMM: Self Tuning Memory Manager), 這個特性使得很多內(nèi)存參數(shù)如前面所述的 SORTHEAP，LOCKLIST，LOGBUFSZ 等進行自動調(diào)節(jié)，當數(shù)據(jù)庫參數(shù) SELF_TUNING_MEM 設為 ON, 這些參數(shù)設為 AUTOMATIC 即可以進行自動調(diào)整。這樣可以節(jié)省很多人工調(diào)整的時間。

CPU 因素

關(guān)于 CPU 因素首先是考慮 DB2 優(yōu)化器 (OPTIMIZER) 對訪問計劃 (ACCESS PLAN) 的分析與優(yōu)化。一般來說，一條 SQL 在執(zhí)行時首先會被解析，然后進行語義分析，進而重寫 SQL, 優(yōu)化器會對重寫過的 SQL 進行基于成本的分析最終選擇最有效的訪問計劃。最終生成可執(zhí)行代碼(執(zhí)行計劃)來執(zhí)行這條語句。查詢訪問計劃的工具有很多，既有圖形化工具 Visual Explain，也有命令 db2exfmt 來格式化解釋表 (Explain tables) 中的數(shù)據(jù)生成 ACCESS PLAN 。還有命令 db2expln 查詢 ACCESS PLAN 。

在 DB2 里的優(yōu)化級別分為九級，缺省是第五級，級別越高優(yōu)化器分析得程度越深。這個級別有數(shù)據(jù)庫配置參數(shù) DFT_QUERYOPT 決定。并不是級別設得越高性能越好，因為對于一些較為簡單的 SQL 語句，如果優(yōu)化級別過高那么花在優(yōu)化 SQL 上的時間就會過長，而執(zhí)行時間相對來說很短，有些得不償失。在選擇訪問計劃時，索引掃描的效率往往會比表掃描要高，所以索引的優(yōu)化也是值得注意的。正確的建立索引會使查詢性能大幅度的提高。

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

在考慮 CPU 因素時還要考慮 CPUSPEED 這個參數(shù)，這個參數(shù)標明了 CPU 的運行速度，它會幫助優(yōu)化器評估最好的訪問計劃。一般來說這個參數(shù)設為 -1，優(yōu)化器將自動計算 CPU 的速度。另外運用多分區(qū)的特性可以把一個數(shù)據(jù)庫分布到多臺機器上，這樣可以充分利用多臺機器的 CPU 的資源對應用程序的事務進行并行處理，從而提高數(shù)據(jù)庫的性能。

I/O 因素

關(guān)于 I/O 因素要考慮以下幾個方面：首先是磁盤的 I/O, 為了能夠最大化磁盤的 I/O 可以把數(shù)據(jù)，索引以及日志分別放在不同的硬盤上。因為在一個事務中數(shù)據(jù)和索引可能需要同時訪問，而在事務提交時，數(shù)據(jù)和日志要同時寫入磁盤，而且有可能索引也要同步維護，所以將它們放在不同的硬盤上可以使它們的讀寫并行運行，從而不致使磁盤成為瓶頸。同時選擇數(shù)據(jù)庫管理表空間 (DMS) 要比系統(tǒng)管理表空間 (SMS) 性能要好，因為讀寫 SMS 需要經(jīng)過操作系統(tǒng)的 cache 再到緩沖池，而可以采用裸設備的 DMS 則不需要。但是 DMS 相對 SMS 來說維護起來較麻煩。

其次要考慮的是日志文件的大小，當數(shù)據(jù)庫在寫事務日志時當一個日志文件寫滿后會轉(zhuǎn)向另外一個日志文件，這種日志文件的切換會造成操作系統(tǒng)上的開銷。所以應當盡量將日志文件大小(LOGFILSIZ)設得大一些，這樣可以減少日志文件切換的次數(shù)。但是日志文件過大難免會造成一些空間的浪費。

同時也要考慮到隔離級別的因素，在 DB2 中隔離級別分成 4 級：可重復的讀，讀穩(wěn)定性，游標穩(wěn)定性和未提交的讀。這四種級別逐個降低。越高的隔離級別越能保證數(shù)據(jù)完整性，但卻會降低并發(fā)性，所以應當綜合權(quán)衡后做出決定。隔離級別可以通過如下命令來改變：

CHANGE ISOLATION TO=CS|RR|RS|UR

在連接方面還要考慮到代理和連接的關(guān)系，這也會影響到數(shù)據(jù)庫的并發(fā)性，具體信息可以參考資源部分。

最后要考慮的還是關(guān)于多分區(qū)的特性。在多分區(qū)數(shù)據(jù)庫中，一個請求首先傳到協(xié)調(diào)分區(qū)，然后由協(xié)調(diào)分區(qū)將請求細分成多個部分發(fā)送到其他分區(qū)，這樣數(shù)據(jù)可以在各個分區(qū)進行并行讀寫，實現(xiàn) I/O 最大化。

性能優(yōu)化相關(guān)工具

在 DB2 中有很多和性能優(yōu)化相關(guān)的工具和命令，下面簡單地介紹幾種：

SNAPSHOT: 這是 DB2 獲取數(shù)據(jù)庫信息快照的一種方法。它能夠獲取在數(shù)據(jù)庫中關(guān)于緩沖池，鎖，排序以及 SQL 等等信息。 DBA 可以通過獲取這些信息來對數(shù)據(jù)庫中的各組件進行評估來分析問題的瓶頸。

DB2PD?: 這個命令是用來分析數(shù)據(jù)庫的當前狀態(tài)，它帶有很多參數(shù)。可以用來分析應用程序，代理，內(nèi)存塊，緩沖池，日志及鎖狀態(tài)等信息。

RUNSTATS?: 這個命令是用來收集數(shù)據(jù)庫中數(shù)據(jù)的最新統(tǒng)計信息，并更新到系統(tǒng)表中。更新統(tǒng)計信息將會促使優(yōu)化器選擇更加符合實際的高效的訪問計劃，從而提高工作效率。

REORG?: 這個命令用來重新整理數(shù)據(jù)庫中數(shù)據(jù)和索引的碎片，使其在物理上可以得以按一定規(guī)則排列，這樣可以加快檢索的速度。

DB2DART?: 這個命令是一個數(shù)據(jù)庫的分析和報告工具，它用來檢查表空間，索引以及數(shù)據(jù)庫結(jié)構(gòu)的正確性，分析在性能問題上的一些原因。

DB2SUPPORT?: 這個命令用來收集 DB2 和操作系統(tǒng)的所有相關(guān)信息并生成一個壓縮文件，可傳送給優(yōu)化人員進行分析。

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

其他性能因素

XML 的優(yōu)化：?在 DB2 V9 以后引入了純 XML 的數(shù)據(jù)類型，這是一種層次型數(shù)據(jù)類型。這和傳統(tǒng)的關(guān)系型數(shù)據(jù)類型不一樣，在 V9 以前 DB2 存儲 XML 數(shù)據(jù)使用 CLOB 數(shù)據(jù)類型，應用程序在存取 XML 數(shù)據(jù)的時候必須先要解析 XML 再使用其數(shù)據(jù)。而在純 XML 類型中，可以直接讀取其中的元素，這樣性能會有較大的提高。另外針對純 XML 還有 XML 的索引，也會增大存取的性能。

操作系統(tǒng)：?數(shù)據(jù)庫存在于操作系統(tǒng)之上，操作系統(tǒng)的性能將直接影響到數(shù)據(jù)庫的運行效率，因此優(yōu)化操作系統(tǒng)也是優(yōu)化數(shù)據(jù)庫的一個重要過程。在操作系統(tǒng)級別上可以對內(nèi)存進行優(yōu)化，比如說對系統(tǒng)共享內(nèi)存，信號量以及虛擬內(nèi)存的設置等等都可以影響到數(shù)據(jù)庫的性能。同時在磁盤的分布上也會影響到數(shù)據(jù)庫 I/O 效率。

網(wǎng)絡：?網(wǎng)絡將會影響到數(shù)據(jù)庫的 I/O 性能，當數(shù)據(jù)通過網(wǎng)絡在客戶端和服務器端進行傳送時，網(wǎng)絡上出現(xiàn)瓶頸會導致數(shù)據(jù)庫 I/O 性能顯著下降。所以選擇優(yōu)良的網(wǎng)絡設備以及配置良好的網(wǎng)絡環(huán)境對數(shù)據(jù)庫性能相當重要。同時也要考慮到防火墻的因素，有時防火墻會阻擋來自某些 IP 的數(shù)據(jù)包。

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

DML 性能問題

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

在查詢的連接或條件子句中的相關(guān)字段是否加了索引。 ( 關(guān)于 SQL 的優(yōu)化可以參見 SQL 優(yōu)化相關(guān)文章，本文不再贅述 ) 。

察看緩沖池的大小，緩沖池太小會造成很多數(shù)據(jù)不能讀到緩沖池而直接從硬盤上讀取，造成很大的瓶頸。另一方面關(guān)于緩沖池預取的設置，一般能將預取大小 (PREFETCHSIZE) 設定為區(qū)段大小與容器個數(shù)的積，這樣可以最大利用到預取的并行性。

在查詢中涉及到 order by 字句時，如果排序的字段沒有設置索引那么排序?qū)玫絻?nèi)存中的排序堆 (sortheap) 。如果排序堆過小會造成排序溢出到硬盤上 (Overflowed) 造成性能衰退。

同時還要考慮到 RUNSTATS/REORG 因素。 RUNSTATS 命令可以更新表中的統(tǒng)計信息。當表中的數(shù)據(jù)經(jīng)過頻繁的增刪改后其相應的統(tǒng)計信息會發(fā)生變化，而優(yōu)化器選擇執(zhí)行計劃的時候是根據(jù)這種統(tǒng)計信息來計算的，所以運行 RUNSTATS 此時顯得尤為重要。 REORG 可以整理數(shù)據(jù)存儲的物理結(jié)構(gòu)，也能減少數(shù)據(jù)掃描的時間，提高查詢的性能。

從存儲方面應當注意的是選取裸設備的 DMS 要比 SMS 性能要好，因為它少了一層文件系統(tǒng)的緩沖而直接訪問緩沖池。

學會使用 optimize for n rows 子句，它可以提高前面 n 條記錄的顯示速度。這樣可以使用戶能夠先快速查看這 n 條記錄，然后再看其他紀錄。減少了用戶的等待時間。

物化查詢表 (MQT) 也是提高查詢性能的一種手段，它可以將經(jīng)常用到的查詢結(jié)果集存儲到一張中間表中，在查詢時減少了數(shù)據(jù)檢索的時間。

在架構(gòu)上采用 MPP 或 SMP 也是提高查詢或?qū)懖僮餍阅艿氖侄巍?/p>

針對復雜查詢時可以將數(shù)據(jù)庫配置參數(shù) DFT_QUERYOPT( 缺省查詢優(yōu)化類 ) 的值設得高一些(7 或 9)，針對簡單查詢可以將它設得低一些 (3 或 5)，因為設置越高優(yōu)化器所作的分析就越深入，耗費在生成計劃上的時間就越多。

針對 C/S 結(jié)構(gòu)的查詢可以將查詢語句寫在服務器端生成存儲過程來減少數(shù)據(jù)的網(wǎng)絡傳輸以及客戶端的壓力。而經(jīng)過編譯的存儲過程執(zhí)行得更加高效。

還要考慮到隔離級別與鎖的因素，隔離級別越高越能保證數(shù)據(jù)的完整性，但同時會減弱并發(fā)性。這一點需要權(quán)衡需求而定。

網(wǎng)絡因素也不可忽視，將數(shù)據(jù)庫服務器參數(shù) RQRIOBLK 設為 65534 可以相應地提高網(wǎng)絡吞吐量。(缺省值 32767)

最后需要考慮的是數(shù)據(jù)庫的結(jié)構(gòu)，在某些情況下，在某些表中增加一些冗余字段雖然犧牲了一些空間和維護成本，但是在查詢時可以減少很多連接操作，這樣可以大大提高查詢性能。就是用空間換取時間。

接下來看一下增刪改的性能優(yōu)化方法：

首先是索引因素，在做增刪改時數(shù)據(jù)庫會對表中的索引做相應的修改。這會消耗一定的資源，所以在保證數(shù)據(jù)完整性的前提下可以先將索引刪除，待到增刪改結(jié)束后再重建這些索引。這也會節(jié)省一些時間。將索引和數(shù)據(jù)放在不同的硬盤上也可以增加寫操作的并行性。

其次要考慮日志因素，在數(shù)據(jù)寫操作的同時，數(shù)據(jù)庫系統(tǒng)也在維護著事務日志，所以應盡量減少日志維護的代價。將 auto commit 設為 false，可以減少提交的次數(shù)(同時也減少了寫日志的次數(shù))。增大 LOGBUFSZ,LOGFILSZ 可以減少刷新日志的次數(shù)以及日志文件切換的次數(shù)?；蛘邔⒈淼膶傩愿臑椤?ACTIVATE NOT LOGGED INITIALLY ” , 這樣可以屏蔽表的日志操作，以提高寫操作的性能，但是失去事務日志的表的數(shù)據(jù)很難修復，這一點需要權(quán)衡。

將日志和數(shù)據(jù)分別放在不同的硬盤上也可以增加寫操作的并行性。

在插入記錄時采用 APPEND MODE 可以消除 DB2 尋找表中間的空余空間的時間而直接插到表尾，從而提高插入的性能。

關(guān)于并行性的因素，采用 MPP 模式可以使用并行處理的方式增加寫操作的性能。將容器分散在不同的硬盤上也可以增加寫操作的性能。

還要考慮到約束和觸發(fā)器的影響，在寫操作時應當盡量避免表中有約束和觸發(fā)器。在保證數(shù)據(jù)完整性的前提下可在頻繁大批量寫操作時先將約束或觸發(fā)器去除，完畢后重建。

和查詢一樣，寫操作同樣要考慮到隔離級別和鎖的因素(參見查詢優(yōu)化部分)。

在 insert 語句中包括多行可以減少客戶機 - 服務器通信次數(shù)，提高插入性能。如：insert into table1 values (1, ’ a ’ ),(2, ’ b ’ ),(3, ’ c ’ ) 。

還有一個需要考慮的因素是 DB2 V95 在 UNIX 上的采用線程模型，在操作系統(tǒng)中的開銷變小，使得寫操作性能要比之前的 DB2 的版本要好。

DB2 實用程序的性能優(yōu)化

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

提高數(shù)據(jù)庫配置參數(shù) UTIL_HEAP_SZ 的大小，這個內(nèi)存區(qū)域用來為備份和恢復操作提供緩沖。

減少整庫備份，多采用表空間備份需要的表空間。

減少完全備份，多采用增量備份或 DELTA 備份。

增加備份命令中的 PARALLELISM 參數(shù)來增加備份的并行性(增加線程或進程)。

增加備份命令中的 BUFFER 參數(shù)值。

增加備份的目標目錄，最好能將多個目錄放在不同的硬盤上，這樣可以增加備份的并行程度。

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

和備份操作一樣，需要增大數(shù)據(jù)庫配置參數(shù) UTIL_HEAP_SZ 的大小。

增加恢復命令中的 BUFFERS 參數(shù)值。

增加恢復命令中的 PARALLELISM 參數(shù)來增加備份的并行性(增加線程或進程)。

容器分布于不同的硬盤上也可以使恢復操作加快(提高并行性)。

采用 SMP 模式來激活多代理來增加恢復操作的并行性。

提高導入操作(import)的性能 :

import 操作類似 insert 操作，因此很多方法可以參見 insert 的調(diào)優(yōu)步驟。

添加 compound=x 選項可使導入操作批量進行而減少了網(wǎng)絡的通信量。

增加 COMMITCOUNT 的值已減少 LOG 的 I/O 次數(shù)。

啟用緩沖區(qū)插入，對 db2uimpm 程序包使用 INSERT BUF 選項重新綁定到數(shù)據(jù)庫。在 import 以前執(zhí)行命令: db2 bind db2uimpm.bnd insert buf

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

Export 操作類似 select 操作，因此很多方法可以參見 select 的調(diào)優(yōu)步驟。

將 export 操作導出的文件放在與數(shù)據(jù)和日志不同的硬盤上以減少 I/O 的競爭。

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

在多分區(qū)環(huán)境下，db2 load 會進行并行裝載，性能會大幅度提高。

添加 buffer 參數(shù)可以增加裝載過程中的緩存空間，提高性能。

并發(fā)連接時的性能考慮

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

案例分析

查詢優(yōu)化案例

接下來這里從一個試驗來看一下 DML 操作過程中優(yōu)化的詳細步驟和具體數(shù)據(jù)。首先看一個查詢優(yōu)化的例子，下面是試驗中的建表語句：

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;

最初的環(huán)境沒有優(yōu)化，表空間類型 SMS 表空間，查詢的表中沒有索引，sortheap 過小等等。在這種情況下執(zhí)行下列查詢語句：

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

在沒有優(yōu)化的情況下得到的總的執(zhí)行時間是 653 秒，而經(jīng)過優(yōu)化后得到總的執(zhí)行時間是大概是 15 秒左右。在優(yōu)化中采用了如下優(yōu)化步驟：

選擇 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 的大小

執(zhí)行 runstats

選擇適當?shù)膬?yōu)化級別

改進表結(jié)構(gòu)，增加冗余字段。以空間換時間：

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. 查詢操作優(yōu)化示意圖

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

寫入操作優(yōu)化

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

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;

最初的表沒有優(yōu)化，含有索引，約束等因素，插入 4 萬條記錄大約花了 68 秒鐘，而最終優(yōu)化后插入 4 萬條記錄只需 6 秒鐘。如下是優(yōu)化步驟：

去除索引。

去除約束。

在 insert 語句中包括多行。

采用 Append 模式

屏蔽表的日志操作。

采用并行寫操作。

采用嚴格的隔離級別。

圖 2. 插入操作優(yōu)化示意圖

從圖中可以看出減少索引和約束可以大幅度提高插入性能，而將多條插入語句合并成一行產(chǎn)生的效果更加明顯。

性能調(diào)優(yōu)注意事項

為了得到高性能將緩沖池調(diào)得過大，導致數(shù)據(jù)庫連不上。這對沒有經(jīng)驗的用戶來說可能是個災難，這意味著數(shù)據(jù)庫可能要重建。最初我們曾經(jīng)犯過這樣的錯誤。現(xiàn)在可以通過調(diào)節(jié) DB2 注冊參數(shù) DB2_OVERRIDE_BPF 來設置緩沖池的大小，從而能夠再次連接數(shù)據(jù)庫。當然最好將 STMM 激活，使內(nèi)存能夠自動調(diào)整。

往往忽視 runstats 和 reorg 的作用，我們發(fā)現(xiàn)不止一個的性能問題，都是由于優(yōu)化器選擇了錯誤的 access plan 導致系統(tǒng)整體性能下降。而對外顯示的則不光是 SQL 執(zhí)行慢，同時也能會表現(xiàn)出 I/O 瓶頸或系統(tǒng)響應時間長。這往往會誤導我們?nèi)シ治銎渌胤?。但究其根?#xff0c;很多時間是由于優(yōu)化器的錯誤。這些問題往往在重新執(zhí)行 runstats 和 reorg 之后就解決了。所以這兩個命令也要特別注意。

在進行數(shù)據(jù)加載的時候往往忽略了索引因素，導致性能加載性能下降。我們遇到過這樣的一個例子，一張表導入 1000 條記錄花了 5 分鐘，檢查了很多配置找不到原因，最后發(fā)現(xiàn)這張表上有 1 個主鍵，還有 4 個外鍵。將他們刪除后重新導入只花了幾秒鐘。所以在進行 load 或者是 insert 的時候盡量將主外鍵或相關(guān)索引刪除，加載完成后重建相關(guān)索引。主外鍵盡量通過加載程序來保證它的數(shù)據(jù)完整性。這一點往往會被忽略，所以在加載數(shù)據(jù)前先檢查一下所有表的索引狀態(tài)及引用關(guān)系。

在修改 db2 參數(shù)的時候，一次最好修改一個參數(shù)，然后看看效果，在調(diào)節(jié)其他參數(shù)。否則一次多個參數(shù)，調(diào)好了也沒弄清楚是哪個參數(shù)起的作用。下次還得全部來一遍。還要注意，并非所有參數(shù)都是越大越好，有時可能會適得其反。

注意索引的試用，優(yōu)化好的索引對查詢語句性能的提高往往會產(chǎn)生數(shù)十倍的性能改進。所以，調(diào)優(yōu)前可以先察看一下相關(guān)語句的索引利用情況。這可以通過察看 SQL 語句和執(zhí)行計劃，看一下已有索引是否被利用起來了或是否需要建立新的索引。這往往比 DB2 系統(tǒng)調(diào)優(yōu)更重要。但切記考慮插入操作，索引也會降低插入的性能。這一點要綜合考慮。

由于 XML 數(shù)據(jù)可以跨頁存儲，在設計 XML 數(shù)據(jù)庫時要盡可能的使用較大的數(shù)據(jù)頁，這樣可以避免 XML 數(shù)據(jù)跨頁查詢，以提高查詢性能。

采用表分區(qū)：有這樣一個例子：客戶有一張表的數(shù)據(jù)量非常大，每天都會產(chǎn)生大約 30 萬條記錄，同時每天都會刪除五天前的記錄，所以此表大概有 150 萬條記錄，現(xiàn)在客戶在每天的第一次查詢時要重新對表進行索引(因為晚上會產(chǎn)生很多數(shù)據(jù)，所以新增加的數(shù)據(jù)都沒有建索引)，導致響應非常慢！對于這種問題，后來采用了表分區(qū)，用 6 個分區(qū)表來分別裝載原來 6 天的數(shù)據(jù)。所以查詢和插入都只涉及一張表，所以響應速度得到大幅度提高。

了解 CHNGPGS_THRESH 參數(shù)，是緩沖池寫日志的閥值。有一個例子，在創(chuàng)建索引時比較慢，經(jīng)過檢查發(fā)現(xiàn) CHNGPGS_THRESH 參數(shù)過大，造成每次寫日志的時候數(shù)據(jù)量過大，造成 I/O 瓶頸，適當減小這個參數(shù)值，可以增加寫日志的次數(shù)，但數(shù)減少每次寫日志的數(shù)據(jù)量，這對于大緩沖池里的大表上創(chuàng)建索引時很有效的。

在導入數(shù)據(jù)時盡量采用 load, 少用 import, 我們做過統(tǒng)計，用 import 花費 10 分鐘的數(shù)據(jù)，用 load 大概只需要 1 分鐘，這大大提高了工作效率。

注意 db2diag.log 的大小，當這個文件很大的時候，數(shù)據(jù)庫的所有操作，包括停啟 db2 都會特別的慢，有時甚至掛起。所以要經(jīng)?？纯催@個文件的大小，過大時最好刪掉，重啟 db2 。當然 DIAGLEVEL 不要設得太高，除非為了診斷某個問題獲得更多信息，一般默認的 3 足夠了。

復雜的應用環(huán)境中的性能優(yōu)化 (DB2 Performance Expert)

現(xiàn)在的生產(chǎn)環(huán)境都是非常復雜的，性能問題涉及到了應用程序，應用服務器，數(shù)據(jù)庫，網(wǎng)絡等各種因素。要從復雜的環(huán)境中迅速定位性能的瓶頸非常困難。下面介紹一個非常有用的工具可以幫助用戶解決這個難題。這個工具就是 IBM 的 DB2 Performance Expert 。運用 DB2 Performance Expert V3.2 可以很快的找到系統(tǒng)的性能瓶頸。如下圖所示：

圖 3. 系統(tǒng)響應時間分布圖

從這個截圖可以看出目前應用程序(灰色部分)和數(shù)據(jù)庫(黑色部分)占用了很大的比例，是系統(tǒng)瓶頸所在。而下圖則詳細描述了數(shù)據(jù)庫的一些狀態(tài)信息。

圖 4. 數(shù)據(jù)庫重要指標信息圖

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的db2嵌套查询效率_db2性能优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。