使用InfoSphere Optim Query Workload Tuner从不同来源捕获SQL工
本系列的前一篇文章介绍了访问路径的概念,向您展示了如何在 Optim Query Tuner 中读取访问路径图,并详细介绍了调优每个查询的方法。
在第 3 部分中,将会介绍调优 SQL 工作负载的方法。本文将了解如何使用 InfoSphere® Optim™ Query Workload Tuner 从不同来源捕获 SQL 工作负载、收集统计数据和索引分析、比较访问计划,并执行计划锁定和计划管理。本文的目标是确保 IBM® DB2® 优化器获得它所需要的信息,从而制定出基于最佳性能的 DB2 查询决策,本文还提供了一些建议,以帮助 DB2 优化器改进访问,比如收集必要的统计数据和创建最佳索引。
在第 2 部分中,介绍了单个查询调优的方法。利用 IBM InfoSphere Optim Query Workload Tuner (IOQWT) 等查询调优工具的支持,应用程序开发人员或管理员可以分析单个查询的访问路径,并收集更多统计数据,重写查询或更改设计,从而提高性能。
工作负载性能调优的目的是:确保应用程序满足服务水平协议,并确保系统的最佳总拥有成本 (TCO)。本文将提供一种方法,使用 IBM InfoSphere Optim Query Workload Tuner (IOQWT) 进行工作负载调优。
工作负载调优与查询调优
单个查询调优关注特定查询的性能,而工作负载调优专注于工作负载中所有查询的性能。无论执行工作负载调优还是单个查询调优,目标都是相同的:提高性能。与单个查询调优相比,工作负载调优有许多优势:
- 提高所有查询的性能,可以降低 TCO 并增加满足业务服务水平要求的机会。然而,一个应用程序可能包括成千上万个查询,甚至更多,为每个查询执行单个查询调优,这是不实际的。
- 要确定哪些统计数据将有利于每个查询,以及有利于这些统计数据的后续收集,这可能需要花费大量的重复工作。作为一个 DBA,一个综合的 RUNSTATS 建议是有益的,可以避免重复执行 RUNSTATS。
- 查询调优可以识别辅助索引或更改现有索引的需求。通过隔离方式分析查询并没有考虑到索引更改对其他查询的影响,并且可能导致产生太多索引,这会影响数据的维护和管理。
- 为单个查询识别和收集更多统计数据,可能会导致改善一个查询,并对其他查询产生不平衡。“积非不能成是” 的谚语用在客户工作负载中往往并不准确。纠正一个评估错误,可能会暴露未被分析的其他查询错误。
工作负载调优方法
尽管单个查询调优具有上述缺点,但它允许专注于改善最重要的查询的性能。从整个工作负载的角度进行分析时,并不是每一个查询都可以共享与业务相同的重视程度。
可以根据执行计数、累计耗时或 CPU 时间、平均耗时或 CPU 时间等标准,为每个查询分配不同的权重。另一种方法可能是,捕获一些最耗时的 SQL 进行调优,确保样本规模足够大,以便克服与单个查询调优关联的局限性。
无论使用何种标准,一般调优方法至少包含以下四个逻辑步骤:
- 确定要调优的样例工作负载。
- 调优工作负载。
- 审查建议,并应用它们。
- 验证和比较调优之前和调优之后的性能。
步骤 2-4 组成了一个可以迭代执行的调优周期。本文将介绍每一部分。下一节介绍使用 IOQWT 捕获和调优工作负载的一些最佳实践。