簡介：正在尋找一個資源中心來調優 WebSphere® Portal Web Content Management 和 IBM® DB2® for Linux®, UNIX®, and Windows® 環境？本文描述該環境獨特的、需要特殊考 慮的各個部分。您將學習如何調優 Application Server 和 WebSphere Portal。作為良好的開端，您將 學習一些應該設置為指定值的各種注冊表變量和數據庫管理器及數據庫配置參數。最後，持續維護小節提 供了如何使 DB2 系統隨系統增長仍然高效運行的指導原則。
對環境進行性能調優
WebSphere Portal 環境的調優涉及到對該環境的不同的系統和組件的調優和配置。本節討論一些 通用的概念，並詳細描述本文評測環境所使用的配置的特征。 WebSphere Portal Web Content Management (WCM) AIX® Power4 評測環境的配置和調優是基於 WebSphere Portal AIX Power4 環境 的，IBM WebSphere Portal Version 6.0 Tuning Guide 對後者作了詳細闡述。用於評測 WCM 的環境的 所有不同之處在本章中都會明確提出。對任何 WebSphere Portal 環境的完整的調優和配置方法包括：
配置應用服務器和為這個應用服務器定義的資源
確定用於擴展環境的復制策略
調 優數據庫和數據庫服務器
調優目錄服務器和它的數據庫
調優 web 服務器
調優操作 系統和網絡
調優 WebSphere Portal 服務
在調優各個系統時，首先應該具備一個基准，並 監視性能指標，以確定是否應該更改某個參數，當作出更改時，也要監視性能指標，以確定更改的效果。
了解環境
WebSphere Portal V6.0 使用附加的服務器來提供其功能。在我的評測環境中， 除了 portal 服務器本身以外，還有一個 Web 服務器，一個數據庫服務器和一個目錄服務器，這些服務 器放在 WebSphere Portal 系統之外的單獨的系統上。采用這種配置的主要好處是可以避免同一個系統上 的多個服務器之間爭用資源。如果其他服務器與 WebSphere Portal 服務器爭用資源，就會影響系統可達 到的吞吐率。在本報告中，用於評測的配置將 IBM HTTP Server 與 WebSphere Portal 放在同一個系統 上。
應用服務器調優
在 WebSphere Application Server 中，應用服務器的配置和調優有 很多方面。我發現，本文和 IBM WebSphere Portal Version 6.0 Tuning Guide 中描述的那些方面對於 WebSphere Portal 在我們的實驗環境中正確、高效地運行非常關鍵。
根據我對於本文描述的工作 負載的經驗，表 1 展示了與用於 Power4 平台的 AIX 的 IBM WebSphere Portal Version 6.0 Tuning Guide 不同的一些配置：
表 1. 應用服務器參數
參數 設置 其他細節 Java™ Virtual Machine (JVM) 堆大小 1792 請注意，JVM 堆的大小與系統的物理內存的大小有直接的關系。永遠不要將 JVM 堆大小設置為 大於系統的物理內存大小。
請參閱 JVM 最大堆大小限制
JVM 堆大內存頁 -Xlp 和 IBM JVM 一起使用，用於分配具有大內存頁的堆。
請參閱 JVM 堆大 內存頁
kCluster and
pCluster
-Xk30000
-Xp24000k,2400k
固化簇。為類文件預先分配 JVM 堆，因為類文件一旦被裝載，就固化在內存中。
請參 閱 kCluster 和 pCluster
JVM 最大堆大小限制
在為應用服務器設置 堆大小時，要記住：確保系統有足夠的物理空間，以便將所有進程裝入物理內存，並滿足操作系統需要。 如果分配的內存大於系統的物理內存，就會發生分頁，從而導致糟糕的性能。
我將堆大小的最小 值和最大值設置為相同的值，對於在 IBM JDK 上運行的生產系統來說，這可能不是最佳選擇。在我的評 測中，系統承受負載的時間很短（大約 3 小時），並且運行的 portlet 的內存需求不大。如果使用內存 需求較大的 portlet，或者要持續運行，那麼通過將初始堆大小設置為 320 MB 可能會減少堆碎片。
對堆大小進行調優之後，要監視系統，以確保沒有發生分頁。如前所述，換頁會導致糟糕的性能 。
如何設置參數：
在 WebSphere Administrative Console 中，選擇 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine
可以在下面兩個地方更改堆大小：
- Initial Heap Size
- Maximum Heap Size
JVM 堆大內存頁
該設置可以與 IBM JVM 一起使用，以使用大內存頁分配堆空間。為支持大內存頁，AIX 操作系統必須 進行配置。使用大內存頁可以減少跟蹤堆所需的 CPU 開銷。通過這樣的調優，我的評測吞吐率提高了 10%。
如何設置參數：
在 WebSphere Administrative Console 中，選擇 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine -> Generic JVM Argument
添加： -Xlp
在 WebSphere Administrative Console 中，選擇 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Custom Properties -> New -> EXTSHM=OFF
（注意：當 EXTSHM 開啟時，會阻止大內存頁的使用。）
停止 Portal 服務器
配置 AIX，以支持大內存頁。我使用以下步驟分配 1856 MB 的 RAM 作為大內存頁（16MB）。之所以 選擇這個大小，是因為這些系統中有 4GB 的物理內存。對於采用不同物理內存大小的系統，這些值應有 所調整。
vmo -r -o lgpg_regions=116 -o lgpg_size=16777216
bosboot -a
reboot -q
vmo -p -o v_pinshm=1
chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE $USER
重新啟動 Portal Server。要確認是否正在使用大內存頁，運行 AIX 命令 vmstat -l 1 5 並查看 “ alp” 列，它是當前使用的活動大內存頁。如果正在使用大內存頁，那麼它應該是一個非 0 值。
kCluster 和 pCluster
JVM 堆上的對象通常是移動的；也就是說，Garbage Collector（GC）在決定重排列堆時，可能會移動 這些對象。但是，無論是永久地還是暫時地，有些對象是不能移動的。那些不能移動的對象被稱作固化對 象（pinned object）。
在版本 1.3.1 Service Refresh 7 及之前版本中，GC 首先在堆的底部分配一個 kCluster 作為第一 個對象。kCluster 是一個存儲區域，專門用於類塊。它大到足以容納 1280 個條目。每個類塊長度為 256 字節。
然後，GC 分配一個 pCluster 作為堆上的第二個對象。pCluster 是用於分配固化對象的存儲區域。 它的長度為 16 KB。
當 kCluster 耗盡時，GC 將類塊分配在 pCluster 中。當 pCluster 也耗盡時，GC 分配一個 2 KB 的新的 pCluster。
由於這個新的 pCluster 可以分配在堆中的任何位置，並且必須是固定的，因此可能導致碎片問題。 固化對象使 GC 不能在堆壓縮期間合並空閒空間，因而可能導致一個堆有很多容量較小的空閒空間，所以 即使某次分配明顯少於空閒空間總量，也不能成功分配。為解決這個問題，1.3.1 和更高版本的 SR7 提 供了一些命令行選項，用於指定 kCluster（-Xk）、pCluster（-Xp）和 pCluster 的溢出大小（-Xp）。 使用這些選項將簇的初始大小設置得足夠大，以避免碎片問題。
如何設置參數：
在 WebSphere Administrative Console 中，選擇 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine -> Generic JVM Argument
輸入 -Xk30000 -Xp24000k,2400k
數據源調優
根據 WebSphere Portal 信息中心的描述，WebSphere Portal V6.0 使用多個數據庫。在我的例子中 ，我使用 7 個獨立的數據庫，每個數據庫都有它自己的數據源。這些數據源是：
表 2. 數據源名稱
數據庫 數據庫名稱 數據源名稱 Release release reldbDS Community community commdbDS Customization custom cusdbDS Feedback fdbkdb fdbkdbDS Likeminds lmdb lmdbDS JCR jcrdb jcrdbDS Member Manager wmmdb wmmdbDS對於預置語句緩存大小，路徑為 Resources -> JDBC Providers -> provider name -> Data Sources -> datasource name -> WebSphere Application Server data source properties 。provider name 和 datasource name 隨數據庫遷移期間為數據庫選定的名稱而定。查看參數 statement cache size。
我們將所有數據源的預置語句緩存大小設為 1 條語句，以減少對本地內存的需求，從而避免系統崩潰 。
DB2 注冊表變量
下面的注冊表變量應該在實例級設置（使用 db2set 命令）：
表 3. DB2 注冊表變量解釋
注冊表變量 描述 DB2_RR_TO_RS 從 DB2 v8.2 開始，不推薦使用該參數。如果在 8.2 以上版本的 DB2 中嘗試設置該參數時沒 有遇到錯誤，那麼可以設置該參數。如果遇到錯誤，也沒有關系。接下來的兩個變量就是用來替代它的。當 DB2_RR_TO_RS 開啟時，不能確保 RR 掃描用戶表的行為，因為在索引鍵插入和刪除期 間不會鎖定下一個鍵。但是編目表不受這個選項的影響。當 DB2_RR_TO_RS 開啟時，另一個變化的行為是 ，掃描將跳過已經被刪除但是尚未提交的行，即使這些行符合掃描條件也是如此。
DB2_EVALUNCOMMITTED 該變量被啟用時，將允許表或索引訪問掃描推遲或避免行鎖，直到發現一個數據記錄滿足謂詞 條件。DB2_EVALUNCOMMITTED 只適用於使用 Cursor Stability 或 Read Stability 隔離級別的語句。對 於索引掃描，索引必須是 type-2 索引。而且，雖然在 type-2 索引掃描中，被刪除的行不會被跳過，但 是除非同時設置了注冊表變量 DB2_SKIPDELETED，否則在表掃描訪問中，被刪除的行將被無條件跳過。 DB2_SKIPDELETED 該變量被啟用時，將允許使用 Cursor Stability 或 Read Stability 隔離級別的語句在索引 掃描期間無條件地跳過被刪除的鍵，而在表訪問期間則無條件地跳過被刪除的行。當 DB2_EVALUNCOMMITTED 被啟用時，被刪除的行會被自動跳過，但是除非同時啟用了 DB2_SKIPDELETED，否 則 type-2 索引中未提交的偽刪除鍵不會被跳過。 DB2_INLIST_TO_NLJN 有時候，優化器沒有准確的信息來確定用於重寫查詢的最佳連接方法。如果 IN 列表中包含參 數標記符或主機變量，使優化器不能使用編目統計信息來確定選擇性，就會出現這種情況。這個注冊表變 量會導致優化器優先使用嵌套循環連接來連接值列表，使用為 IN 列表提供值的表作為連接的內部表。 DB2_MINIMIZE_LISTPREFETCH 為了避免對 JCR 數據庫表的查詢使用低效的訪問計劃，這個變量是必需的。
以實例用戶身份，輸入以下命令，以設置 DB2 注冊表變量：
db2set DB2_RR_TO_RS=YES
db2set DB2_EVALUNCOMMITTED=YES
db2set DB2_SKIPDELETED=ON
db2set DB2_INLIST_TO_NLJN=YES
db2set DB2_MINIMIZE_LISTPREFETCH=ON
可選變量
如果 DB2 所在系統是 CPU 密集型，那麼還可以設置下面的參數。由於這個變量對於所有包含多於 5 個連接的語句都有影響，因此要小心使用。該參數可以幫助減少優化期間占用的時間和資源。雖然這樣可 以減少優化所需的時間和資源，但是同時也會增加生成非最佳數據訪問計劃的風險。
DB2_REDUCED_OPTIMIZATION=5
注意： 只有在 IBM 明確建議的情況下，才應該設置該參數。
數據庫管理器配置參數
表 4 展示了數據庫管理器配置參數：
表 4. 數據庫管理器配置參數
參數名 值 QUERY_HEAP_SZ 32768 MAXAGENTS 1000 SHEAPTHRES 50000 HEALTH_MON OFF ASLHEAPSZ 60 RQRIOBLK 65535以實例用戶的身份，輸入以下命令，更新數據庫管理器配置：
db2 "update dbm cfg using query_heap_sz 32768"
db2 "update dbm cfg using maxagents 1000"
db2 "update dbm cfg using sheapthres 50000"
db2 "update dbm cfg using health_mon off"
db2 "update dbm cfg using aslheapsz 60"
db2 "update dbm cfg using rqrioblk 65535"
db2 "update dbm cfg using federated no"
注意： 如果需要聯邦數據庫支持，不能將 FEDERATED 設為 NO。
數據庫配置參數
用於所有數據庫的參數
表 5 展示了應該為所有數據庫設置的數據庫配置參數：
表 5. 用於所有數據庫的數據庫配置參數
參數名 值 APPLHEAPSZ 4096 APP_CTL_HEAP_SZ 1024 STMTHEAP 8192 DBHEAP 2400 LOCKLIST 1000 LOGFILSIZ 1000 LOGPRIMARY 12 LOGSECOND 20 LOGBUFSZ 128 AVG_APPLS 5 LOCKTIMEOUT 30 MAXLOCKS 70 MAXAPPLS AUTOMATIC以實例用戶的身份，輸入以下命令，為所有數據庫更新數據庫配置。注意將 DBNAME 改為實際的數據 庫名稱：
db2 "update db cfg for DBNAME using applheapsz 4096"
db2 "update db cfg for DBNAME using app_ctl_heap_sz 1024"
db2 "update db cfg for DBNAME using stmtheap 8192"
db2 "update db cfg for DBNAME using dbheap 2400"
db2 "update db cfg for DBNAME using locklist 1000"
db2 "update db cfg for DBNAME using logfilsiz 1000"
db2 "update db cfg for DBNAME using logprimary 12"
db2 "update db cfg for DBNAME using logsecond 20"
db2 "update db cfg for DBNAME using logbufsz 128"
db2 "update db cfg for DBNAME using avg_appls 5"
db2 "update db cfg for DBNAME using locktimeout 30"
db2 "update db cfg for DBNAME using maxlocks 70"
db2 "update db cfg for DBNAME using maxappls automatic"
用於 JCR 數據庫的參數
表 6 展示了應該為 JCR 數據庫設置的數據庫參數：
表 6. 用於 JCR 數據庫的數據庫參數
參數名 值 DBHEAP 4800 SORTHEAP 4096 APPLHEAPSZ 16384 APP_CTL_HEAP_SZ 20000 STMTHEAP 16384 NUM_IOCLEANERS 11 NUM_IOSERVERS 11
以實例用戶的身份，輸入以下命令，更新特定於 JCRDB 的數據庫配置。將 JCRDB 改為實際的數據庫 名稱：
db2 "update db cfg for JCRDB using dbheap 4800"
db2 "update db cfg for JCRDB using sortheap 4096"
db2 "update db cfg for JCRDB using applheapsz 16384"
db2 "update db cfg for JCRDB using app_ctl_heap_sz 20000"
db2 "update db cfg for JCRDB using stmtheap 16384"
db2 "update db cfg for JCRDB using num_iocleaners 11"
db2 "update db cfg for JCRDB using num_ioservers 11"
數據庫調優
數據庫性能對於從 WCM 獲得良好性能十分重要。本文和 IBM WebSphere Portal Version 6.0 Tuning Guide 中提到的維護任務和實踐對於 WebSphere Portal 在我們的實驗環境中正確、高效地運行非常關鍵 。在您的生產環境中，可能還需要進行一些其他的數據庫維護和調優。
校正序列
在創建數據庫時，DB2 允許對序列進行校正（collate）。這將對性能產生影響。雖然在本報告描述的 場景中，使用 UCA400_NO collation 實際上對吞吐率沒有影響，但是它會產生高得多的數據庫 CPU 開銷 。然而，在單獨的調查評測中，UCA400_NO 校正（collation）的使用對於某些 WCM 事務創建有明顯的影 響。根據經驗，需要對特定於地區的特殊數據排序需求和可能導致的更高的數據庫 CPU 開銷之間進行權 衡。當我創建數據庫時，沒有指定任何 COLLATE 選項。
將 JCR 表變為穩定狀態
JCR 模式的 DB2 配置將大多數表標記為 VOLATILE CARDINALITY。在初始填充期間，這是正確的，因 為很多表從 0 行或少數幾行增長到多行。這個屬性告訴 DB2 優化器不要信任表統計信息，因為這些統計 信息表明表非常小，如果信任這些統計信息，優化器會像往常一樣利用針對小表的索引對表進行掃描。而 一旦數據庫達到穩定狀態，則希望優化器根據編目統計信息選擇最佳訪問計劃（要獲得關於如何維護這些 統計信息的建議，請參閱後面的小節）。為此，運行以下命令：
db2 -x -r "nonVolatile.db2" "select rtrim(concat('alter table ', concat(rtrim (tabSchema),
concat('.', concat(rtrim(tabname), ' not volatile'))))) from syscat.tables where type='T'
and volatile='C' and tabSchema='JCR'"
db2 -v -f "nonVolatile.db2"
持續的數據庫維護
Runstats 和 reorg
DB2 賴以高效運行的兩個數據庫屬性是數據庫編目統計信息和數據在表中的物理組織。在數據庫的生 命周期中，特別是經過重大的數據修改（插入、更新和刪除），例如填充階段之後，應該定期地重新計算 編目統計信息。由於計算這些統計信息時需要占用很多的資源，因此最好在非繁忙時段、低需求階段或者 portal 離線時執行這種維護。DB2 runstats 命令用於計算和記錄關於表、索引和列的統計信息。在我們 的環境中，我使用了兩種方法來計算這些統計信息。 我推薦的形式是：
+
db2 "runstats on table tableschema.tablename on all columns with distribution
on all columns and sampled detailed indexes all allow write access"
這些選項使優化器可以為復雜的 SQL 確定最佳訪問計劃。對於計算編目統計信息，一種更簡單、更方 便的方法是：
db2 reorgchk update statistics on table all
該命令不僅計算並記錄一些相同的編目統計信息，它還產生一個報告，通過查看該報告可以發現表組 織方面的問題。但是，我發現該命令所產生的信息不夠充分，不足以讓優化器為復雜的 SQL（特別是對於 JCR 數據庫的查詢）選擇高效的訪問計劃。如果您想使用一種與 reorgchk 命令一樣方便，同時又能提供 優化器所需的詳細統計信息的方法，那麼可以使用下面的命令：
db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table',
concat(rtrim (tabSchema), concat('.',concat(rtrim(tabname),
' on all columns with distribution on all columns and sampled detailed
indexes all allow write access'))))) from syscat.tables where type='T'"
db2 -v -f "runstats.db2"
在生產環境中，重組所有的表是無法接受的。為了確定哪些表可以通過重組獲益，可以使用下面的命 令：
db2 reorgchk current statistics on table all > "reorgchk.txt"
表名旁的三個列當中至少有一個列中標記有 * 符號的表，這就是需要重組的表。對於需要重組的表， 使用以下命令：
db2 reorg table tableschema.tablename
監視
快照監視用於識別數據庫在一段時間內的行為。它被進一步用於對系統進行細微調節，以及發現與性 能相關的問題。
要啟用快照監視，首先需要激活不同的監視器。有兩種方式可以激活監視器。一種方式是配置數據庫 管理器，在實例級別激活監視，另一種方式是在特定的時候為當前會話啟用監視。
要在實例級別啟用默認的監視，使用以下命令：
db2 update dbm cfg using DFT_MON on
其中 DFT_MON 在以下值當中取值：
DFT_MON_BUFPOOL DFT_MON_LOCK DFT_MON_SORT DFT_MON_STMT DFT_MON_TABLE DFT_MON_TIMESTAMP DFT_MON_UOW
要為當前會話啟用監視，使用命令：
db2 update monitor switches using MON_SWITCH on
其中 MON_SWITCH 在以下值當中取值：
表 7. 監視器開關
監視器 值 Buffer Pool Activity Information BUFFERPOOL Lock Information LOCK Sorting Information SORT SQL Statement Information STATEMENT Table Activity Information TABLE Take Timestamp Information TIMESTAMP Unit of Work Information UOW注意：由於活動的監視器會增加對 CPU 的使用，所以應當只在必要時才激活所有的監視器。
要獲得當前被激活的監視器開關，可以使用以下命令：
db2 get monitor switches
要獲得數據庫的快照，可以運行以下命令：
db2 get snapshot for all on DBNAME >snap.out
監視 DB2 系統的另一種方法是 db2top。
緩沖池分析
緩沖池是在從磁盤讀取或修改表和索引數據頁時，用於緩存它們的內存。由於緩沖池允許從內存而不 是磁盤訪問數據，因此可以提高數據庫系統的性能。由於內存訪問比磁盤訪問快很多，因此數據庫管理器 讀寫磁盤的次數越少，性能就越好。
由於 DB2 v8 中沒有 SYSIBMADM.BP_HITRATIO 表，我編寫了兩個存儲過程，用於計算緩沖池的命中率 ：bphr 顯示實際數據庫的緩沖池命中率，而 bphr_all 顯示實例中所有活動數據庫的緩沖池命中率。
可以使用以下命令來調用這兩個存儲過程：
db2 call bphr
db2 call bphr_all
連接到一個數據庫之後，可以使用以下命令安裝這兩個存儲過程：
db2 -td@ -f bphr.db2
清單 1. 計算緩沖池命中率的存儲過程的代碼
CREATE PROCEDURE bphr ()
SPECIFIC tessus_bphr LANGUAGE SQL DYNAMIC RESULT SETS 1
BEGIN
DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr,
idx_hr, page_clean_ratio )
AS
(
SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
CASE
WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND
(pool_data_l_reads > 0 OR pool_index_l_reads > 0))
THEN
DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
ELSE
NULL
END CASE,
CAST( (CAST( pool_data_l_reads - pool_data_p_reads
AS DOUBLE)*100.0)/ (pool_data_l_reads+1) AS DECIMAL(3,1)),
CAST( (CAST( pool_index_l_reads - pool_index_p_reads
AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
CAST( (CAST( pool_async_data_writes + pool_async_index_writes
AS DOUBLE) *100.0)/(pool_data_writes+pool_index_writes+1)
AS DECIMAL(3,1))
FROM TABLE (snapshot_bp('',-1)) AS BP
ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr
FROM bp_snap;
OPEN res;
END@
CREATE PROCEDURE bphr_all ()
SPECIFIC tessus_bphr_all LANGUAGE SQL DYNAMIC RESULT SETS 1
BEGIN
DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr,
idx_hr, page_clean_ratio )
AS
(
SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
CASE
WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND
(pool_data_l_reads > 0 OR pool_index_l_reads > 0))
THEN
DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
ELSE
NULL
END CASE,
CAST( (CAST( pool_data_l_reads - pool_data_p_reads
AS DOUBLE)*100.0)/ (pool_data_l_reads+1) AS DECIMAL(3,1)),
CAST( (CAST( pool_index_l_reads - pool_index_p_reads
AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
CAST( (CAST( pool_async_data_writes + pool_async_index_writes
AS DOUBLE) *100.0)/(pool_data_writes+pool_index_writes+1)
AS DECIMAL(3,1))
FROM TABLE (snapshot_bp(CAST(NULL AS VARCHAR(128)),-1)) AS BP
ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr
FROM bp_snap;
OPEN res;
END@
在 DB2 9 中，可以使用這兩個存儲過程，也可以使用以下 SQL 語句來獲得緩沖池命中率：
db2 "select snapshot_timestamp, substr(db_name,1,10) as dbname,
substr(bp_name,1,18) as bufferpool, total_hit_ratio_percent as total,
data_hit_ratio_percent as data, index_hit_ratio_percent as index
from sysibmadm.bp_hitratio"
理想的緩沖池命中率是高於 96%。首先可以嘗試增加緩沖池大小，看能否提高命中率。如果命中率仍 然較低，那麼可能需要重新設計表空間和緩沖池的邏輯布局。
可以使用以下命令在線更改緩沖池的大小：
db2 alter bufferpool BPNAME immediate size NUMBER_OF_PAGES
d目錄服務器調優
我的評測使用 IBM Tivoli Directory Server (ITDS) version 5.2 作為目錄服務器。該目錄服務器 配置方面的細節與 IBM WebSphere Portal Version 6.0 Tuning Guide 中指定的 AIX ITDS V5.2 目錄服 務器的配置相同。
WebSphere Portal Service 屬性
WebSphere Portal 有很多可配置的服務；每個服務都有一些可用的參數。本節描述我對哪些服務進行 了不同於 IBM WebSphere Portal Version 6.0 Tuning Guide 的調優。
惟一進行了不同調優的服務是 Cache Manager Service。對於這個服務，除了下面表中列出的更改外 ，我接受了 WebSphere Portal 的默認設置：
表 8. Cache Manager Service 參數
結束語
本教程展示了調優 WebSphere Portal WCM 和 DB2 環境涉及的步驟。您應該看到了這個環境的獨特之 處，對它進行調優時需要作一些特殊的考慮。本文展示了那些應該設置為指定值的各種注冊表變量和一些 數據庫管理器及數據庫配置參數的重要性。最後，您看到了如何維護 DB2 系統，使之隨系統增長仍然可 以高效運行。
下載
