如果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
  verflows= 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 ..."