让数据库飞起来 十大DB2优化技巧[8]

创建一个 SQL Event Monitor写入文件

db create event monitor SQLCOST for statements write to

激活事件监视器(确保有充足的可用磁盘空间)

db set event monitor SQLCOST state =

让应用程序运行

取消激活事件监视器

db set event monitor SQLCOST state =

使用 DB 提供的 dbevmon 工具来格式化 SQL Event Monitor 原始数据(根据 SQL 吞吐率可能需要数百兆字节的可用磁盘空间)

dbevmon db DBNAME evm SQLCOST

sqltracetxt

浏览整个已格式化的文件寻找显着大的成本数(一个耗时的过程)

more sqltracetxt

对已格式化的文件进行更完整的分析该文件试图标识唯一的语句(独立于文字值)每个唯一语句的频率(它出现的次数)和其总 CPU排序以及其它资源成本的总计如此彻底的分析在 分钟的应用程序 SQL 活动样本上可能要花一周或更多的时间

要减少确定高成本 SQL 语句所花的时间您可以考虑许多可用的信息来源

从技巧 务必要计算在每个事务中从每个表中读取的行数如果产生的数字看上去很大那么 DBA 可以在 SQL Event Monitor 格式化输出中搜索有关的表名称(这将缩小搜索范围而且节省一些时间)这样也许能够找出有问题的语句 从 技巧 务必计算每个表空间的异步读取百分比和物理 I/O 读取率如果一个表空间的异步读取百分比很高并远远超过平均的物理 I/O 读取率那么在此表空间中的一个或更多的表正在被扫描查询目录并找出哪些表被分配到可疑的表空间(每个表空间分配一个表提供最佳性能检测)然后在 SQL Event Monitor 格式化输出中搜索这些表这些也可能有助于缩小对高成本 SQL 语句的搜索范围 尝试观察应用程序执行的每条 SQL 语句的 DB Explain 信息然而我发现高频率低成本语句经常争用机器容量和能力来提供期望的性能如果分析时间很短而且最大性能是关键的那么请考虑使用供应商提供的工具(它们能够快速自动化识别资源密集的 SQL 语句的过程) DatabaseGUYS Inc的 SQLGUY 工具提供精确实时且均衡的 SQL 语句的成本等级分析

[] [] [] [] [] [] [] [] []