<a id="Header1_HeaderTitle" class="headermaintitle" href="http://www.shnenglu.com/prayer/">Prayer

監(jiān)控和調優(yōu)數(shù)據(jù)庫配置參數(shù)

RUNSTATS 實用程序用于更新系統(tǒng)目錄表中的統(tǒng)計信息，以幫助查詢優(yōu)化過程。如果沒有這些統(tǒng)計信息，數(shù)據(jù)庫管理器可能會做出對 SQL 語句的性能產生不利影響的決定。RUNSTATS 實用程序允許您收集表和／或索引中所包含數(shù)據(jù)的統(tǒng)計信息。使用 RUNSTATS 實用程序收集基于表和索引數(shù)據(jù)的統(tǒng)計信息，以便為下列情形中的存取方案選擇過程提供精確的信息：

當向表裝入數(shù)據(jù)并創(chuàng)建了合適的索引時。
當用 REORG 實用程序重新組織表時。
當存在大量影響表及其索引的更新、刪除和插入操作時。（此處的“大量”可能意味著 10% 到 20% 的表和索引數(shù)據(jù)都受到了影響。）
在綁定性能至關重要的應用程序之前。
當您希望將新的和以前的統(tǒng)計信息進行比較時。定期進行統(tǒng)計使您能夠在早期階段發(fā)現(xiàn)性能問題。
當預取數(shù)量發(fā)生變化時。
當您已經使用了 REDISTRIBUTE NODEGROUP 實用程序時。

當對 SQL 查詢進行優(yōu)化時，SQL 編譯器所做出的決定會受到優(yōu)化器的數(shù)據(jù)庫內容模型的重大影響。優(yōu)化器使用該數(shù)據(jù)模型來估計可以用于解決某個特定查詢的其它存取路徑的成本。數(shù)據(jù)模型中的關鍵元素是一組統(tǒng)計信息，該統(tǒng)計信息收集了有關數(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ù)模型：

表中的頁數(shù)和非空的頁數(shù)。
從原始頁移到其它（溢出）頁的程度。
表中的行數(shù)。
有關單個列的統(tǒng)計信息，比如一列中唯一值的數(shù)量。
一個索引的群集程度；即，表中行的物理順序與索引的符合程度。
有關索引的統(tǒng)計信息，比如索引級別的數(shù)量和每個索引中葉子頁的數(shù)量。
經常使用的列值的出現(xiàn)次數(shù)。
列值在列中所有值中的分布狀況。
用戶定義的函數(shù)（UDF）的成本估計。

RUNSTATS 可以幫助您確定對數(shù)據(jù)庫的更改與性能之間的關系。統(tǒng)計信息顯示出表中的數(shù)據(jù)分布狀況。常規(guī)使用時，RUNSTATS 提供了在一段時期內有關表和索引的數(shù)據(jù)，從而隨著時間的流逝，可以確定數(shù)據(jù)模型的性能趨勢。在使用 RUNSTATS 之后需要重新綁定使用靜態(tài) SQL 的應用程序，這樣查詢優(yōu)化器就可以選擇新統(tǒng)計信息所給出的最佳存取方案。但是，對于使用動態(tài) SQL 的應用程序（比如大多數(shù)供應商應用程序）而言，沒必要進行重新綁定，因為語句的優(yōu)化是根據(jù)統(tǒng)計信息在運行時進行的。當有關表的統(tǒng)計信息不準確時，可能會造成性能問題。最糟的情況是，某個特定的 SQL 語句可能會造成 DB2 使用表掃描而不是使用索引掃描。

如何更新統(tǒng)計信息

只有當進行顯式的請求時，對象的統(tǒng)計信息才會在系統(tǒng)目錄表中被更新。有幾種方法可以更新部分或全部統(tǒng)計信息：

使用 RUNSTATS（運行統(tǒng)計信息，run statistics）實用程序。
使用帶有指定的統(tǒng)計信息收集選項的 LOAD。
對針對一組預先定義的目錄視圖進行操作的 SQL UPDATE 語句進行編碼。
使用“reorgchk update statistics”命令。

當您不完全知道所有表名或表名實在太多時，進行 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)計信息。

查看是否運行了 RUNSTATS

要查看是否對數(shù)據(jù)庫執(zhí)行了 RUNSTATS，一種快捷方法便是查詢一些系統(tǒng)目錄表。例如，如上面的腳本所示，可以運行下面這條命令：

db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"

如果還未運行 RUNSTATS，您會看到 nleaf 和 nlevels 列為“-1”且 stats_time 列為“-”。如果已經運行了 RUNSTATS，則這些列包含實際的數(shù)字，并且如果運行過 RUNSTATS，則 stats_time 列將包含時間戳記。如果您認為 stats_time 中所示時間離現(xiàn)在已有很長一段時間，那就該再次運行 RUNSTATS。

回頁首

下面這些有關數(shù)據(jù)庫配置調優(yōu)的技巧將使您在 OLTP 環(huán)境中取得非常好的性能，同時使您能夠避免顯而易見的“陷阱”。在配置參數(shù)中，數(shù)據(jù)庫管理器配置參數(shù)需要重新啟動數(shù)據(jù)庫管理器，而為了使更改生效，大多數(shù)數(shù)據(jù)庫配置參數(shù)都要求應用程序重新連接到數(shù)據(jù)庫。

這里描述的配置參數(shù)包括：

緩沖池大小
日志緩沖區(qū)大小
應用程序堆大小
排序堆大小和排序堆閾值
代理程序的數(shù)目
鎖
活動應用程序的最大數(shù)目
異步頁清除程序的數(shù)目
I/O 服務器的數(shù)目
編入組中的提交數(shù)目

回頁首

緩沖池大小

緩沖池是內存中的一塊存儲區(qū)域，用于臨時讀入和更改數(shù)據(jù)庫頁（包含表行或索引項）。緩沖池的用途是為了提高數(shù)據(jù)庫系統(tǒng)的性能。從內存訪問數(shù)據(jù)要比從磁盤訪問數(shù)據(jù)快得多。因此，數(shù)據(jù)庫管理器需要從磁盤讀取或寫入磁盤的次數(shù)越少，性能就越好。對一個或多個緩沖池進行配置之所以是調優(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ù)設置成合適的值。根據(jù)數(shù)據(jù)庫的大小和應用程序的性質將該參數(shù)設置成一個合理的大值，這種做法很安全。通常，該參數(shù)的缺省值非常小，可能滿足不了要求。請考慮下列情況：

一開始，如果您的機器上有足夠大的內存，請將 BUFFPAGE 設置成 40000 個頁（160 MB），或者等于機器總內存的 10%。
對于大型 OLTP 數(shù)據(jù)庫，在保持系統(tǒng)穩(wěn)定的同時為緩沖池留出盡可能多的內存。一開始，先嘗試使用 1.6 GB 的內存，然后嘗試用更多內存。

運行下面這個腳本，以便：

驗證目錄值
啟用數(shù)據(jù)庫配置參數(shù) BUFFPAGE
更新所有數(shù)據(jù)庫的 BUFFPAGE 值。

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

檢查結果。如果每個緩沖池都有一個為“-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
-- run your application -- db2 -v get snapshot for all databases > snap.out db2 -v get snapshot for dbm >> snap.out db2 -v get snapshot for all bufferpools >> snap.out db2 -v reset monitor all db2 -v terminate

請確保您在斷開數(shù)據(jù)庫連接之前發(fā)出“db2 -v get snapshot”。當最后一個應用程序與數(shù)據(jù)庫斷開連接時，該數(shù)據(jù)庫停止運行，同時所有快照統(tǒng)計信息將會丟失。要確保一直存在使數(shù)據(jù)庫處于正常運行狀態(tài)的連接，請使用下列方法之一：

在收集快照的窗口中保持一個單獨的連接。
使用 DB2 ACTIVATE DATABASE 命令。

在數(shù)據(jù)庫快照或緩沖池快照的快照輸出中，查找下列“logical reads”和“physical reads”，這樣就可以計算出緩沖池命中率，它可以幫助您調優(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ù)庫管理器不需要從磁盤裝入頁（即該頁已經在緩沖池中）就能處理頁請求的時間百分比。緩沖池的命中率越高，使用磁盤 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%。要提高緩沖池命中率，請嘗試下面這些方法：

增加緩沖池大小。
考慮分配多個緩沖池，如果可能的話，為每個經常被訪問的大表所屬的表空間分配一個緩沖池，為一組小表分配一個緩沖池，然后嘗試一下使用不同大小的緩沖池以查看哪種組合會提供最佳性能。

如果已分配的內存不能幫助提高性能，那么請避免給緩沖池分配過多的內存。應當根據(jù)取自測試環(huán)境的快照信息來決定緩沖池的大小。

回頁首

日志緩沖區(qū)大小（LOGBUFSZ）

LOGBUFSZ 是一個數(shù)據(jù)庫配置參數(shù)。它是用于日志緩沖區(qū)的參數(shù)。它允許您指定數(shù)據(jù)庫共享內存的大小以用作在將日志記錄寫到磁盤之前這些記錄的緩沖區(qū)。當下列事件之一發(fā)生時會將日志記錄寫到磁盤：

事務提交。
日志緩沖區(qū)已滿。
其它某個內部數(shù)據(jù)庫管理器事件發(fā)生時。

將日志記錄存在緩沖區(qū)將產生更加有效的日志文件 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

一般而言，“log pages read”和“log pages written”之比應當盡可能小。理想情況下，“log pages read”的值應為 0，而“log pages written”的值應很大。當 log pages read 太多時，意味著需要一個較大的 LOGBUFSZ。

回頁首

應用程序堆大小（APPHEAPSZ）

APPHEAPSZ 是一個數(shù)據(jù)庫配置參數(shù)，它定義了代表某個特定代理程序或子代理程序的數(shù)據(jù)庫管理器可以使用的私有內存頁數(shù)。在為應用程序初始化代理程序或子代理程序時分配堆。分配的堆大小是處理給予代理程序或子代理程序的請求所需的最小值。當代理程序或子代理程序需要更多的堆空間以處理較大的 SQL 語句時，數(shù)據(jù)庫管理器將按照需要分配內存，所分配的內存大小最大可達到該參數(shù)所指定的最大值。

下面這條命令可以將缺省值（DB2 EE 為 128 個 4KB 頁，DB2 EEE 為 64 個 4KB 頁）更改成最佳值：

db2 -v update db cfg for DB_NAME using applheapsz 256 db2 -v terminate

排序堆大小（SORTHEAP）和排序堆閾值（SHEAPTHRES）

當應用程序接收到一個表明應用程序堆中存儲空間不夠的錯誤時，應該增加 APPHEAPSZ 的值。

回頁首

SORTHEAP 是一個數(shù)據(jù)庫配置參數(shù)，它定義了私有排序所使用的私有內存頁的最大數(shù)目，或共享排序所使用的共享內存頁的最大數(shù)目。如果排序是私有排序，那么該參數(shù)影響代理程序私有內存。如果排序是共享排序，那么該參數(shù)影響數(shù)據(jù)庫的共享內存。每個排序都有單獨的由數(shù)據(jù)庫管理器按需分配的排序堆。在排序堆中對數(shù)據(jù)進行排序。如果由優(yōu)化器來指導排序堆大小的分配，那么用優(yōu)化器提供的信息來分配的排序堆的大小要小于由該參數(shù)所指定的排序堆大小。

SHEAPTHRES 是一個數(shù)據(jù)庫管理器配置參數(shù)。私有和共享排序所使用內存的來源不一樣。共享排序內存區(qū)的大小是在第一次連接到數(shù)據(jù)庫時根據(jù) SHEAPTHRES 值以靜態(tài)方式預先確定的。私有排序內存區(qū)的大小是不受限制的。對于私有排序和共享排序，應用 SHEAPTHRES 參數(shù)的方式不同：

對于私有排序，SHEAPTHRES 是對私有排序在任何給定的時間可以消耗的全部內存的實例級“軟”限制。當實例的總私有排序內存消耗量達到這一限制時，為其它進入的私有排序請求而分配的內存會大大減少。
對于共享排序，SHEAPTHRES 是對共享排序在任何給定的時間可以消耗的全部內存的數(shù)據(jù)庫級“硬”限制。當達到這一限制時，不允許有其它共享排序內存請求，直到總的共享內存消耗量回落到 SHEAPTHRES 所指定的限制以下。

使用排序堆的操作示例包括內存中表的散列連接和操作。閾值的顯式定義防止數(shù)據(jù)庫管理器將過多數(shù)量的內存用于大量排序。

使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器來跟蹤排序活動。
使用合適的索引使排序堆的使用降到最低。
當需要頻繁進行大型排序時，增加 SORTHEAP 的值。
如果增加 SORTHEAP，請確定是否還需要調整數(shù)據(jù)庫管理器配置文件中的 SHEAPTHRES 參數(shù)。
優(yōu)化器用排序堆大小來確定存取路徑。在更改該參數(shù)后請考慮重新綁定應用程序（使用 REBIND PACKAGE 命令）。
理想情況下，應當將排序堆閾值（SHEAPTHRES）參數(shù)合理地設置為在數(shù)據(jù)庫管理器實例中設置的 SORTHEAP 參數(shù)最大值的倍數(shù)。該參數(shù)至少應當是實例中任何數(shù)據(jù)庫所定義的最大 SORTHEAP 的兩倍。

如何更改這些參數(shù)

要更改 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

代理程序的數(shù)目（MAXAGENTS、NUM_POOLAGENTS 和 NUM_INITAGENTS）

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ù)目，并可以計算溢出了可用于排序的內存的那部分排序的百分比。

SortsPerTransaction = (Total Sorts) / (Commit statements attempted + Rollback statements attempted) PercentSortOverflow = (Sort overflows * 100 ) / (Total sorts)

經驗：如果 SortsPerTransaction 大于 5，它可能表明每個事務的排序太多。如果 PercentSortOverflow 大于 3%，那么可能發(fā)生了嚴重的、未曾預料到的大型排序。發(fā)生這種情況時，增加 SORTHEAP 只會隱藏性能問題－卻無法修正它。這個問題的正確解決方案是通過添加正確的索引改進有問題的 SQL 語句的存取方案。

回頁首

這些是數(shù)據(jù)庫管理器配置參數(shù)。

MAXAGENTS 參數(shù)表明在任何給定時間接受應用程序請求的數(shù)據(jù)庫管理器代理程序的最大數(shù)目。MAXAGENTS 的值應當至少是每個被并發(fā)地訪問的數(shù)據(jù)庫中的 MAXAPPLS（并發(fā)應用程序最大數(shù)目）值的總和。如果數(shù)據(jù)庫的數(shù)量大于 NUMDB 參數(shù)，那么最安全的方案就是使用 NUMDB 和 MAXAPPLS 最大值的乘積。每個額外的代理程序都需要一些資源開銷，這些開銷在啟動數(shù)據(jù)庫管理器時會分配給代理程序。
NUM_POOLAGENTS 參數(shù)是用于評定您希望代理程序池增加到多大的準則。如果所創(chuàng)建的代理程序多于該參數(shù)值所指明的數(shù)目，那么當代理程序執(zhí)行完自己當前的請求后將終止運行而不是返回給代理程序池。如果該參數(shù)的值為 0，將按照需要創(chuàng)建代理程序，在代理程序執(zhí)行完自己當前的請求后終止運行。

要避免因在并發(fā)連接許多應用程序的 OLTP 環(huán)境中頻繁創(chuàng)建和終止代理程序而產生的成本，請將 NUM_POOLAGENTS 的值增加到接近 MAXAGENTS 值。
NUM_INITAGENTS 參數(shù)決定空閑代理程序的初始數(shù)量，這些代理程序是在 DB2START 時在代理程序池中創(chuàng)建的。指定初始代理程序數(shù)目要合適（盡管并非必要條件），這可以縮短“熱身”時間。

在大多數(shù)情況下，將 MAXAGENTS 和 NUM_POOLAGENTS 的值設置成略微大于并發(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

鎖（LOCKLIST、MAXLOCKS 和 LOCKTIMEOUT）

在運行期間的任何時候，您都可以使用下面這個命令來獲取數(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ù)庫管理器可以使用更多的代理程序。

回頁首

這些與鎖相關的控制都是數(shù)據(jù)庫配置參數(shù)：

LOCKLIST 表明分配給鎖列表的存儲容量。每個數(shù)據(jù)庫都有一個鎖列表，鎖列表包含了并發(fā)連接到該數(shù)據(jù)庫的所有應用程序所持有的鎖。鎖定是數(shù)據(jù)庫管理器用來控制多個應用程序并發(fā)訪問數(shù)據(jù)庫中數(shù)據(jù)的機制。行和表都可以被鎖定。根據(jù)對象是否還持有其它鎖，每把鎖需要 32 個或 64 個字節(jié)的鎖列表：
- 需要 64 個字節(jié)來持有某個對象上的鎖，在這個對象上，沒有持有其它鎖。
- 需要 32 個字節(jié)來記錄某個對象上的鎖，在這個對象上，已經持有一個鎖。
MAXLOCKS 定義了應用程序持有的鎖列表的百分比，在數(shù)據(jù)庫管理器執(zhí)行鎖升級之前必須填充該鎖列表。當一個應用程序所使用的鎖列表百分比達到 MAXLOCKS 時，數(shù)據(jù)庫管理器會升級這些鎖，這意味著用表鎖代替行鎖，從而減少列表中鎖的數(shù)量。當任何一個應用程序所持有的鎖數(shù)量達到整個鎖列表大小的這個百分比時，對該應用程序所持有的鎖進行鎖升級。如果鎖列表用完了空間，那么也會發(fā)生鎖升級。數(shù)據(jù)庫管理器通過查看應用程序的鎖列表并查找行鎖最多的表，來決定對哪些鎖進行升級。如果用一個表鎖替換這些行鎖，將不再會超出 MAXLOCKS 值，那么鎖升級就會停止。否則，鎖升級就會一直進行，直到所持有的鎖列表百分比低于 MAXLOCKS。MAXLOCKS 參數(shù)乘以 MAXAPPLS 參數(shù)不能小于 100。

雖然升級過程本身并不用花很多時間，但是鎖定整個表（相對于鎖定個別行）降低了并發(fā)性，而且數(shù)據(jù)庫的整體性能可能會由于對受鎖升級影響的表的后續(xù)訪問而降低。

下面是一些控制鎖列表大小的建議：
- 經常進行提交以釋放鎖。
- 當執(zhí)行大量更新時，更新之前，在整個事務期間鎖定整個表（使用 SQL LOCK TABLE 語句）。這只使用了一把鎖從而防止其它事務妨礙這些更新，但是對于其他用戶它的確減少了數(shù)據(jù)并發(fā)性。
- 使用 altER TABLE 語句的 LOCKSIZE 參數(shù)控制如何在持久基礎上對某個特定表進行鎖定。
- 查看應用程序使用的隔離級別。使用可重復讀隔離級別在某些情況下可能會導致自動執(zhí)行表鎖定。當有可能減少所持有共享鎖的數(shù)量時，可以使用游標穩(wěn)定性（Cursor Stability）隔離級別。如果沒有損害應用程序完整性需求，那么可以使用未提交的讀隔離級別而不是游標穩(wěn)定性隔離級別，以進一步減少鎖的數(shù)量。

使用下列步驟確定鎖列表所需的頁數(shù)：

計算鎖列表大小的下限：(512 * 32 * MAXAPPLS) / 4096，其中 512 是每個應用程序平均所含鎖數(shù)量的估計值，32 是對象（已有一把鎖）上每把鎖所需的字節(jié)數(shù)。
計算鎖列表大小的上限：(512 * 64 * MAXAPPLS) / 4096，其中 64 是某個對象上第一把鎖所需的字節(jié)數(shù)。
對于您的數(shù)據(jù)，估計可能具有的并發(fā)數(shù)，并根據(jù)您的預計為鎖列表選擇一個初始值，該值位于您計算出的上限和下限之間。

使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器調優(yōu) MAXLOCKS 值。

設置 MAXLOCKS 時，請考慮鎖列表的大小（LOCKLIST）：

MAXLOCKS = 100 * (512 鎖／應用程序 * 32 字節(jié)／鎖 * 2) / (LOCKLIST * 4096 字節(jié))

該樣本公式允許任何應用程序持有的鎖是平均數(shù)的兩倍。如果只有幾個應用程序并發(fā)地運行，則可以增大 MAXLOCKS，因為在這些條件下鎖列表空間中不會有太多爭用。
LOCKTIMEOUT 指定了應用程序為獲取鎖所等待的秒數(shù)。這有助于應用程序避免全局死鎖。
- 如果將該參數(shù)設置成 0，那么應用程序將不等待獲取鎖。在這種情形中，如果請求時沒有可用的鎖，那么應用程序立刻會接收到 -911。
- 如果將該參數(shù)設置成 -1，那么將關閉鎖超時檢測。在這種情形中，應用程序將等待獲取鎖（如果請求時沒有可用的鎖），一直到被授予了鎖或出現(xiàn)死鎖為止。

建議

設置 LOCKTIMEOUT 以快速檢測由于異常情形而出現(xiàn)的等待，比如事務被延遲了（可能是由于用戶離開了他們的工作站）。將它設置得足夠高，這樣有效的鎖請求就不會因為高峰時的工作負載而超時，在高峰時等待獲取鎖的時間將延長。

在聯(lián)機事務處理（OLTP）環(huán)境中，這個值從 30 秒開始。在只進行查詢的環(huán)境中可以從一個更大的值開始。無論哪種情況，都可使用基準測試技術來調優(yōu)該參數(shù)。

如何更改這些參數(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ù)目（MAXAPPLS）

一旦鎖列表滿了，由于鎖升級生成更多的表鎖和更少的行鎖，因此減少了數(shù)據(jù)庫中共享對象的并發(fā)性，從而降低了性能。另外，應用程序間可能會發(fā)生更多死鎖（因為它們都等待數(shù)量有限的表鎖），這會導致事務被回滾。當數(shù)據(jù)庫的鎖請求達到最大值時，應用程序將接收到值為 -912 的 SQLCODE。如果鎖升級造成性能方面的問題，則可能需要增大 LOCKLIST 參數(shù)或 MAXLOCKS 參數(shù)的值。可以使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器來確定是否發(fā)生鎖升級，跟蹤應用程序（連接）遭遇鎖超時的次數(shù)，或者數(shù)據(jù)庫檢測到的所有已連接應用程序的超時情形。

首先，運行下面這個命令以打開針對鎖的 DB2 監(jiān)視器：

db2 -v update monitor switches using lock on
                db2 -v terminate

然后收集數(shù)據(jù)庫快照：

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ù)庫的每個應用程序分配一些私有內存，因此允許有更多并發(fā)應用程序將意味著用去更多內存。該參數(shù)值必須大于等于已連接應用程序的數(shù)量，加上這些相同的應用程序中完成兩階段提交或回滾過程中可能并發(fā)存在的數(shù)量的總和。

要運行 OLTP 應用程序，請確保將 MAXAPPLS 的值設置正確（足夠大但不能是沒必要的大）以容納最多的并發(fā)用戶／連接。對于那些使用連接池的應用程序，我們建議將 MAXAPPLS 的值設置成比連接池的大小大 1 或 2（這樣做只是為了以防需要調用命令行連接來同時做一些事情）。

要更改 MAXAPPLS 的值，請運行下面的命令：

db2 -v update db cfg for DB_NAME using MAXAPPLS a_number db2 -v terminate

異步頁清除程序的數(shù)目（NUM_IOCLEANERS）

當應用程序嘗試連接數(shù)據(jù)庫，但是連接到數(shù)據(jù)庫的應用程序數(shù)已經達到了 MAXAPPLS 的值時，會向應用程序返回下面這個錯誤，表明連接到該數(shù)據(jù)庫的應用程序數(shù)已達到了最大值。

SQL1040N The maximum number of applications is already connected to the database. SQLSTATE=57030

回頁首

NUM_IOCLEANERS 是一個數(shù)據(jù)庫配置參數(shù)，它可以讓您指定數(shù)據(jù)庫的異步頁清除程序的數(shù)目。在數(shù)據(jù)庫代理程序需要緩沖池中的空間之前，這些頁清除程序將緩沖池中已更改的頁寫到磁盤。這允許代理程序不必等待已更改頁被寫到磁盤就可以讀取新頁。因此，這會加快應用程序事務的運行。

如果將該參數(shù)設置成 0，則不啟動頁清除程序，結果，數(shù)據(jù)庫代理程序將緩沖池中的所有頁寫到磁盤。該參數(shù)會對存儲在多個物理存儲設備上的單個數(shù)據(jù)庫的性能產生顯著影響，這是因為在這種情況下其中某個設備極有可能處于空閑狀態(tài)。如果沒有配置頁清除程序，則應用程序可能會遇到不時發(fā)生的“日志已滿”情況。

如果連接到數(shù)據(jù)庫的應用程序主要執(zhí)行更新數(shù)據(jù)的事務，那么增加清除程序的數(shù)目會提高性能。增加頁清除程序的數(shù)量還會減少“軟”故障（比如斷電）的恢復時間，因為磁盤上數(shù)據(jù)庫的內容在任何給定時候都是比較新的。

當設置該參數(shù)的值時要考慮下面這些因素：

如果有多個事務針對數(shù)據(jù)庫運行，則將該參數(shù)的值設置在 1 到該數(shù)據(jù)庫所使用的物理存儲器的數(shù)量之間。有一個建議：至少將該參數(shù)的值設置成您系統(tǒng)上 CPU 的數(shù)量。
在具有高更新事務率的環(huán)境下，可能需要配置較多的頁清除程序。
在具有大緩沖池的環(huán)境下，也可能需要配置較多的頁清除程序。

可以用下面的命令來為該參數(shù)設置一個新值：

db2 -v update db cfg for DB_NAME using NUM_IOCLEANERS a_number db2 -v terminate

如何決定該減少還是該增加 NUM_IOCLEANERS？

使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器，利用有關從緩沖池進行寫操作的快照數(shù)據(jù)（或事件監(jiān)視器）信息來幫助您調優(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：

“Buffer pool data writes”約等于“Asynchronous pool data page writes”。
“Buffer pool index writes”約等于“Asynchronous pool index page writes”。

只要下面這兩個條件有一個成立，則增加NUM_IOCLEANERS：

“Buffer pool data writes”遠遠大于“Asynchronous pool data page writes”。
“Buffer pool index writes”遠遠大于“Asynchronous pool index page writes”。

Dirty page steal cleaner triggers 指出調用頁清除程序的次數(shù)，因為在數(shù)據(jù)庫“受損”緩沖區(qū)替換期間需要同步寫操作。為了有更好的響應時間，該數(shù)值應當盡可能低。利用上面所示的計數(shù)器，可以使用下面的公式計算用該元素表示的所有清除程序調用的百分比：

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ù)庫代理程序直接調度非預取 I/O，因此非預取 I/O 不受 NUM_IOSERVERS 約束。

在 OLTP 環(huán)境中，請使用缺省值。

編入組中的提交數(shù)目（MINCOMMIT）

使用下面的命令為 NUM_IOSERVERS 設置新值：

db2 -v update db cfg for DB_NAME using NUM_IOSERVERS a_number db2 -v terminate

回頁首

MINCOMMIT 是數(shù)據(jù)庫配置參數(shù)，它讓您把將日志記錄寫到磁盤的工作一直延遲到執(zhí)行了最小數(shù)量的提交為止。該延遲可以有助于減少與寫日志記錄相關的數(shù)據(jù)庫管理器開銷。這意味著當您針對數(shù)據(jù)庫運行多個應用程序并且在非常短的時間范圍內應用程序請求大量提交時可以提高性能。只有當該參數(shù)值大于 1 并且當連接到數(shù)據(jù)庫的應用程序數(shù)量大于或等于該參數(shù)值時，才會發(fā)生這個提交分組。當執(zhí)行提交分組時，應用程序提交請求會被掛起，直到時間過去 1 秒或提交請求的數(shù)量等于該參數(shù)值。

MINCOMMIT 的缺省值為 1。如果多個讀／寫應用程序通常請求并發(fā)數(shù)據(jù)庫提交，則從缺省值開始遞增該參數(shù)值。這將產生更有效率的日志文件 I/O，因為使用日志文件 I/O 的次數(shù)比較少，而每次使用日志文件 I/O 時所寫的日志記錄比較多。如果您認為缺省值不夠大，那么建議您從 3 開始進行調整，在 3 的附近嘗試以查看性能對工作負載的影響。您還可以對每秒鐘的事務量進行采樣，并調整該參數(shù)以適應每秒鐘的峰值事務量（或者采用它的某個較大的百分比）。適應峰值活動使得在重負載期間寫日志記錄的開銷減到了最低。

如果增大 MINCOMMIT，可能還需要增大 LOGBUFSZ 參數(shù)以避免在這些重負載期間強制將已滿的日志緩沖區(qū)寫入磁盤。在這種情況下，LOGBUFSZ 應該等于：

MINCOMMIT * (log space used, on average, by a transaction)

下面介紹了如何使用數(shù)據(jù)庫系統(tǒng)監(jiān)視器幫助您調優(yōu)該參數(shù)的一些方法：

計算每秒鐘的峰值事務數(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

計算每個事務所使用的日志空間：
用類似的方式，通過在一段時間內對一些事務使用抽樣技術，可以通過下面這個監(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. 產生如上所示的輸出。
4. 可以使用下面這個公式計算出每個事務所使用的日志空間：
LogSpaceUsedPerTrans = log_space_used / totalTransactions