起原：赛迪网 作者：Baron
为了接济 DB2 DBA 防备性能灾祸并失失高性能，本文首要介绍了一套毛病诊断流程。下文中将着重讲解在Unix、Windows和OS/2 情形下应用DB2 UDB电子商务（OLTP应用挨次）的10条性能改进技巧。
10. 看管开关
确保已经掀开看管开关。倘使它们没有掀开，您将无法获取您需求的性能信息。要掀开该看管开关，请收回以下命令： db2 "update monitor switches using
lock ON sort ON bufferpool ON uow ON
table ON statement ON"
9. 代理挨次
确保有充分的 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取合用者）。
8. 最除夜掀开的文件数
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"
7. 锁
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 页的数目。
6. 临时表空间
为了改进 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"
1 指的是tablespace ID #1，它是刚才所给出的示例中的TEMPSPACE1。
5. 内存排序
OLTP 应用挨次不应该实行除夜的排序。它们在 CPU、I/O 和所用时辰方面的本钱极高，而且将使任何 OLTP 应用挨次慢上去。是以，256 个 4K 页（1MB）的缺省SORTHEAP大小（1MB）应该是充分了。您也应该晓得排序溢出的数目和每个事情的排序数。
请收回以下命令： Db2 "get snapshot for database on DBNAME"
并查找以下行： Total sort heap allocated= 0
Total sorts = 1
Total sort time (ms)= 8
Sort overflows = 0
Active sorts = 0
Commit statements attempted = 3
Rollback statements attempted = 0
Let transactions = Commit statements attempted Rollback
statements attempted
Let SortsPerTX= Total sorts / transactions
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）对提高事情吞吐率是极为紧张的。
4. 表访问
关于每个表，确定 DB2 为每个事情读取的行数。您必须收回两个命令： db2 "get snapshot for database on DBNAME"
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 必须在一个缺乏志向的页上定位一个行时就会产生溢出。
3. 表空间阐发
表空间快照对了解理睬访问什么数据以及如何访问是极端有价格的。要失失一个表空间快照，请收回以下命令： db2 "get snapshot for tablespaces on DBNAME"
对每个表空间，回答以下标题问题：
均匀读取时辰（ms）是几多？
均匀写入时辰（ms）是几多？
异步（预取）相关于同步（随机）所占的物理 I/O 的百分比是几多？
每个表空间的缓冲池掷中率是几多？
每分钟读取几多物理页面？
关于每个事情要读取几多物理和逻辑页面？
关于完好绝对表空间，回答以下标题问题：
哪个表空间的读取和写入的时辰最慢？为什么？是因为其容器在慢速的磁盘上吗？容器大小能否相等？比照异步访问和同步访问，访问属性能否和希冀的划一？随机读取的表应该有随机读取的表空间，这是为了失失高的同步读取百分比、平常较高的缓冲池掷中率和更低的物理 I/O 率。
对每个表空间，确保预取大小等于数据块大小乘以容器数。请收回以下命令： db2 "list tablespaces show detail"
倘使需求，可认为一个给定表空间转变预取大小。可以应用以下命令来反省容器界说： db2 "list tablespace containers for N show detail"
在此，N 是表空间标识号。
2. 缓冲池优化
我时常缔造一些 DB2 UDB 站点，虽然机械具有 2、4 或 8GB 内存，然则 DB2 数据库却只要一个缓冲池（IBMDEFAULTBP），其大小只要 16MB！
倘使在您的站点上也是这种情形，请为 SYSCATSPACE 目次表空间竖立一个缓冲池、为TEMPSPACE表空间竖立一个缓冲池以及另外竖立至多两个缓冲池：BP_RAND和BP_SEQ。随机访问的表空间应该分配给用于随机访问的缓冲池（BP_RAND）。序次访问（应用异步预取 I/O）的表空间应该分配给用于序次访问的缓冲池（BP_SEQ）。根据某些事情的性能目标，您可以竖立附加的缓冲池；比方，您可以使一个缓冲池充分除夜以存储整个“热”（除夜概说访问极度频繁的）表。当触及到除夜的表时，某些 DB2 用户将紧张表的索引放入一个索引（BP_IX）缓冲池获得了很除夜告成。
太小的缓冲池会孕育产生过多的、不必要的物理 I/O。太除夜的缓冲池使琐细处在把持琐细页面调度的危害中并耗费不必要的 CPU 周期来治理太过度配的内存。恰恰合适的缓冲池大小就在“太小”和“太除夜”之间的某个均衡点上。适当的大小存在于酬谢将要起头增添的点上。倘使您没有应用对象来自动举行酬谢增添阐发，那么您应该在不息添加缓冲池大小上迷信地测试缓冲池性能（掷中率、I/O 时辰和物理 I/O 读取率），直抵到达最佳的缓冲池大小。因为业务一向在更动和增长，以是应该活期重新评价“最佳大小”选择诡计。
1. SQL 本钱阐发
一条蹩脚的 SQL 语句会彻底破损您的一整天。我不止一次地看到一个相对庞大的 SQL 语句搞糟了一个调整得很好的数据库和机械。关于许多这些语句，天底下（或在文件中）没有 DB2 UDB 设置参数可以改正因错误的 SQL 语句招致的高本钱的情形。
更蹩脚的是，DBA 常常遭到种种约束：不克不及转变 SQL（能够是因为它是应用挨次供给商供给的，比方 SAP、 PeopleSoft或 Siebel）。这给 DBA 只留下三条路可走：
(1)转变或添加索引
(2)转变堆积
(3)转变目次统计信息
另外，此刻强壮的应用挨次由不计其数条分比方的 SQL 语句组成。这些语句实行的频率随应用挨次的功用和一样平常的业务需求的分比方而分比方。SQL 语句的现实本钱是它实行一次的本钱乘以它实行的次数。
每个 DBA 所面临的庞大的任务是，辨认具有最高“现实本钱”的语句的应战，而且增添这些语句的本钱。
议决本机 DB2 Explain 实用挨次、一些第三方供给商供给的对象或 DB2 UDB SQL Event Monitor 数据，您可以谋略出实行一次 SQL 语句所用的本钱本钱。然则语句实行频率只能议决详细和耗时地阐发 DB2 UDB SQL Event Monitor 的数据来体会。
在研讨SQL语句标题问题时，DBA 应用的范例流程是：
1. 竖立一个 SQL Event Monitor，写入文件： ___FCKpd___22gt; db2 "create event monitor SQLCOST for statements write to ..."
2. 激活变乱看管器（确保有富裕的可用磁盘空间）： ___FCKpd___23gt; db2 "set event monitor SQLCOST state = 1"
3. 让应用挨次运转。
4. 勾销激活变乱看管器： ___FCKpd___24gt; db2 "set event monitor SQLCOST state = 0"
5. 应用 DB2 供给的 db2evmon 对象来花腔化 SQL Event Monitor 原始数据（根据 SQL 吞吐率能够需求数百兆字节的可用磁盘空间）： ___FCKpd___25gt; db2evmon -db DBNAME -evm SQLCOST
> sqltrace.txt
6. 阅读整个已花腔化的文件，寻觅明显除夜的本钱数（一个耗时的进程）： ___FCKpd___26gt; more sqltrace.txt
7. 对已花腔化的文件举行更完备的阐发，该文件试图标识独一的语句（独立于文字值）、每个独一语句的频率（它出现的次数）和其总 CPU、排序以及其它本钱本钱的总计。如斯彻底的阐发在 30 分钟的应用挨次 SQL 活动样本上能够要花一周或更多的时辰。
要增添确定高本钱 SQL 语句所花的时辰，您可以思索许多可用的信息起原：
从技巧4，务必要谋略在每个事情中从每个表中读取的行数。倘使孕育产生的数字看上去很除夜，那么 DBA 可以在 SQL Event Monitor 花腔化输出中搜索有关的表称呼（这将减少搜索局限而且节省一些时辰），何等除夜约可以找出有标题问题的语句。 从 技巧 3，务必谋略每个表空间的异步读取百分比和物理 I/O 读取率。倘使一个表空间的异步读取百分比很高并远远赶过均匀的物理 I/O 读取率，那么在此表空间中的一个或更多的表正在被扫描。盘考目次并找出哪些表被分配到可疑的表空间（每个表空间分配一个表供给最佳性能检测），然后在 SQL Event Monitor 花腔化输出中搜索这些表。这些也能够有助于减少对高本钱 SQL 语句的搜索局限。 实行观查询拜访应用挨次实行的每条 SQL 语句的 DB2 Explain 信息。然则，我缔造高频率、低本钱语句常常争用机械容量和才能来供给希冀的性能。 倘使阐发时辰很短而且最除夜性能是关键的，那么请思索应用供给商供给的对象（它们可以快速自动化辨认本钱鳞集的 SQL 语句的进程）。 Database-GUYS Inc.的 SQL-GUY 对象供给精确、及时且均衡的 SQL 语句的本钱品级阐发。
连气儿调节
最佳性能不光需求解除高本钱 SQL 语句，而且需求确保相应的物理根蒂基本组织是适当的。当完好绝对的调节旋钮都设置得恰到长处、内存被无效地分配到池和堆而且 I/O 均匀地分配到各个磁盘时，才可失失最佳性能。虽然量度和调整需求时辰，然则实行这 10 个发起的 DBA 将极度告成地餍足内部和内部的 DB2 客户。因为电子商务的鼎新和增长，纵然是治理得最好的数据库也需求活期的微调。DBA 的使命永久都做不完！
技巧总结：
对使命负载应用充分的代理挨次。
不承诺 DB2 不必要地封闭和掀开文件。
不承诺历久的锁等候。
确保数据库的 TEMPSPACE 表空间的并行 I/O 才能。
保守地治理 DB2 排序内存并不要以除夜的 SORTHEAP 来润饰藻饰包围排序标题问题。
阐揭橥的访问活动并确定具有出格高的每个事情读取行数或溢出数的表。
阐发每个表空间的性能特征，并追求改进读取时辰最慢、等候时辰最长、物理 I/O 读取率最高、掷中率最差的表空间性能以及与所希冀的不分比方的访问属性。
竖立多个缓冲池，有目的地将表空间分配到缓冲池以便于共享访问属性。
反省 DB2 UDB SQL Event Monitor 信息以找到哪个 SQL 语句耗费谋略本钱最多并接纳精确的步伐。
一旦解除了高本钱 SQL，顿时重新评价设置和物理方案设置。
版权声明：
原创作品，承诺转载，转载时请务必以超链接方式标明文章 原始出处 、作者信息和本声明。不然将清查法律责任。