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，马上重新评估配置和物理设计设置。
