簡介： 本文介紹了使用 OLTP 應用程序的有關(guān)性能的一些基本要素，并包括了有關(guān)更新目錄統(tǒng)計信息以及監(jiān)控和調(diào)優(yōu)數(shù)據(jù)庫配置參數(shù)的信息。
發(fā)布日期： 2003 年 8 月 01 日
級別： 初級
訪問情況 71 次瀏覽
建議: 0 (添加評論)
DB2 Universal Database?（UDB）是第一個支持多媒體和 Web 的關(guān)系數(shù)據(jù)庫管理系統(tǒng)，它的功能非常強大，足以滿足大公司的需求，并且它非常靈活，足以滿足中小企業(yè)的要求。DB2 產(chǎn)品系列軟件和因特網(wǎng)技術(shù)的結(jié)合使我們可以方便地跨不同平臺訪問信息、使用信息并且保證信息安全。全世界有 30 多萬家公司的 6000 多萬個 DB2 用戶依賴于 IBM 數(shù)據(jù)管理解決方案。
DB2 UDB 為大多數(shù)需要電子商務的應用程序（比如電子商務、企業(yè)資源計劃、客戶關(guān)系管理、供應鏈管理、Web 自助服務和商業(yè)智能）提供支持。這是一種可伸縮的、工業(yè)級數(shù)據(jù)庫，非常適合用作電子商務發(fā)展過程中的數(shù)據(jù)管理基礎(chǔ)。
聯(lián)機事務處理（Online transaction processing，OLTP）是一類能為面向事務應用程序提供便利的應用程序，并可用來管理面向事務的應用程序，它通常用于處理許多行業(yè)的數(shù)據(jù)輸入和檢索事務，這些行業(yè)包括銀行、航空、郵購、超市和制造業(yè)。通常，OLTP 工作負載包括許多并發(fā)運行的短事務。如今的聯(lián)機事務處理日益要求支持跨網(wǎng)絡以及可能包括多家公司的事務。因此，新的 OLTP 軟件使用了客戶機／服務器處理和代理軟件，這種軟件允許事務在一個網(wǎng)絡的不同計算機平臺上運行。
在任何一種數(shù)據(jù)庫系統(tǒng)中，性能是最重要的因素之一。本文根據(jù)由運行 OLTP 類型的性能基準測試程序（TPC-C、TPC-W、Trade2 等）所得到的經(jīng)驗，著重討論了許多 DB2 性能調(diào)優(yōu)技巧。雖然數(shù)據(jù)庫應用程序的性能會受許多因素影響，但是我們著重討論配置而不是諸如容量規(guī)劃、數(shù)據(jù)庫設(shè)計或應用程序設(shè)計之類的因素。
本文的組織結(jié)構(gòu)如下：
更新目錄統(tǒng)計信息，這部分強調(diào)收集和維護最新數(shù)據(jù)庫統(tǒng)計信息的重要性，缺少這項工作常常是導致許多性能問題的源頭所在。
監(jiān)控和調(diào)優(yōu)數(shù)據(jù)庫配置參數(shù)，這部分按照重要性的順序描述了一列數(shù)據(jù)庫管理器參數(shù)和數(shù)據(jù)庫參數(shù)。通常，沒必要嘗試列表中的所有參數(shù)以實現(xiàn)性能目標?？梢灾粐L試其中位于列表頂部的那幾個，以查看是否有性能方面的改進。
有了這些技巧，就可以啟動自己的 OLTP 應用程序并使其擁有非常好的運行性能。
有足夠的網(wǎng)絡帶寬。
必須有足夠大的網(wǎng)絡帶寬以支持工作負載。請確保網(wǎng)絡或任何中間集線器都不會成為瓶頸。當支持遠程訪問時這一點尤為重要。例如，T1 線路支持 1.544 Mb/s，這僅為 0.193 MB/s，而通常的 10 Mb/s 以太局域網(wǎng)可以支持 1.25 MB/s，吞吐量為 T1 線路的 6 倍。在 UNIX 上使用諸如 netstat 這樣的命令可以監(jiān)控連接上的流量。
使用 DB2 控制中心（DB2 Control Center）的 DB2 性能配置向?qū)В―B2 Performance Configuration Wizard）來設(shè)置初始的 DB2 數(shù)據(jù)庫管理器（Database Manager）和數(shù)據(jù)庫配置（Database Configuration）參數(shù)。
這個工具會詢問您一系列有關(guān)工作負載性質(zhì)的問題，以便確定配置參數(shù)值的起始設(shè)置。您可以修改這些參數(shù)以滿足生產(chǎn)工作負載的需要。
RUNSTATS 實用程序用于更新系統(tǒng)目錄表中的統(tǒng)計信息，以幫助查詢優(yōu)化過程。如果沒有這些統(tǒng)計信息，數(shù)據(jù)庫管理器可能會做出對 SQL 語句的性能產(chǎn)生不利影響的決定。RUNSTATS 實用程序允許您收集表和／或索引中所包含數(shù)據(jù)的統(tǒng)計信息。使用 RUNSTATS 實用程序收集基于表和索引數(shù)據(jù)的統(tǒng)計信息，以便為下列情形中的存取方案選擇過程提供精確的信息：
當對 SQL 查詢進行優(yōu)化時，SQL 編譯器所做出的決定會受到優(yōu)化器的數(shù)據(jù)庫內(nèi)容模型的重大影響。優(yōu)化器使用該數(shù)據(jù)模型來估計可以用于解決某個特定查詢的其它存取路徑的成本。數(shù)據(jù)模型中的關(guān)鍵元素是一組統(tǒng)計信息，該統(tǒng)計信息收集了有關(guān)數(shù)據(jù)庫中所包含的數(shù)據(jù)和系統(tǒng)目錄表中所存儲的數(shù)據(jù)的信息。這包括表、別名（nickname）、索引、列和用戶定義的函數(shù)（UDF）的統(tǒng)計信息。數(shù)據(jù)統(tǒng)計信息中的變化會引起對存取方案的選擇發(fā)生變化，該存取方案作為訪問所期望數(shù)據(jù)的最有效方法。
下面列舉了一些統(tǒng)計信息，這些統(tǒng)計信息可以幫助給優(yōu)化器定義數(shù)據(jù)模型：
RUNSTATS 可以幫助您確定對數(shù)據(jù)庫的更改與性能之間的關(guān)系。統(tǒng)計信息顯示出表中的數(shù)據(jù)分布狀況。常規(guī)使用時，RUNSTATS 提供了在一段時期內(nèi)有關(guān)表和索引的數(shù)據(jù)，從而隨著時間的流逝，可以確定數(shù)據(jù)模型的性能趨勢。在使用 RUNSTATS 之后需要重新綁定使用靜態(tài) SQL 的應用程序，這樣查詢優(yōu)化器就可以選擇新統(tǒng)計信息所給出的最佳存取方案。但是，對于使用動態(tài) SQL 的應用程序（比如大多數(shù)供應商應用程序）而言，沒必要進行重新綁定，因為語句的優(yōu)化是根據(jù)統(tǒng)計信息在運行時進行的。當有關(guān)表的統(tǒng)計信息不準確時，可能會造成性能問題。最糟的情況是，某個特定的 SQL 語句可能會造成 DB2 使用表掃描而不是使用索引掃描。
只有當進行顯式的請求時，對象的統(tǒng)計信息才會在系統(tǒng)目錄表中被更新。有幾種方法可以更新部分或全部統(tǒng)計信息：
當您不完全知道所有表名或表名實在太多時，進行 RUNSTATS 的最簡單方法就是使用“db2 reorgchk update statistics”命令。正確的腳本如下：
db2 -v connect to DB_NAME db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes" db2 -v reorgchk update statistics on table all db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes" db2 -v terminate |
我們上面所選的示例不需要表名。這一命令對所有表執(zhí)行 RUNSTATS。
記住： 在填充數(shù)據(jù)庫之后再運行 RUNSTATS 實用程序。
如果您知道表名并且想避免對大量表運行 RUNSTATS 實用程序（因為這樣做可能要花很長時間），那么一次對一張表進行 RUNSTATS 更為可取。命令如下：
db2 -v runstats on table TAB_NAME and indexes all |
這個命令將收集該表及其所有索引（基本級別）的統(tǒng)計信息。
要查看是否對數(shù)據(jù)庫執(zhí)行了 RUNSTATS，一種快捷方法便是查詢一些系統(tǒng)目錄表。例如，如上面的腳本所示，可以運行下面這條命令：
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes" |
如果還未運行 RUNSTATS，您會看到 nleaf 和 nlevels 列為“-1”且 stats_time 列為“-”。如果已經(jīng)運行了 RUNSTATS，則這些列包含實際的數(shù)字，并且如果運行過 RUNSTATS，則 stats_time 列將包含時間戳記。如果您認為 stats_time 中所示時間離現(xiàn)在已有很長一段時間，那就該再次運行 RUNSTATS。
監(jiān)控和調(diào)優(yōu)數(shù)據(jù)庫配置參數(shù)
下面這些有關(guān)數(shù)據(jù)庫配置調(diào)優(yōu)的技巧將使您在 OLTP 環(huán)境中取得非常好的性能，同時使您能夠避免顯而易見的“陷阱”。在配置參數(shù)中，數(shù)據(jù)庫管理器配置參數(shù)需要重新啟動數(shù)據(jù)庫管理器，而為了使更改生效，大多數(shù)數(shù)據(jù)庫配置參數(shù)都要求應用程序重新連接到數(shù)據(jù)庫。
這里描述的配置參數(shù)包括：
緩沖池是內(nèi)存中的一塊存儲區(qū)域，用于臨時讀入和更改數(shù)據(jù)庫頁（包含表行或索引項）。緩沖池的用途是為了提高數(shù)據(jù)庫系統(tǒng)的性能。從內(nèi)存訪問數(shù)據(jù)要比從磁盤訪問數(shù)據(jù)快得多。因此，數(shù)據(jù)庫管理器需要從磁盤讀取或?qū)懭氪疟P的次數(shù)越少，性能就越好。對一個或多個緩沖池進行配置之所以是調(diào)優(yōu)的最重要方面，是因為連接至數(shù)據(jù)庫的應用程序的大多數(shù)數(shù)據(jù)（不包括大對象和長字段數(shù)據(jù)）操作都在緩沖池中進行。
缺省情況下，應用程序使用緩沖池 IBMDEFAULTBP，它是在創(chuàng)建數(shù)據(jù)庫時創(chuàng)建的。當 SYSCAT.BUFFERPOOLS 目錄表中該緩沖池的 NPAGES 值為 -1 時，DB2 數(shù)據(jù)庫配置參數(shù) BUFFPAGE 控制著緩沖池的大小。否則會忽略 BUFFPAGE 參數(shù)，并且用 NPAGES 參數(shù)所指定的頁數(shù)創(chuàng)建緩沖池。
對于僅使用一個緩沖池的應用程序，將 NPAGES 更改成 -1，這樣 BUFFPAGE 就可以控制該緩沖池的大小。這使得更新和報告緩沖池大小以及其它 DB2 數(shù)據(jù)庫配置參數(shù)變得更加方便。
確保可以使用數(shù)據(jù)庫配置中的 BUFFPAGE 參數(shù)來控制緩沖池大小之后，將該參數(shù)設(shè)置成合適的值。根據(jù)數(shù)據(jù)庫的大小和應用程序的性質(zhì)將該參數(shù)設(shè)置成一個合理的大值，這種做法很安全。通常，該參數(shù)的缺省值非常小，可能滿足不了要求。請考慮下列情況：
運行下面這個腳本，以便：
db2 -v connect to DB_NAME db2 -v select * from syscat.bufferpools db2 -v alter bufferpool IBMDEFAULTBP size -1 db2 -v connect reset db2 -v update db cfg for dbname using BUFFPAGE bigger_value db2 -v terminate |
要確定數(shù)據(jù)庫的緩沖池大小是否由 BUFFPAGE 參數(shù)所決定，請運行：
db2 -v connect to DB_NAME db2 -v SELECT * from SYSCAT.BUFFERPOOLS db2 -v connect reset db2 -v terminate |
檢查結(jié)果。如果每個緩沖池都有一個為“-1”的 NPAGES 值，那么緩沖池大小是由數(shù)據(jù)庫配置中的 BUFFPAGE 參數(shù)控制的。
要確定緩沖池大小是否足夠大，請在運行應用程序時收集數(shù)據(jù)庫和／或緩沖池的快照。類似于下面的腳本為您提供這些所需的信息：
db2 -v update monitor switches using bufferpool on db2 -v get monitor switches db2 -v reset monitor all |
請確保您在斷開數(shù)據(jù)庫連接之前發(fā)出“db2 -v get snapshot”。當最后一個應用程序與數(shù)據(jù)庫斷開連接時，該數(shù)據(jù)庫停止運行，同時所有快照統(tǒng)計信息將會丟失。要確保一直存在使數(shù)據(jù)庫處于正常運行狀態(tài)的連接，請使用下列方法之一：
在數(shù)據(jù)庫快照或緩沖池快照的快照輸出中，查找下列“l(fā)ogical reads”和“physical reads”，這樣就可以計算出緩沖池命中率，它可以幫助您調(diào)優(yōu)緩沖池：
-- Related lines from a sample of bufferpool snapshots -- Buffer pool data logical reads = 702033 Buffer pool data physical reads = 0 Buffer pool data writes = 414 Buffer pool index logical reads = 168255 Buffer pool index physical reads = 0 |
緩沖池命中率表明數(shù)據(jù)庫管理器不需要從磁盤裝入頁（即該頁已經(jīng)在緩沖池中）就能處理頁請求的時間百分比。緩沖池的命中率越高，使用磁盤 I/O 的頻率就越低。按如下計算緩沖池命中率：
(1 - ((buffer pool data physical reads + buffer pool index physical reads) / (buffer pool data logical reads + pool index logical reads)) ) * 100% |
這個計算考慮了緩沖池高速緩存的所有頁（索引和數(shù)據(jù)）。理想情況下，該比率應當超過 95%，并盡可能接近 100%。要提高緩沖池命中率，請嘗試下面這些方法：
如果已分配的內(nèi)存不能幫助提高性能，那么請避免給緩沖池分配過多的內(nèi)存。應當根據(jù)取自測試環(huán)境的快照信息來決定緩沖池的大小。
LOGBUFSZ 是一個數(shù)據(jù)庫配置參數(shù)。它是用于日志緩沖區(qū)的參數(shù)。它允許您指定數(shù)據(jù)庫共享內(nèi)存的大小以用作在將日志記錄寫到磁盤之前這些記錄的緩沖區(qū)。當下列事件之一發(fā)生時會將日志記錄寫到磁盤：
將日志記錄存在緩沖區(qū)將產(chǎn)生更加有效的日志文件 I/O，這是因為這樣一來可以降低將日志記錄寫到磁盤的頻率，同時每次可寫更多的日志記錄。如果對專用的日志磁盤有相當多的讀操作，或者希望有較高的磁盤利用率，那么可以增加這個緩沖區(qū)的大小。當增加這個參數(shù)的值時，也要考慮 DBHEAP 參數(shù)，因為日志緩沖區(qū)使用的空間由 DBHEAP 參數(shù)所控制。
我們發(fā)現(xiàn)該參數(shù)的缺省值為 8（4KB 頁），這對于 OLTP 數(shù)據(jù)庫而言通常不夠大。LOGBUFSZ 的最佳值為 128 個或 256 個 4KB 頁。例如，可以使用下面這個命令來更改該參數(shù)值：
db2 -v update database cfg for DB_NAME using LOGBUFSZ 256 db2 -v terminate |
通過查看下面這個示例中所示各行，使用數(shù)據(jù)庫快照來確定 LOGBUFSZ 參數(shù)的值是否為最佳值：
Log pages read = 0 Log pages written = 12644 |
一般而言，“l(fā)og pages read”和“l(fā)og pages written”之比應當盡可能小。理想情況下，“l(fā)og pages read”的值應為 0，而“l(fā)og pages written”的值應很大。當 log pages read 太多時，意味著需要一個較大的 LOGBUFSZ。
APPHEAPSZ 是一個數(shù)據(jù)庫配置參數(shù)，它定義了代表某個特定代理程序或子代理程序的數(shù)據(jù)庫管理器可以使用的私有內(nèi)存頁數(shù)。在為應用程序初始化代理程序或子代理程序時分配堆。分配的堆大小是處理給予代理程序或子代理程序的請求所需的最小值。當代理程序或子代理程序需要更多的堆空間以處理較大的 SQL 語句時，數(shù)據(jù)庫管理器將按照需要分配內(nèi)存，所分配的內(nèi)存大小最大可達到該參數(shù)所指定的最大值。
下面這條命令可以將缺省值（DB2 EE 為 128 個 4KB 頁，DB2 EEE 為 64 個 4KB 頁）更改成最佳值：
db2 -v update db cfg for DB_NAME using applheapsz 256 db2 -v terminate |
當應用程序接收到一個表明應用程序堆中存儲空間不夠的錯誤時，應該增加 APPHEAPSZ 的值。
排序堆大?。⊿ORTHEAP）和排序堆閾值（SHEAPTHRES）
SORTHEAP 是一個數(shù)據(jù)庫配置參數(shù)，它定義了私有排序所使用的私有內(nèi)存頁的最大數(shù)目，或共享排序所使用的共享內(nèi)存頁的最大數(shù)目。如果排序是私有排序，那么該參數(shù)影響代理程序私有內(nèi)存。如果排序是共享排序，那么該參數(shù)影響數(shù)據(jù)庫的共享內(nèi)存。每個排序都有單獨的由數(shù)據(jù)庫管理器按需分配的排序堆。在排序堆中對數(shù)據(jù)進行排序。如果由優(yōu)化器來指導排序堆大小的分配，那么用優(yōu)化器提供的信息來分配的排序堆的大小要小于由該參數(shù)所指定的排序堆大小。
SHEAPTHRES 是一個數(shù)據(jù)庫管理器配置參數(shù)。私有和共享排序所使用內(nèi)存的來源不一樣。共享排序內(nèi)存區(qū)的大小是在第一次連接到數(shù)據(jù)庫時根據(jù) SHEAPTHRES 值以靜態(tài)方式預先確定的。私有排序內(nèi)存區(qū)的大小是不受限制的。對于私有排序和共享排序，應用 SHEAPTHRES 參數(shù)的方式不同：
使用排序堆的操作示例包括內(nèi)存中表的散列連接和操作。閾值的顯式定義防止數(shù)據(jù)庫管理器將過多數(shù)量的內(nèi)存用于大量排序。
要更改 SORTHEAP 和 SHEAPTHRES 的值，請運行以下命令：
-- SORTHEAP should be changed for individual database -- db2 -v update db cfg for DB_NAME using SORTHEAP a_value -- SHEAPTHRES is a database manager parameter -- db2 -v update dbm cfg using SHEAPTHRES b_value db2 -v terminate |
OLTP 應用程序不應該執(zhí)行大型排序。大型排序在 CPU 和 I/O 資源方面的成本太高了。通常，SORTHEAP 大小的缺省值（256 個 4KB 頁）就足夠了。事實上，對于高并發(fā)性 OLTP，您可能希望降低這個缺省值。當需要進一步研究時，可以發(fā)出下面這條命令：
db2 -v update monitor switches using sort on |
然后，讓您的應用程序運行一會，然后輸入：
db2 -v get snapshot for database on DBNAME |
看一下下面這個示例中的輸出：
Total sort heap allocated = 0 Total sorts = 1 Total sort time (ms) = 0 Sort overflows = 0 Active sorts = 0 Commit statements attempted = 1 Rollback statements attempted = 0 Dynamic statements attempted = 4 Static statements attempted = 1 Binds/precompiles attempted = 0 |
根據(jù)該輸出，可以計算每個事務的排序數(shù)目，并可以計算溢出了可用于排序的內(nèi)存的那部分排序的百分比。
SortsPerTransaction = (Total Sorts) / (Commit statements attempted + Rollback statements attempted) PercentSortOverflow = (Sort overflows * 100 ) / (Total sorts) |
經(jīng)驗：如果 SortsPerTransaction 大于 5，它可能表明每個事務的排序太多。如果 PercentSortOverflow 大于 3%，那么可能發(fā)生了嚴重的、未曾預料到的大型排序。發(fā)生這種情況時，增加 SORTHEAP 只會隱藏性能問題 － 卻無法修正它。這個問題的正確解決方案是通過添加正確的索引改進有問題的 SQL 語句的存取方案。
代理程序的數(shù)目（MAXAGENTS、NUM_POOLAGENTS 和 NUM_INITAGENTS）
這些是數(shù)據(jù)庫管理器配置參數(shù)。
NUM_POOLAGENTS 參數(shù)是用于評定您希望代理程序池增加到多大的準則。如果所創(chuàng)建的代理程序多于該參數(shù)值所指明的數(shù)目，那么當代理程序執(zhí)行完自己當前的請求后將終止運行而不是返回給代理程序池。如果該參數(shù)的值為 0，將按照需要創(chuàng)建代理程序，在代理程序執(zhí)行完自己當前的請求后終止運行。
要避免因在并發(fā)連接許多應用程序的 OLTP 環(huán)境中頻繁創(chuàng)建和終止代理程序而產(chǎn)生的成本，請將 NUM_POOLAGENTS 的值增加到接近 MAXAGENTS 值。
在大多數(shù)情況下，將 MAXAGENTS 和 NUM_POOLAGENTS 的值設(shè)置成略微大于并發(fā)應用程序連接的最大預計數(shù)目。
讓 NUM_INITAGENTS 保留為缺省值會比較好。
為了更改這些參數(shù)，請運行以下命令：
db2 -v update dbm cfg using MAXAGENTS a_value db2 -v update dbm cfg using NUM_POOLAGENTS b_value db2 -v update dbm cfg using NUM_INITAGENTS c_value db2 -v terminate |
在運行期間的任何時候，您都可以使用下面這個命令來獲取數(shù)據(jù)庫管理器的快照數(shù)據(jù)：
db2 -v get snapshot for database manager |
看一下下列輸出行：
High water mark for agents registered = 4 High water mark for agents waiting for a token = 0 Agents registered = 4 Agents waiting for a token = 0 Idle agents = 0 Agents assigned from pool = 5 Agents created from empty pool = 4 Agents stolen from another application = 0 High water mark for coordinating agents = 4 Max agents overflow = 0 |
如果您發(fā)現(xiàn)“Agents waiting for a token”或“Agents stolen from another application”不等于 0，則可能需要增加 MAXAGENTS 以允許數(shù)據(jù)庫管理器可以使用更多的代理程序。
鎖（LOCKLIST、MAXLOCKS 和 LOCKTIMEOUT）
這些與鎖相關(guān)的控制都是數(shù)據(jù)庫配置參數(shù)：
MAXLOCKS 定義了應用程序持有的鎖列表的百分比，在數(shù)據(jù)庫管理器執(zhí)行鎖升級之前必須填充該鎖列表。當一個應用程序所使用的鎖列表百分比達到 MAXLOCKS 時，數(shù)據(jù)庫管理器會升級這些鎖，這意味著用表鎖代替行鎖，從而減少列表中鎖的數(shù)量。當任何一個應用程序所持有的鎖數(shù)量達到整個鎖列表大小的這個百分比時，對該應用程序所持有的鎖進行鎖升級。如果鎖列表用完了空間，那么也會發(fā)生鎖升級。數(shù)據(jù)庫管理器通過查看應用程序的鎖列表并查找行鎖最多的表，來決定對哪些鎖進行升級。如果用一個表鎖替換這些行鎖，將不再會超出 MAXLOCKS 值，那么鎖升級就會停止。否則，鎖升級就會一直進行，直到所持有的鎖列表百分比低于 MAXLOCKS。MAXLOCKS 參數(shù)乘以 MAXAPPLS 參數(shù)不能小于 100。
雖然升級過程本身并不用花很多時間，但是鎖定整個表（相對于鎖定個別行）降低了并發(fā)性，而且數(shù)據(jù)庫的整體性能可能會由于對受鎖升級影響的表的后續(xù)訪問而降低。
下面是一些控制鎖列表大小的建議：
使用下列步驟確定鎖列表所需的頁數(shù)：
對于您的數(shù)據(jù)，估計可能具有的并發(fā)數(shù)，并根據(jù)您的預計為鎖列表選擇一個初始值，該值位于您計算出的上限和下限之間。
使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器調(diào)優(yōu) MAXLOCKS 值。
設(shè)置 MAXLOCKS 時，請考慮鎖列表的大?。↙OCKLIST）：
MAXLOCKS = 100 * (512 鎖／應用程序 * 32 字節(jié)／鎖 * 2) / (LOCKLIST * 4096 字節(jié))
該樣本公式允許任何應用程序持有的鎖是平均數(shù)的兩倍。如果只有幾個應用程序并發(fā)地運行，則可以增大 MAXLOCKS，因為在這些條件下鎖列表空間中不會有太多爭用。
建議
設(shè)置 LOCKTIMEOUT 以快速檢測由于異常情形而出現(xiàn)的等待，比如事務被延遲了（可能是由于用戶離開了他們的工作站）。將它設(shè)置得足夠高，這樣有效的鎖請求就不會因為高峰時的工作負載而超時，在高峰時等待獲取鎖的時間將延長。
在聯(lián)機事務處理（OLTP）環(huán)境中，這個值從 30 秒開始。在只進行查詢的環(huán)境中可以從一個更大的值開始。無論哪種情況，都可使用基準測試技術(shù)來調(diào)優(yōu)該參數(shù)。
要更改鎖參數(shù)，請運行以下命令：
db2 -v update db cfg for DB_NAME using LOCKLIST a_number db2 -v update db cfg for DB_NAME using MAXLOCKS b_number db2 -v update db cfg for DB_NAME using LOCKTIMEOUT c_number db2 -v terminate |
一旦鎖列表滿了，由于鎖升級生成更多的表鎖和更少的行鎖，因此減少了數(shù)據(jù)庫中共享對象的并發(fā)性，從而降低了性能。另外，應用程序間可能會發(fā)生更多死鎖（因為它們都等待數(shù)量有限的表鎖），這會導致事務被回滾。當數(shù)據(jù)庫的鎖請求達到最大值時，應用程序?qū)⒔邮盏街禐?-912 的 SQLCODE。如果鎖升級造成性能方面的問題，則可能需要增大 LOCKLIST 參數(shù)或 MAXLOCKS 參數(shù)的值。可以使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器來確定是否發(fā)生鎖升級，跟蹤應用程序（連接）遭遇鎖超時的次數(shù)，或者數(shù)據(jù)庫檢測到的所有已連接應用程序的超時情形。
db2 -v update monitor switches using lock on db2 -v terminate |
db2 -v get snapshot for database on DB_NAME |
Locks held currently = 0 Lock waits = 0 Time database waited on locks (ms) = 0 Lock list memory in use (Bytes) = 504 Deadlocks detected = 0 Lock escalations = 0 Exclusive lock escalations = 0 Agents currently waiting on locks = 0 Lock Timeouts = 0 Internal rollbacks due to deadlock = 0 |
如果“Lock list memory in use (Bytes)”超過定義的 LOCKLIST 大小的 50%，那么就增加 LOCKLIST 數(shù)據(jù)庫配置參數(shù)中的 4KB 頁的數(shù)量。鎖升級、鎖超時和死鎖將表明系統(tǒng)或應用程序中存在某些潛在問題。鎖定問題通常表明應用程序中存在一些相當嚴重的并發(fā)性問題，在增大鎖列表參數(shù)的值之前應當解決這些問題。
MAXAPPLS 是一個數(shù)據(jù)庫配置參數(shù)。它指定了可以連接到數(shù)據(jù)庫的并發(fā)應用程序（本地和遠程）的最大數(shù)量。由于需要給連接到數(shù)據(jù)庫的每個應用程序分配一些私有內(nèi)存，因此允許有更多并發(fā)應用程序?qū)⒁馕吨萌ジ鄡?nèi)存。該參數(shù)值必須大于等于已連接應用程序的數(shù)量，加上這些相同的應用程序中完成兩階段提交或回滾過程中可能并發(fā)存在的數(shù)量的總和。
要運行 OLTP 應用程序，請確保將 MAXAPPLS 的值設(shè)置正確（足夠大但不能是沒必要的大）以容納最多的并發(fā)用戶／連接。對于那些使用連接池的應用程序，我們建議將 MAXAPPLS 的值設(shè)置成比連接池的大小大 1 或 2（這樣做只是為了以防需要調(diào)用命令行連接來同時做一些事情）。
要更改 MAXAPPLS 的值，請運行下面的命令：
db2 -v update db cfg for DB_NAME using MAXAPPLS a_number db2 -v terminate |
當應用程序嘗試連接數(shù)據(jù)庫，但是連接到數(shù)據(jù)庫的應用程序數(shù)已經(jīng)達到了 MAXAPPLS 的值時，會向應用程序返回下面這個錯誤，表明連接到該數(shù)據(jù)庫的應用程序數(shù)已達到了最大值。
SQL1040N The maximum number of applications is already connected to the database. SQLSTATE=57030 |
異步頁清除程序的數(shù)目（NUM_IOCLEANERS）
NUM_IOCLEANERS 是一個數(shù)據(jù)庫配置參數(shù)，它可以讓您指定數(shù)據(jù)庫的異步頁清除程序的數(shù)目。在數(shù)據(jù)庫代理程序需要緩沖池中的空間之前，這些頁清除程序?qū)⒕彌_池中已更改的頁寫到磁盤。這允許代理程序不必等待已更改頁被寫到磁盤就可以讀取新頁。因此，這會加快應用程序事務的運行。
如果將該參數(shù)設(shè)置成 0，則不啟動頁清除程序，結(jié)果，數(shù)據(jù)庫代理程序?qū)⒕彌_池中的所有頁寫到磁盤。該參數(shù)會對存儲在多個物理存儲設(shè)備上的單個數(shù)據(jù)庫的性能產(chǎn)生顯著影響，這是因為在這種情況下其中某個設(shè)備極有可能處于空閑狀態(tài)。如果沒有配置頁清除程序，則應用程序可能會遇到不時發(fā)生的“日志已滿”情況。
如果連接到數(shù)據(jù)庫的應用程序主要執(zhí)行更新數(shù)據(jù)的事務，那么增加清除程序的數(shù)目會提高性能。增加頁清除程序的數(shù)量還會減少“軟”故障（比如斷電）的恢復時間，因為磁盤上數(shù)據(jù)庫的內(nèi)容在任何給定時候都是比較新的。
當設(shè)置該參數(shù)的值時要考慮下面這些因素：
可以用下面的命令來為該參數(shù)設(shè)置一個新值：
db2 -v update db cfg for DB_NAME using NUM_IOCLEANERS a_number db2 -v terminate |
使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器，利用有關(guān)從緩沖池進行寫操作的快照數(shù)據(jù)（或事件監(jiān)視器）信息來幫助您調(diào)優(yōu)該配置參數(shù)。
當使用快照和收集緩沖池的快照數(shù)據(jù)時，監(jiān)控下列計數(shù)器：
Buffer pool data writes = 0 Asynchronous pool data page writes = 0 Buffer pool index writes = 0 Asynchronous pool index page writes = 0 LSN Gap cleaner triggers = 0 Dirty page steal cleaner triggers = 0 Dirty page threshold cleaner triggers = 0 |
如果下面這兩個條件成立，則 減少NUM_IOCLEANERS：
只要下面這兩個條件有一個成立，則 增加NUM_IOCLEANERS：
Dirty page steal cleaner triggers 指出調(diào)用頁清除程序的次數(shù)，因為在數(shù)據(jù)庫“受損”緩沖區(qū)替換期間需要同步寫操作。為了有更好的響應時間，該數(shù)值應當盡可能低。利用上面所示的計數(shù)器，可以使用下面的公式計算用該元素表示的所有清除程序調(diào)用的百分比：
Dirty page steal cleaner triggers / (Dirty page steal cleaner triggers + Dirty page threshold cleaner triggers + LSN Gap cleaner triggers) |
如果該比率很高，則它可能表明您所定義的頁清除程序太少了。頁清除程序太少會使故障恢復時間變長。
I/O 服務器的數(shù)目（NUM_IOSERVERS）
諸如備份和恢復之類的實用程序使用 I/O 服務器代表數(shù)據(jù)庫代理程序執(zhí)行預取 I/O 和異步 I/O。該參數(shù)是一個數(shù)據(jù)庫配置參數(shù)，用于指定數(shù)據(jù)庫的 I/O 服務器的數(shù)目。超過這個數(shù)量的預取和實用程序 I/O 在任何時候都不能在數(shù)據(jù)庫中運行。在啟動 I/O 操作時，I/O 服務器處于等待狀態(tài)。由于從數(shù)據(jù)庫代理程序直接調(diào)度非預取 I/O，因此非預取 I/O 不受 NUM_IOSERVERS 約束。
在 OLTP 環(huán)境中，請使用缺省值。
使用下面的命令為 NUM_IOSERVERS 設(shè)置新值：
db2 -v update db cfg for DB_NAME using NUM_IOSERVERS a_number db2 -v terminate |
MINCOMMIT 是數(shù)據(jù)庫配置參數(shù)，它讓您把將日志記錄寫到磁盤的工作一直延遲到執(zhí)行了最小數(shù)量的提交為止。該延遲可以有助于減少與寫日志記錄相關(guān)的數(shù)據(jù)庫管理器開銷。這意味著當您針對數(shù)據(jù)庫運行多個應用程序并且在非常短的時間范圍內(nèi)應用程序請求大量提交時可以提高性能。只有當該參數(shù)值大于 1 并且當連接到數(shù)據(jù)庫的應用程序數(shù)量大于或等于該參數(shù)值時，才會發(fā)生這個提交分組。當執(zhí)行提交分組時，應用程序提交請求會被掛起，直到時間過去 1 秒或提交請求的數(shù)量等于該參數(shù)值。
MINCOMMIT 的缺省值為 1。如果多個讀／寫應用程序通常請求并發(fā)數(shù)據(jù)庫提交，則從缺省值開始遞增該參數(shù)值。這將產(chǎn)生更有效率的日志文件 I/O，因為使用日志文件 I/O 的次數(shù)比較少，而每次使用日志文件 I/O 時所寫的日志記錄比較多。如果您認為缺省值不夠大，那么建議您從 3 開始進行調(diào)整，在 3 的附近嘗試以查看性能對工作負載的影響。您還可以對每秒鐘的事務量進行采樣，并調(diào)整該參數(shù)以適應每秒鐘的峰值事務量（或者采用它的某個較大的百分比）。適應峰值活動使得在重負載期間寫日志記錄的開銷減到了最低。
如果增大 MINCOMMIT，可能還需要增大 LOGBUFSZ 參數(shù)以避免在這些重負載期間強制將已滿的日志緩沖區(qū)寫入磁盤。在這種情況下，LOGBUFSZ 應該等于：
MINCOMMIT * (log space used, on average, by a transaction) |
下面介紹了如何使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器幫助您調(diào)優(yōu)該參數(shù)的一些方法：
通過采用典型一天中的監(jiān)視器樣本，可以確定重負載時期。它的一種實現(xiàn)方法是：
1. 在測量開始時，發(fā)出下面這個命令：
db2 -v reset monitor for database db_name |
（這不會使高水位的計數(shù)器復位。）
2. 在測量完畢后，發(fā)出下面這個命令：
db2 -v get snapshot for database on db_name |
3. 使用以下輸出來計算事務的峰值：
Last reset timestamp = 06-12-2001 14:51:43.786876 Snapshot timestamp = 06-12-2001 14:56:27.787088 Commit statements attempted = 1011 Rollback statements attempted = 10 Log space used by the database (Bytes) = 3990 |
讓 totalTransactions等于“commit statements attempted”和“rollback statements attempted”的總和。
讓 totalElapsedTime（單位為秒）等于“Last reset timestamp”和“Snapshot timestamp”的差。如下計算每秒事務數(shù)：
NumOfTransPerSecond = totalTransactions / totalElapsedTime |
用類似的方式，通過在一段時間內(nèi)對一些事務使用抽樣技術(shù)，可以通過下面這個監(jiān)視器元素： log_space_used（所使用的工作日志空間單元）計算出使用的日志空間的平均值。
1. 在測量開始時使用下面這個命令將感興趣的數(shù)據(jù)庫的監(jiān)視器復位：
db2 -v reset monitor for database db_name. |
2. 在測量完畢后使用下面這個命令獲取快照：
db2 -v get snapshot for database on db2_name. |
3. 產(chǎn)生如上所示的輸出。
4. 可以使用下面這個公式計算出每個事務所使用的日志空間：
LogSpaceUsedPerTrans = log_space_used / totalTransactions |
使用下面的命令更改 MINCOMMIT 值：
db2 -v update db cfg for DB_NAME using MINCOMMIT a_number db2 -v terminate |
本文描述了一些 DB2 性能方面的基本要素、調(diào)優(yōu)技巧和技術(shù)以及可能影響 OLTP 性能的一些主要的 DB2 配置參數(shù)。通過按照這里所描述的一些簡單步驟，可以設(shè)置、監(jiān)控和調(diào)優(yōu) DB2 數(shù)據(jù)庫系統(tǒng)。我們希望本文所提供的指導能幫助您實現(xiàn)最優(yōu)化 DB2 應用程序性能的目標。
