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

　　历史访问路径

　　解释器以逐行写入计划表，语句表或是其他与性能相关表单的方式产生一份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