当领导给DBA分配一项在DB2 z/OS环境下对性能进行调优的任务，那么有没有多种手段可以达到这一目标呢？

　　答案是肯定的。这里列出了5种主要的性能调优方法如下：

• SQL调优包括SQL检查，以及了解潜在访问路径，表单和索引数据分配和一些相关统计信息。
• 资源约束调优是对CPU，运行时间，输入输出，内存，网络流量以及其他资源可能权衡的分析。
• 应用程序调优主要关注那些可访问的特定表单，批量窗口以及在线服务级别。
• 对象调优专注于对表单，索引，存储过程以及数据库对象的一般定义和配置。
• 系统调优则针对的是DB2数据库管理系统的基础结构，以使其支持以上所有项目。

　　调优工具

　　系统管理程式（SMF）报告：有很多的工具可以输入SMF记录并生成DB2报表。这些工具包括IBM公司的DB2 Performance Monitor / Performance Expert （现在名为” Omegamon XE for DB2 Performance Expert”），还有一些工具是来自其他第三方提供商。

　　资源管理程式（RMF）报告：这些关于资源利用情况的报告是在资源管理程式收集并提供的数据基础上产生的。对于先进性能调优器则要求的更多，因为它们被认定为对z/OS特性的了解是专家级别的。建议DBA读下相关手册（“RMF 性能管理指南” SC33-7992-04，以及“RMF 报告分析” SC33-7991-09） 并从以下方面入手：

• 耦合设施活动
• I/O活动
• CUP活动

　　三个最为重要的性能报告

　　DBA总需要应对生产系统性能的问题，因此他们需要具备以下知识：

• 计量总结，或称为计量简报（Accountting Short Report）。它给出了关于程序和SQL语句的运行时间，CUP利用率，以及I/O情况的基本历史信息。
• 解释工具可以让用户报告DB2中一条SQL语句所要使用的访问路径。它所包含的有用信息有连接方式，排序要求以及索引使用情况。
• 诊断检查信息，是一个定期执行的查询汇报标准工具集。可以通过它呈现DB2的子系统配置参数，数据访问模式，索引群集等信息。

　　其他性能报告

　　以上三类报告最常用来诊断特定的短期性能问题。相比之下，接下来的三类报告的应用更具前瞻性。DBA将能掌控多个应用程序或是整个子系统的性能，估计资源使用情况从而做出容量规划并尝试去预测未来的需求。

• 历史访问路径信息指的是解释器产生的存储访问路径。它可以让DBA在时间域上比较应用程序的访问路径，监视变更情况以及做趋势分析。
• 详细计量报告是一种详尽的应用程序或是SQL语句执行的视图。它是超乎计量简报中总结信息之外的一种信息挖掘方式。
• TOP “n”报告是自定义版本的基于标准系统管理程式的报告（包括计量，统计，性能等），并且它可以通过多关键字来限制报告的规模。而用例可以包含排名前10（或前20）的高CPU使用率的应用程序，或是运行时长排名前10的SQL语句等。

　　以下我们将更为详细的谈谈这三种报告。

　　历史访问路径

　　解释器以逐行写入计划表，语句表或是其他与性能相关表单的方式产生一份SQL访问路径信息的报告。这些记录可以以单独的档案加以存储和维护并长期积累。如此一来就提供给了DBA对应用程序和SQL语句的DB2访问路径选择的一份历史档案。

　　从而DBA可以根据时间域检查任何变更。这对于表单或索引改变，主应用程序的变更，SQL增强，DB2子系统配置的改变或是软件的升级后的检查十分重要。

　　除了计划表数据外，DBA也可以获得表单，字段，索引和统计数据，以及键和完整性信息。

　　这可以通过指定一个存储所有访问路径的主计划表来完成，尽管这样做你会在某种程度上需要关联访问路径，而这些访问路径会随着SQL语句数量的改变而改变（一种方法是通过在所有的SQL语句中设置QueryNo 参数来实现）。通过创建一个主计划表，你可以执行各种自己的查询。例如：

　　通过连接SysTables, SysIndexes, 和 SysColumns（以及其他）来显示某些被选定的特定的索引字段加以访问，当然也可以是其他表单索引。你也可以选择诸如表基数的统计信息以决定哪些查询访问的是非抽样表单，哪些是访问稀疏或无记录表单，亦或是大型表。

　　通过连接目录表SysKeys和SysRels来决定哪些访问路径会受到参照完整性的影响

　　另外的途径则是通过购买软件工具来收集、存储和显示相关信息。

　　详细计量报告

　　此类报告可以让DBA对计划/包的细节进行挖掘。它可以给出计划和包的极为详尽的信息。而它的典型应用是在DBA参考过计量简报并认定存在可能的性能问题之后。

　　图1是对详细计量报告的一个概述，此图给出了报告是如何对其进行展现的基本思想。其中一些较常应用的部分用彩色进行标注。

图1 – 详细计量报告

　　TOP ”n”报告

　　通过定期执行并获得TOP “n”报告，DBA可以得到对许多问题类型的早期预警。例如，你可能会运行一份周报对CPU利用率排名前20的SQL语句进行监听。如果一条语句在报告中存留数周的时间，那么就可能预示着有调优的可能性。而如果一条新语句出现则可能是因为某些东西被变更了，例如更大数据容量或是不同的访问路径。

　　TOP ”n”报告是典型的根据应用程序类型和类别定制的。在线应用程序通常是短期的，而批量应用程序则可能会运行数小时，所以应该根据类别进行单独报告。

　　大多数基于系统管理程式的报告可以根据要求显示有限数量的条目，正所谓 TOP “n”。例如，你可以要求在一个时间周期内分析所有的包，但仅仅报告其中在In-DB2 CPU Time，或是Class 1 Wait Time亦或是任何数量的字段中具有最高值的前10项（或前20，亦或是前50等）。以下列出了一些最为有用的字段：

• Elapsed Time（Application； In-DB2）
• CPU Time （Application； In-DB2）
• Class 1 Wait Time （In-Application）
• Class 2 Wait Time （In-DB2）
• Class 3 Wait Suspensions
• # DML Statements Executed
• # GetPages
• # Buffer Updates
• # Synchronous Reads

　　四种常见的调优策略

　　如手头已有历史报告，则有四种常见的方法可用来检查相关信息以达到对应用程序进行性能调优的目的：

• 计量报告下钻，DBA对计量简报进行分析来寻找常见问题，然后通过参考详细报告来查找更多的细节问题。
• 自动化的TOP ”n”分析，通过创建一个流程来读取电子版的TOP “n”报告，然后根据简易的标准来发布异常报告。
• 约束权衡，也称为资源约束分析。DBA查找系统中的约束资源，如过载CPU，满存储的磁盘，超长运行时间的任务等等。经过一个约束性认定，DBA就可以分析出哪些应用程序正在使用约束资源，而另外哪些资源可以用来缓解这种情况。
• 解释检查自动化，历史解释信息可以通过简易的流程来进行分析并生成潜在访问路径问题的报告

　　这些策略中，计量报告挖掘是最常用到的。

　　计量报告挖掘

　　从计量简报入手，DBA对应用程序进行整体扫描并寻找当前以及潜在的性能问题。这些问题可能包括高CPU利用率，长运行时间，大量的SQL语句发布， 或是大量的输入输出（I/Os）。

　　经过对一些目标程序的认定，DBA现在可以对详细计量报告进行回顾。计量简报条目只需要几行；相比之下，对于应用程序详细报告的一个条目则可达十页甚至更多！所以，详细报告的限制执行仅针对目标应用程序。

　　从何处着手

　　不论你决定从什么方面着手进行调优，有一点是可以确定的：那就是你会有大量的工作要做！要降低工作负荷，你应该将精力集中在流程的自动化上。一个很好的起点就是建立，检查并自动化你的TOP “n”报告。

　　选择报告或是与你要进行调优方面相关的报告并部署一个例行的流程来生成这些报告，与合适的人举行例会来对这些结果进行检查。

　　例如，如果你正进行SQL调优，并对你的排名前10（或前50）的SQL语句建立了例行报告。选择你自己的标准进行报告：总的运行时间，总的CPU时间，以及总的I/O同步等待时间都是常见的项目。每天或是每周运行这些报告并和你的同行或是以合适的应用程序领域进行检查

　　检查可用的诊断检查或开发属于你自己项目，并对它们进行定期的运行和检查。当它们出现时制定计划用以对问题进行标识。

　　即便最简陋的商店也可能会有你想要的工具。去发掘一些IBM或第三方工具能让DB2的调优事半功倍。

        相关阅读：DB2 for z/OS应用调优：事务处理时间