1、1 DB2性能問題的表現應用系統（0A）上的表現：一般是登錄、首頁、待辦列表等數據量比較大的模塊，響應 時間長，耗時數秒到數十秒都有可能。有時候是用戶訪問高峰期慢，下班時間又比較正常。操作系統上的表現：一般是中間件服務器（WAS）系統正常，CPU和10占用不會持續超過50%，系統運行進程不會有持續的等待。數據庫服務器則非常繁忙，CPU占用持續在50%以上，往往會達到持續 90%左右，10占用可能不高。從系統層面判斷，性能瓶頸出在數據 庫上。2調優的基本思路DB2的性能和操作系統、鎖、緩沖池、索引等參數，以及SQL的寫法都有很大關系，受限于個人認識，這里主要介紹緩沖池和索引的調優方法。緩沖池的調

2、整比較簡單，一般可以先調整緩沖池，若效果不明顯，則再調整索引和SQL。3緩沖池調優緩沖池是內存中的一塊區域，DB2會將用到數據放到緩沖池中提高性能。緩沖池太小，每次查詢仍然要到磁盤中操作，達不到緩沖的效果。緩沖池太大，超出操作系統管理的限制，會導致數據庫無法連接的錯誤。緩沖池是通過表空間與數據表發生聯系的，數據表存放在指定的表空間中，每個表空間又有指定的緩沖池。因為每張數據表存儲的數據量都不同，一般根據每條記錄存放的最大數據量，我們會為數據表分別指定4k-32k不同的表空間來存放，以達到優化存儲和性能的目的，緩沖池也是類似。這個一般在創建數據庫時就會分配好了。在6門ix下，可以使用下面的命令查

3、看緩沖池相關信息：切換到db2inst1賬號su -db2i nst1連接到pzbdw數據庫db2 connect to pzbdw: ; 查看緩沖池定義1 db2 "select BPNAME,NPAGES,PAGESIZE from ": :l_查看表空間的定義，包含表空間名稱(TableSpaceName)、使用的緩沖池名稱(BufferpoolName),表空間的頁大小(TBSPageSize),緩沖池的數量(BufferpoolPages),緩沖池的頁大小數據(BufferpoolSize)信息。 db2 "select TableSpaceName,

4、BufferpoolName, TBSPageSize, BufferpoolPages,:;F1jj:BufferpoolSize from b, s where ="|moreii查看mv_workitem 表所在表空間和緩沖池信息，一般"MV_ ”開頭的表使用的緩沖池是重點關注對象：db2 "select TABSCHEMA TableSchemaName, TABNAME TableName, TableSpaceName,II1Ii BufferpoolName, BufferpoolPages, BufferpoolSize from t , b, s

5、 where;tabname='MV WORKITEM' and = and ="i_ _ _ _ _開啟緩沖池監控器：db2 update mon itor switches using bufferpool on在應用系統重現問題后，檢查緩沖池的快照：j db2 get sn apshot for bufferpools on pzbdw|grep -i buffer|more檢查相關緩沖池快照，需要重點關注的data和index的邏輯/物理讀寫數據，一般來說,在緩沖池足夠的情況下，physical reads值趨近于0,而logical reads值則很大。下面

6、是紅塔集團OA的32k緩沖池，在正常時的一個快照。Bufferpool Sn apshotBufferpool name= BF32Buffer pool data logical reads= 493907Buffer pool data physical reads= 78Buffer pool temporary data logical reads= 129662Buffer pool temporary data physical reads= 0Buffer pool data writes= 1Buffer pool index logical reads= 10302Buffe

7、r pool in dex physical reads= 122Buffer pool temporary in dex logical reads= 0Buffer pool temporary in dex physical reads = 0Total buffer pool read time (millisec on ds) = 671Total buffer pool write time (millisec on ds)= 15Buffer pool in dex writes= 58No victim buffers available= 635Tablespaces usi

8、ng bufferpool= 2Alter bufferpool in formati on:如果發現物理和邏輯讀的值相差不大，則使用下面的命令調整緩沖池大小，一般可以每次增加2000左右。db2 ALTER BUFFERPOOL BF32 size 18000緩沖池的調整是立即生效的，不需要重啟數據庫。需要注意的是，緩沖池的大小受物理 內存和操作系統限制， 一般32位操作系統下，總的緩沖池大小不能超過1G。如果在這個限制下，不能滿足所有緩沖池都達到物理讀趨近于0,則考慮盡可能保證用戶體驗影響較大的(MV、UM等開頭的表使用的)緩沖池大小。理論上64位操作系統可以管理更大的內存空間， 因此可以

9、獲得更好的性能。如下所示緩沖池，總大小為1x4+4x4+3x8+1x32=226MBPNAMENPAGESPAGESIZE1:1IBMDEFAULTBP110001:140961BF41400040961BF8:3000:8192:BF16:250016384:BF322500327681PZBDW321000132768由于緩沖池的監控器收集的是自啟用以后的數據，為獲得調整后的準確情況，應關閉后重新打開，再次收集快照信息。db2 update mon itor switches using bufferpool offdb2 update mon itor switches using bu

10、fferpool ondb2 get sn apshot for bufferpools on pzbdw|grep -i buffer|more重復以上步驟，獲得比較合理的緩沖池設置。4索引調優索引的調優，首先應該檢查0A默認的索引是否已經創建成功， 如果系統已經運行了較 長的一段時間，可以對所有的索引進行一次 run stat，保證索引的有效性，如果還是沒有效果， 就需要找到有嚴重性能問題的 SQL語句進行有針對性的調優。對所有表進行run stat的命令：db2 -v reorgchk update statistics on table all4.1收集DB2運行時數據：DB使用事件監

11、視器來收集運行時的數據，示例數據庫名為pzbdw， rkmon是該示例所使用的事件監視器的名稱，可以用其它任何名稱來替代它。示例中的命令是在linux上測試的，其他操作系統可能要做一些相應的調整。1. 切換到db2inst1用戶，保證db2inst1用戶對/tmp目錄具有寫的權限，且具有500M以上剩余磁盤空間。啟動監控器，創建一個名為rkmon的sql語句監控器，并啟動之。su - db2 inst1db2 connect to pzbdwdb2 "update mon itor switches using stateme nt on"db2 "create

12、eve nt mon itor rkmon for stateme nts write to file '/tmp'"db2 "set event mon itor rkm on state=1"2. 進入應用系統執行相應的操作，重現系統問題（最好多做幾次或配合壓力測試）。在/tmp目錄下，應該可以看到一組擴展名為“.evt ”的文件，這些文件就是您的事件監視器文件。然后關閉監控，否則監控文件可能很快會將系統存儲撐爆。db2 "set event mon itor rkm on state=0"3. 從事件監視文件生成詳細的SQ

13、L報告，在生成的文件中，可以看到這段時間執行的所有sql語句，消耗的時間等詳細信息。db2evm on -path /tmp > /tmp/4. 如果要重新生成新的報告，需要先關閉監視器，清理監視文件，再重建，否則會和前面的事件文件混在一起不便分析。停止監控并刪除日志：db2 "drop event mon itor rkm on"rm -rf /tmp/*.evt重建監控器：db2 "create eve nt mon itor rkmon for stateme nts write to file '/tmp'"db2 &quo

14、t;set event mon itor rkm on state=1"所有任務完成后應停止全局的監控器$ db2 "update mon itor switches using stateme nt off"4.2分析數據，收集性能影響最大的SQL語句附件提供的db2trace工具，可以分析文件，并將分析結果導入數據庫DB2TRACE表中,便于查詢分析。附帶源代碼，可能某些版本的DB2輸出格式不完全一致，可以進行相應調整。先修改classes目錄下的文件，修改數據庫連接參數，文件路徑等信息。然后在命令行 下進入db2trace目錄，運行bat文件，*unix環境

15、下可能需要先賦予命令執行權限:chmod 777: ;在具有java環境的條件下，這個工具在服務器和客戶端上都可以運行。由于文件往往比較大，在遠程調優的環境下，將工具直接上傳到服務器運行比較方便。AIX操作系統自帶java環境，linux也可以使用 WAS自帶的jdk。Linux環境下JAVA環境的配置請自行google。根據sqltrace文件大小不同，此命令運行可能需要較長時間，控制臺沒有輸出，可以到數據庫中查看db2trace表記錄的變化，此命令每次運行都會先清空db2trace表再插入。分析完成后，就可以直接在數據庫中查詢得到性能影響較大的sql語句了。可以使用下面的四個來查詢獲得。

16、如果查詢出錯，請檢查db2trace表的schema是否正確。其中最耗CPU的SQL語句對于解決問題往往是最有價值的：最耗CPU的SQL語句i db2 "select sqltxt ,usrcpu from db2trace where operation not in ('Static Commit','StaticI1jji Rollback', 'Prepare', 'Open', 'Describe', 'Compile') order by usrcpu desc fetch f

17、irst 10 rows only"執行時間最長的SQL語句db2 "select sqltxt, exectime 'ExecutionTime(sec)'from db2trace where operation not inii:('Static Commit', 'Static Rollback', 'Prepare', 'Open', 'Describe', 'Compile') order by decimalIII1ii (exectime) des

18、c fetch first 10 rows only" -II執行次數最多的SQL語句db2 "select distinct(sqltxt),count(*) Count from db2trace where operation not in ('StaticiICommit', 'Static Rollback','Prepare', 'Open', 'Describe', 'Compile') group by sqltxt order byI1i I:count(*)

19、desc fetch first 10 rows only"!排序時間最長的SQL語句db2 "select sqltxt ,totsorttime ' TotalSortTime(ms)' from db2trace where operation not in ;('Static Commit', 'Static Rollback', 'Prepare', 'Open', 'Describe', 'Compile') order byI 1II Idecima

20、l(totsorttime) desc fetch first 10 rows only"I收集整理上面得到的SQL語句，并將里面的替換為實際參數，放到DB2客戶端中執行幾次，驗證這些 SQL的查詢時間確實較長(一般的查詢時間在1s以上就很慢了)。4.3使用索引顧問程序獲得建議的索引收集到有性能問題的 SQL后，可以根據經驗調整索引，也可以使用DB2的顧問程序獲得建議的索引。將所有收集的語句放在文件中，并將下面這行插入到該文件中， 這樣可以更改工作負載中每條語句的執行頻率：-#SET FREQUENCY <x>這里的<x>表示隨后要執行 SQL語句的次數。最后

21、的文件類似于這樣（最好在表名 前加上schema,這樣使用任何 db2instl用戶連接數據庫也沒問題 ）：-#SET FREQUENCY 100select * from where attribute_id=11;select a.*, from a, b where = and =11 order by bindin g_data _n ame,edit_time;select f.* fromf where =11;select * from where OBJECT_ID=11 and OBJECT_TYPE=4;select * from f where =11 and >

22、4;先創建db2執行計劃的相關數據庫對象（以下命令只需要執行一次）db2 -tvf /sqllib/misc/以前面得到的為輸入參數，執行顧問程序得到建議索弓I，生成的索引建議文件為db2advis -d dbn ame -i -t 0 -o可以檢查一下生成的建議索引，然后執行下面的命令創建索引db2 -tf -z重復以上步驟，盡可能是索引最優化。需要注意的時，并不是所有的查詢都可以通過索引解決性能問題，有時可能是需要對SQL或者應用進行優化才能從根本上解決問題的，比如：?未分頁的大數據量查詢?大表間的交叉連接導致笛卡爾乘積運算的這些問題暫不在本文討論范圍內。5.其他調優F面是一些DB2其他方

23、面的調優要點，一般在初始化數據庫的時候都需要調整的，從 其他文檔抄過來，供參考。（1）調整 db2 的最大連接數 MAXAPPLS 和 MAXAGENTS （默認是 400） ， MAXAPPLS 值要略小于 MAXAGENTS （記住這兩個值與硬件的配置大小有關的，不能隨意增大， 否則會超過物理的承受能力）使用以下命令查看 MAXAGENTS 和修改其值的大小db2 get dbm cfgdb2 update dbm cfg using MAXAGENTS N使用以下命令修改 MAXAPPLSdb2 get db cfg for DBNAMEdb2 update db cfg for DBN

24、AME using MAXAPPLS N（2）調整 db2 日志文件最大的大小db2 get db cfg for DBNAME 查看到 LOGFILSIZ 的值大小是多少， 通常默認是 1000 ，可 加到 10000（或更大 ）db2 update db cfg for DBNAME using LOGFILSIZ N（3）設置可打開最大文件數 默認 64 發現數據庫該參數一直使用默認配置， 系統正常運行時， 不斷打開和關閉文件的狀態值 相當高，減緩了 SQL 響應時間并耗費了 CPU 周期。根據現場實際情況，調整該參數值， 直到不斷打開和關閉文件的狀態停止。數據庫配置參數 MAXFILO

25、P 約束 DB2 能夠同時打開的文件最大數量。 當打開的文件 數達到此數量時， DB2 將開始不斷地關閉和打開它的表空間文件（包括裸設備） 。不斷地打 開和關閉文件減緩了 SQL 響應時間并耗費了 CPU 周期。要查明 DB2 是否正在關閉文件，請發出以下命令：db2 "get snapshot for database on DBNAME" 并查找以下的行：Database files closed = 0 如果上述參數的值不為 0，那么增加 MAXFILOP 的值直到不斷打開和關閉文件的狀 態停止。使用以下命令：db2 "update db cfg for D

26、BNAME using MAXFILOP N"（4）設置 Locklist 和 Maxlocks4K）。locklist- 在一個數據庫全局內存中用于鎖存儲的內存。單位為頁（可根據實際應用環境調整這兩個值db2 get db cfg for DBNAMEdb2 update db cfg for DBNAME using locklist Ndb2 update db cfg for DBNAME using maxlocks N(5) 設置超時鎖 降低了原有的鎖超時的參數值，防止在鎖上等待過長時間會在鎖上產生雪崩效應。原有 LOCKTIMEOUT = 30 ，改為 15db2 up

27、date db cfg for EXFLOW using LOCKTIMEOUT 15LOCKTIMEOUT 的缺省值是 -1，這意味著將沒有鎖超時(對OLTP 應用程序，這種情況可能會是災難性的) 。盡管如此， 我還是經常發現許多 DB2 用戶用 LOCKTIMEOUT = -1。將 LOCKTIMEOUT 設置為很短的時間值， 例如 10 或 15 秒。在鎖上等待過長時間會 在鎖上產生雪崩效應。首先，用以下命令檢查 LOCKTIMEOUT 的值：db2 "get db cfg for DBNAME" 并查找包含以下文本的行：Lock timeout (sec) (LOC

28、KTIMEOUT) = -1如果值是 -1 ，考慮使用以下命令將它更改為15 秒(一定要首先詢問應用程序開發者或您的供應商以確保應用程序能夠處理鎖超時) ：db2 "update db cfg for DBNAME using LOCKTIMEOUT 15" 您同時應該監視鎖等待的數量、鎖等待時間和正在使用鎖列表內存( lock list memory ) 的量。請發出以下命令：db2 "get snapshot for database on DBNAME"查找以下行：Locks held currently= 0Lock waits= 0Time d

29、atabase waited on locks (ms)= 0Lock list memory in use (Bytes)= 576Deadlocks detected= 0Lock escalations= 0Exclusive lock escalations= 0Agents currently waiting on locks= 0Lock Timeouts= 0如果 Lock list memory in use (Bytes) 超過所定義 LOCKLIST 大小的 50% ，那么在 LOCKLIST 數據庫配置中增加 4k 頁的數量。查看鎖信息及釋放死鎖可通過下列一系列命令db2

30、 update monitor switches using lock ondb2 get snapshot for locks on DBNAME > 把鎖信息輸出到 文件中 在 文件中查找某張表的相關鎖 找到持有這個鎖的應用程序句柄，如： 888 db2 force application(888)(6) 調排序堆 發現數據庫該參數一直使用默認值，根據現場情況，調整后，降低在CPU、I/O 和所用時間方面的成本。db2 update db cfg for EXFLOW using SORTHEAP 256 (調大一些) 請發出以下命令：db2 "get snapshot f

31、or database on DBNAME" 并查找以下行：Total sort heap allocated= 0Total sorts = 1Total sort time (ms)= 8Sort overflows = 0Active sorts = 0Commit statements attempted = 3Rollback statements attempted = 0Let transactions = Commit statements attempted + Rollback statements attempted100/Let SortsPerTX= Tot

32、al sorts / transactionsLet PercentSortOverflows = Sort overflows * 100 / Total sorts如果 PercentSortOverflows (Sort overflows * 100) / Total sorts ) 大于 3 個百分點，那么 在應用程序 SQL 中會出現嚴重的或意外的排序問題。 因為正是溢出的存在表明發生了大的 排序，所以理想的情況是發現沒有排序溢出或至少其百分比小于一個百分點。 如果出現過多的排序溢出， 那么“應急 ”解決方案是增加 SORTHEAP 的大小。 然而， 這樣做 只是掩蓋了真實的性能問

33、題。相反，您應該確定引起排序的 SQL 并更改該 SQL 、索引或 群集來避免或減少排序開銷。如果 SortsPerTX 大于 5 (作為一種經驗之談) ，那么每個事務的排序數可能很大。雖 然某些應用程序事務執行許多小的組合排序(它們不會溢出并且執行時間很短)，但是它消耗了過多的 CPU。當SortsPerTX很大時，按我的經驗，這些機器通常會受到CPU的限制。確定引起排序的 SQL 并改進存取方案(通過索引、群集或更改 SQL )對提高事務吞 吐率是極為重要的。dbm:ASLHEAPSZ 256 ,?query_heap_sz N 查詢堆的大小必須大于或等于 ASLHEAPSZ , 最好 5

34、 倍以上 db:APPLHEAPSZ 4096 應用程序堆是供數據庫管理器代表某個特定代理使用的私有內存。當代理或子代理要為應用程序而初始化時， 就要從這個堆中分配內存， 并且所分配的內存數量是處理請求時所需的最 小內存量， 如果需要更多的內存， 則最多可以從堆中分配由該參數指定的一個最大值那么多 的內存。按 256 逐次增加，直到錯誤消失。APP_CTL_HEAP_SZ 1024 了解了各參數的功能后， 當需要對這些參數進行調整時， 應同時考慮是否需要對其它幾個相 關參數進行調整。例如當 SQL0973N 錯誤提示需要增大應用程序控制堆的大小時，則可直 接增大 APP_CTL_HEAP_SZ 參數的值， 用戶希望維持應用程序組中應用程序數目不變， 由 于該值為 APPGROUP_MEM_SZ / APP_CTL_HEAP_SZ 所決定，就要考慮同時增大 APPGROUP_MEM_SZ 的值，即增