如何使用DB2 UDB的電子商務OLTP應用程序進行性能優化

這篇文章給大家分享的是有關如何使用DB2 UDB的電子商務OLTP應用程序進行性能優化的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

　　一、 監視開關

　　確保已經打開監視開關。如果它們沒有打開，您將無法獲取您需要的性能信息。要打開該監視開關，請發出以下命令：

　　db2 "update monitor switches using

　　lock ON sort ON bufferpool ON uow ON

　　table ON statement ON"

　　二、代理程序

　　確保有足夠的 DB2 代理程序來處理工作負載。要找出代理程序的信息，請發出命令：

　　db2 "get snapshot for database manager"

　　并查找以下行：

　　High water mark for agents registered = 7

　　High water mark for agents waiting for a token = 0

　　Agents registered= 7

　　Agents waiting for a token= 0

　　Idle agents= 5

　　Agents assigned from pool= 158

　　Agents created from empty Pool = 7

　　Agents stolen from another application= 0

　　High water mark for coordinating agents= 7

　　Max agents overflow= 0

　　如 果您發現Agents waiting for a token或Agents stolen from another application不為 0，那么請增加對數據庫管理器可用的代理程序數(MAXAGENTS 和/或 MAX_COORDAGENTS取適用者)。

　　三、最大打開的文件數

　　DB2 在操作系統資源的約束下盡量做一個“優秀公民”。它的一個“優秀公民”的行動就是給在任何時刻打開文件的最大數設置一個上限。數據庫配置參數 MAXFILOP約束 DB2 能夠同時打開的文件最大數量。當打開的文件數達到此數量時，DB2 將開始不斷地關閉和打開它的表空間文件(包括裸設備)。不斷地打開和關閉文件減緩了 SQL 響應時間并耗費了 CPU 周期。要查明 DB2 是否正在關閉文件，請發出以下命令：

　　db2 "get snapshot for database on DBNAME"

　　并查找以下的行：

　　Database files closed = 0

　　如果上述參數的值不為 0，那么增加MAXFILOP的值直到不斷打開和關閉文件的狀態停埂。

　　db2 "update db cfg for DBNAME using MAXFILOP N"

　　四、鎖

　　LOCKTIMEOUT 的缺省值是 -1，這意味著將沒有鎖超時(對 OLTP 應用程序，這種情況可能會是災難性的)。盡管如此，我還是經常發現許多 DB2 用戶用LOCKTIMEOUT= -1。將LOCKTIMEOUT設置為很短的時間值，例如 10 或 15 秒。在鎖上等待過長時間會在鎖上產生雪崩效應。

　　首先，用以下命令檢查LOCKTIMEOUT的值：

　　db2 "get db cfg for DBNAME"

　　并查找包含以下文本的行：

　　Lock timeout (sec) (LOCKTIMEOUT) = -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= 0

　　Lock waits= 0

　　Time database waited on locks (ms)= 0

　　Lock list memory in use (Bytes)= 576

　　Deadlocks detected= 0

　　Lock escalations= 0

　　Exclusive lock escalations= 0

　　Agents currently waiting on locks= 0

　　Lock Timeouts= 0

　　如果Lock list memory in use (Bytes)超過所定義LOCKLIST大小的 50%，那么在LOCKLIST數據庫配置中增加 4k 頁的數量。

　　怎么使用 DB2 UDB 的電子商務 OLTP 應用程序進行性能優化

　　五、臨時表空間

　　為了改善 DB2 執行并行 I/O 和提高使用TEMPSPACE的排序、散列連接(hash join)和其它數據庫操作的性能，臨時表空間至少應該在三個不同的磁盤驅動器上擁有三個容器。

　　要想知道您的臨時表空間具有多少容器，請發出以下命令：

　　db2 "list tablespaces show detail"

　　查找與以下示例類似的TEMPSPACE表空間定義：

　　Tablespace ID= 1

　　Name= TEMPSPACE1

　　Type= System managed space

　　Contents= Temporary data

　　State= 0x0000

　　Detailed explanation: Normal

　　Total pages= 1

　　Useable pages= 1

　　Used pages= 1

　　Free pages= Not applicable

　　High water mark (pages)= Not applicable

　　Page size (bytes)= 4096

　　Extent size (pages)= 32

　　Prefetch size (pages)= 96

　　Number of containers= 3

　　注意Number of containers的值是 3，而且Prefetch size是Extent size的三倍。為了得到最佳的并行 I/O 性能，重要的是Prefetch size為Extent size的倍數。這個倍數應該等于容器的個數。

　　要查找容器的定義，請發出以下命令：

　　db2 "list tablespace containers for 1 show detail"

　　指的是tablespace ID #1，它是剛才所給出的示例中的TEMPSPACE1。

　　六、內存排序

　　OLTP 應用程序不應該執行大的排序。它們在 CPU、I/O 和所用時間方面的成本極高，而且將使任何 OLTP 應用程序慢下來。因此，256 個 4K 頁(1MB)的缺省SORTHEAP大小(1MB)應該是足夠了。您也應該知道排序溢出的數量和每個事務的排序數。

　　請發出以下命令：

　　Db2 "get snapshot for database on DBNAME"

　　并查找以下行：

　　Total sort heap allocated= 0

　　2 Total sorts = 1

　　3 Total sort time (ms)= 8

　　4 Sort overflows = 0

　　5 Active sorts = 0

　　6 Commit statements attempted = 3

　　7 Rollback statements attempted = 0

　　8 Let transactions = Commit statements attempted + Rollback

　　9 statements attempted

　　10 Let SortsPerTX= Total sorts / transactions

　　11 Let PercentSortOverflows = Sort overflows * 100 / Total sorts

　　如 果PercentSortOverflows ((Sort overflows * 100) / Total sorts )大于 3 個百分點，那么在應用程序 SQL 中會出現嚴重的或意外的排序問題。因為正是溢出的存在表明發生了大的排序，所以理想的情況是發現沒有排序溢出或至少其百分比小于一個百分點。

　　如果出現過多的排序溢出，那么“應急”解決方案是增加SORTHEAP的大小。然而，這樣做只是掩蓋了真實的性能問題。相反，您應該確定引起排序的 SQL 并更改該 SQL、索引或群集來避免或減少排序開銷。

　　如 果SortsPerTX大于 5 (作為一種經驗之談)，那么每個事務的排序數可能很大。雖然某些應用程序事務執行許多小的組合排序(它們不會溢出并且執行時間很短)，但是它消耗了過多的 CPU。當SortsPerTX很大時，按我的經驗，這些機器通常會受到 CPU 的限制。確定引起排序的 SQL 并改進存取方案(通過索引、群集或更改 SQL)對提高事務吞吐率是極為重要的。

　　七、表訪問

　　對于每個表，確定 DB2 為每個事務讀取的行數。您必須發出兩個命令：

　　1 db2 "get snapshot for database on DBNAME"

　　2 db2 "get snapshot for tables on DBNAME"

　　在發出第一個命令以后，確定發生了多少個事務(通過取Commit statements attempted和Rollback statements attempted之和 - 請參閱 技巧 3)。

　　在 發出第二個命令以后，將讀取的行數除以事務數(RowsPerTX)。在每個事務中，OLTP 應用程序通常應該從每個表讀取 1 到 20 行。如果您發現對每個事務有成百上千的行正被讀取，那么發生了掃描操作，也許需要創建索引。(有時以分布和詳細的索引來運行 runstats 也可提供了一個解決的辦法。)

　　“get snapshot for tables on DBNAME”的樣本輸出如下：

　　Snapshot timestamp = 09-25-2000

　　4:47:09.970811

　　Database name= DGIDB

　　Database path= /fs/inst1/inst1/NODE0000/SQL00001/

　　Input database alias= DGIDB

　　Number of accessed tables= 8

　　Table List

　　Table Schema= INST1

　　Table Name= DGI_

　　SALES_ LOGS_TB

　　Table Type= User

　　Rows Written= 0

　　Rows Read= 98857

　　Overflows= 0

　　Page Reorgs= 0

　　Overflows 的數量很大就可能意味著您需要重組表。當由于更改了行的寬度從而 DB2 必須在一個不夠理想的頁上定位一個行時就會發生溢出。

感謝各位的閱讀！關于“如何使用DB2 UDB的電子商務OLTP應用程序進行性能優化”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！