为了帮忙 DB2 DBA 避免功能灾祸并取得高功能，我为我们的客户、用户和 DB2 专家偕行总结了一套弱点诊断流程。以下详尽阐明');在 Unix、Windows 和 OS/2 情形下运用 DB2 UDB 的电子商务 OLTP 利用设施的 10 条最主要的功能革新手腕 - 并在本文的住手部分作出 总结。
每隔大约莫几个星期，我们就会接到苦恼的 DBA 们的电话，抱怨有关功能的成绩。“我们 Web 站点速率慢得像蜗牛一样”，他们叫苦道，“我们正在得到客户，情形严峻。你能帮忙吗?”为了回复这些成绩，我为我的征询公司开荒了一个理会流程，它能让我们很快找到功能成绩的缘由，开荒出补偿设施并提出调处意见。这些打电话的人极少讯问费用和资本 - 他们只关心阻止丧掉。当 DB2 或电子商务利用设施的运转不克不及达到预期的功能时，构造和财政的收益将蒙受极大大的丧掉。
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的值直到不时翻开和封闭文件的情形停埂Ｊ褂靡韵旅睿?/P>
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，写入文件：
$> db2 "create event monitor SQLCOST for statements write to ..."
2. 激活事故监视器(确保有充足的可用磁盘空间)：
$> db2 "set event monitor SQLCOST state = 1"
3. 让利用设施运转。
4. 勾销激活事故监视器：
$> db2 "set event monitor SQLCOST state = 0"
5. 运用 DB2 供应的 db2evmon 东西来花式化 SQL Event Monitor 原始数据(依照 SQL 吞吐率可以大概必要数百兆字节的可用磁盘空间)：
$> db2evmon -db DBNAME -evm SQLCOST
> sqltrace.txt
6. 浏览整个已花式化的文件，寻觅显明大大的资本数(一个耗时的进程)：
$> 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 的义务永世都做不完!
疾速回忆转头最棒的 10 个手腕
对义务负载运用充足的署理设施。
不许可 DB2 不必要地封闭和翻开文件。
不许可经久的锁期待。
确保数据库的 TEMPSPACE 表空间的并行 I/O 伎俩。
保守地治理 DB2 排序内存并不要以大大的 SORTHEAP 来庇护排序成绩。
理会表的访问举动并确定具有希奇高的每个事故读取行数或溢出数的表。
理会每个表空间的功能特征，并追求革新读取工夫最慢、期待工夫最长、物理 I/O 读取率最高、射中率最差的表空间功能以及与所希冀的不分歧的访问属性。
确立多个缓冲池，有目的地将表空间分拨到缓冲池以便于共享访问属性。
搜检 DB2 UDB SQL Event Monitor 信息以找到哪个 SQL 语句花费比赛争论资本最多并回收准确的设施。
一旦解除了高资本 SQL，赶紧重新评价设置和物理方案设置。
来自: 新客网(www.xker.com) 详文参考：http://www.xker.com/page/e2007/1012/35908.html
版权声明：
原创作品，许可转载，转载时请务必以超链接情势标明文章 原始出处 、作者信息和本声明。否则将深究法律责任。