源头：赛迪网 作者：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，即速重新评价配置和物理方案设置。
版权声明：
原创作品，承诺转载，转载时请务必以超链接体式技俩标明文章 原始来因 、作者信息和本声明。不然将深究轨则责任。