通过 Optim Query Tuner 调优 SQL,第 3 部分: 工作负载捕获和调优

了解如何监控和调优查询与工作负载,从而提高应用程序的性能

本系列的前一篇文章介绍了访问路径的概念,向您展示了如何在 Optim Query Tuner 中读取访问路径图,并详细介绍了调优每个查询的方法。在第 3 部分中,将会介绍调优 SQL 工作负载的方法。本文将了解如何使用 InfoSphere® Optim™ Query Workload Tuner 从不同来源捕获 SQL 工作负载、收集统计数据和索引分析、比较访问计划,并执行计划锁定和​​计划管理。本文的目标是确保 IBM® DB2® 优化器获得它所需要的信息,从而制定出基于最佳性能的 DB2 查询决策,本文还提供了一些建议,以帮助 DB2 优化器改进访问,比如收集必要的统计数据和创建最佳索引。

Terry Purcell, 高级技术人员, IBM

Terry PurcellTerry Purcell 是 IBM 硅谷实验室的一名高级技术人员,他是 DB2 for z/OS Optimizer 的首席设计师。作为客户、顾问和 DB2 开发人员,Terry 在 DB2 数据库管理和应用程序开发方面拥有二十年的经验。



Kendrick Ren, 咨询软件工程师, I.B.M.

Kendrick Ren 照片Kendrick Ren 是 IBM Optim Query Tuner 和 Optim Query Workload Tuner 产品的技术领导,他在 IBM 多伦多实验室外工作。自从 2004 年团队组建以来,他就一直致力于这些产品的前身(DB2 Optimization Expert and Optimization Service Center 产品)的研发工作。Kendrick 与使用这些产品的客户和业务合作伙伴密切合作,并在查询优化领域协助他们。在加入 Optimization Expert 团队以前,Kendrick 从事了两年 IBM WebSphere Commerce Server 产品的工作。



Jun Liu, 咨询软件工程师, IBM

Jun LiuJun Liu 在 IBM 中国实验室是 IBM Optim Query Tuner 和 Optim Query Workload Tuner 产品的技术领导之一。他在 2005 年加入了这个团队,并一直致力于这些产品的前身(DB2 Optimization Expert 和 Optimization Service Center 产品)的研发工作。他现在专注于与数据库索引优化和 SQL 访问路径调优领域相关的工具的开发。



Kewei Wei, 咨询软件工程师, IBM

Kewei WeiKewei Wei 在中国是 DB2 for z/OS L3 技术支持和开发团队的技术领导。Kewei 已在 DB2 for z/OS 查询优化技术方面工作了 8 年,在 DB2 应用程序性能调优方面拥有丰富的经验。



2012 年 10 月 15 日

免费下载:IBM® Optim® Development Studio and Optim® pureQuery Runtime 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

在第 2 部分中,介绍了单个查询调优的方法。利用 IBM InfoSphere Optim Query Workload Tuner (IOQWT) 等查询调优工具的支持,应用程序开发人员或数据库管理员可以分析单个查询的访问路径,并收集更多统计数据,重写查询或更改数据库设计,从而提高性能。

工作负载性能调优的目的是:确保应用程序满足服务水平协议,并确保系统的最佳总拥有成本 (TCO)。本文将提供一种方法,使用 IBM InfoSphere Optim Query Workload Tuner (IOQWT) 进行工作负载调优。


工作负载调优与查询调优

单个查询调优关注特定查询的性能,而工作负载调优专注于工作负载中所有查询的性能。无论执行工作负载调优还是单个查询调优,目标都是相同的:提高性能。与单个查询调优相比,工作负载调优有许多优势:

  1. 提高所有查询的性能,可以降低 TCO 并增加满足业务服务水平要求的机会。然而,一个应用程序可能包括成千上万个查询,甚至更多,为每个查询执行单个查询调优,这是不实际的。
  2. 要确定哪些统计数据将有利于每个查询,以及有利于这些统计数据的后续收集,这可能需要花费大量的重复工作。作为一个 DBA,一个综合的 RUNSTATS 建议是有益的,可以避免重复执行 RUNSTATS。
  3. 查询调优可以识别辅助索引或更改现有索引的需求。通过隔离方式分析查询并没有考虑到索引更改对其他查询的影响,并且可能导致产生太多索引,这会影响数据的维护和管理。
  4. 为单个查询识别和收集更多统计数据,可能会导致改善一个查询,并对其他查询产生不平衡。“积非不能成是” 的谚语用在客户工作负载中往往并不准确。纠正一个评估错误,可能会暴露未被分析的其他查询错误。

工作负载调优方法

尽管单个查询调优具有上述缺点,但它允许专注于改善最重要的查询的性能。从整个工作负载的角度进行分析时,并不是每一个查询都可以共享与业务相同的重视程度。

可以根据执行计数、累计耗时或 CPU 时间、平均耗时或 CPU 时间等标准,为每个查询分配不同的权重。另一种方法可能是,捕获一些最耗时的 SQL 进行调优,确保样本规模足够大,以便克服与单个查询调优关联的局限性。

无论使用何种标准,一般调优方法至少包含以下四个逻辑步骤:

  1. 确定要调优的样例工作负载。
  2. 调优工作负载。
  3. 审查建议,并应用它们。
  4. 验证和比较调优之前和调优之后的性能。

步骤 2-4 组成了一个可以迭代执行的调优周期。本文将介绍每一部分。下一节介绍使用 IOQWT 捕获和调优工作负载的一些最佳实践。


捕获工作负载进行分析

在本文的上下文中,工作负载包括应用程序的所有识别的 SQL 语句、相应的执行数据和 EXPLAIN 信息。执行数据中包含运行时间、CPU 时间、查询执行计数等。EXPLAIN 信息指的是 DB2 用于执行 SQL 的访问路径,例如,联接顺序、联接方法、访问方法,等等。

许多用户可以选择从动态的语句缓存中捕获一个动态的 SQL 工作负载,并从 DB2 目录中捕获一个静态的 SQL 工作负载。DB2 将动态 SQL 暂时存储在动态语句缓存中,这样可避免为重复执行相同的 SQL 而进行新的准备。一旦 DB2 在缓存中发现相同的 SQL 实例,它就不会为 SQL 重新生成执行计划,而只是重新使用缓存的计划。用户可以启用对动态语句缓存的跟踪,并允许 DB2 存储执行数据。以下是使用 IOQWT 的一个示例。

数据库管理员启动 IOQWT 并单击 Data Source Explorer 中的 Start Tuning 菜单,如图 1 所示。

图 1. 启动 IOQWT 进行工作负载捕获和调优
该图显示了启动 IOQWT 进行工作负载捕获和调优

Query Tuner Workflow Assistant 将被打开,用户可以从 Statement Cache、Catalog Plan 或 Package、QMF 等多个来源中开始捕获 SQL。本示例是从语句缓存中捕获。

图 2. 从 Statement Cache 中捕获 SQL
该图显示了从 Statement Cache 中捕获 SQL

上面的示例演示了在 WebSphere Application Server 上运行的应用程序,它使用 JDBC 来连接 DB2 9 for z/OS®。比如说,用户想找到系统中消耗大于 1 秒 CPU 时间的所有查询,并对这些查询执行进一步的分析。首先,用户选择工作负载的来源(在左侧);在选择了来源之后,圈住 Statement Cache 并将其突出显示为选中的来源。用户定义上述的 Accumulated CPU。这是用于捕获累计 CPU 时间大于 1 秒的所有 SQL,结果也将根据 CPU 时间进行排序。本示例使用了一个之前保存的筛选器,但首次使用时会要求创建一个新的筛选器。在后面的示例中将介绍如何设置筛选条件。就在屏幕截图中的筛选器下面,用户单击按钮来启用统计数据的收集,这意味着启用了动态语句缓存的跟踪。最后,用户单击 Capture Now,并捕获在接下来的一个小时内执行的、累计 CPU 时间大于 1 秒的所有语句。

图 3. 在表中列出的被捕获的语句
该图显示了在表中列出的被捕获的语句

最后,用户从应用程序中捕获最耗时的四个语句,并开始分析对应用程序性能影响最大的那些语句。

在另一个示例中,DBA 在处理一个银行应用程序项目,以支持个人在线电子交易。DBA 发现应用程序中的某些查询并没有高效地执行,其响应时间也无法接受。借助于其他监视工具,DBA 已经发现这些查询都来自某个特定用户,并且监视数据显示出较高的 IO 时间。DBA 定义一个筛选器,Primary authority ID (PRIMAUTH) 是 USER1,它们的平均 getpages (AVG_STAT_GPAG) 大于在监视工具中所显示的值,即为 10000。根据平均运行时间对结果进行排序,用户可以开始进行进一步的审查并调优它们。

图 4. 定义筛选条件
该图显示了定义筛选条件
图 5. 选择排序列
该图显示了选择排序列

在动态语句缓存中,可以在您的应用程序中设置 STMT_TOKEN,这样您就可以区分只来自这个特定应用程序的所有语句。例如,在Java™ 技术中,客户端可以使用 JDBC API 来设置 STMT_TOKEN,如:((DB2Connection) conn).setDB2ClientProgramId("Your application identifier");

其他编程语言可能也有类似的 API 来设置这个应用程序标识符。这可以帮助避免缺失动态语句或捕获冗余的动态语句。其缺点是,使用该 API 需要更改代码。


从计划或包中捕获工作负载

许多应用程序使用存储在 DB2 目录中的静态 SQL。静态 SQL 已经在系统中绑定,并且在绑定/重新绑定的过程中已生成相应的访问路径。在从一个计划或包中捕获 SQL 语句时,结果可能会包含 SQL 文本和 EXPLAIN 数据(如果绑定选项包含 EXPLAIN YES,DB2 将 EXPLAIN 数据存储在 PLAN_TABLE 和其他解释表中)。与从动态语句缓存中捕获相类似,IOQWT 也提供了方便的筛选器,以帮助用户捕获所需的静态包查询。

在该场景中,用户最近在生产系统中部署了应用程序。在应用程序上线之前,他想检查某个特定包中的所有静态 SQL 语句,并找出可能因为可疑的访问路径模式(如表空间扫描、非匹配索引扫描、排序等)造成访问计划不理想的那些语句。

图 6. 定义从目录中捕获数据的筛选器
该图显示了如何定义从目录中捕获数据的筛选器
图 7. 定义筛选条件
该图显示了定义筛选条件
图 8. 定义访问模式的标准
该图显示了定义访问模式的标准

上述场景对于从计划/包中捕获和查找次优查询来说是典型的。然而,用户经常想要使用此特性,以便将注意力集中在与单个表相关的所有静态 SQL 上,从而发现调优的机会,例如特定于该表的索引。有两种略微不同的场景:一种是捕获依赖于某个特定表的所有包;另一种是只捕获引用某个特定表的静态 SQL,而不是从依赖于该表的包中捕获所有的 SQL。如果用户希望把重点放在整个应用程序中,他们可以键入如下所示的标准。

图 9. 根据包引用的对象定义筛选器
该图显示了根据包引用的对象定义筛选器

筛选器将捕获依赖于一个对象(如表、视图、存储过程等)的所有包。即使这些语句与对象没有直接的关系,在这些包中的所有静态 SQL 都将被提取。如果用户只想捕获相关的静态 SQL,他需要将自己的包与 EXPLAIN YES 绑定,并在允许根据成本或对象筛选的另一个页面上定义筛选器。

图 10. 根据 SQL 语句引用的对象定义筛选器
该图显示了根据 SQL 语句引用的对象定义筛选器

IOQWT 将认真检查所有静态 SQL 的 EXPLAIN 数据,如果一个 SQL 的访问计划中包含访问这个特定的表,SQL 将被提取到捕获结果中。


如何有效地执行工作负载调优

捕获工作负载之后,第二步是尝试调优工作负载。IOQWT 提供了若干个工作负载顾问,如统计顾问、索引顾问、查询顾问和访问路径顾问。这些顾问分析 SQL 语句、EXPLAIN 数据和运行时数据,然后根据内置在工具中的专业知识提供建议。例如,统计顾问会提供有关收集缺失或冲突的统计数据(如表基数或列基数)的建议,DB2 优化器使用这些数据生成一个高效的访问计划。在对工作负载运行顾问程序之前,用户必须确保 EXPLAIN 数据是可用的。通常,如果从动态语句缓存或计划/包中捕获工作负载时没有与绑定选项 EXPLAIN YES 进行绑定,那么用户必须先解释工作负载。

应该注意的是,若在动态语句中为查询发出一个 EXPLAIN STMTCACHE,这会导致现有的访问计划信息外部化。这就意味着动态语句缓存的 EXPLAIN 将提取现有的访问计划。对于静态 SQL,发出 EXPLAIN PLAN 或 EXPLAIN ALL,将导致生成一个新的访问计划,这可能并不是保存在目录中的计划。DB2 10 for z/OS 添加 EXPLAIN PACKAGE 语句,如果该包被绑定在 DB2 9 或更高版本中,该语句将提取现有的访问计划信息。这两种方法都将填充 PLAN_TABLE,从而实现进一步的访问路径分析。

图 11. 高效保存解释数据的 EXPLAIN 选项
该图显示了高效保存解释数据的 EXPLAIN 选项

如果只有一些语句缺失了 EXPLAIN 数据,用户可以选择解释部分语句,或在没有这些语句的情况下继续进行分析。如果工作负载已被解释,并且由于统计数据发生更改,用户想重新解释,那么用户可以选择保留、替换或整合 EXPLAIN 数据。上面的屏幕截图突出显示了这些选项。

在运行顾问程序之前,用户应该注意顾问程序执行的顺序。一般情况下,统计顾问是第一选择,以保证 DB2 优化器有足够的信息实现其访问计划选择。至少有将近一半的 SQL 性能问题是由于缺乏统计数据所造成的。建议查询顾问是第二个执行的顾问程序,因为查询的修订,特别是谓词的修订,可能会严重影响到索引选择和优化器的可用选项。例如,第 2 阶段的谓词被重写为可索引的谓词,现在可能会利用一个现有的索引。其余的两个顾问程序可以在统计和查询顾问之后运行。然而,顾问程序的运行可以是一个迭代过程,因为创建新索引可能需要重新运行统计顾问,以识别和收集缺失的索引统计数据。否则,DB2 可能会由于缺失的统计信息而获得有关新索引的误导性信息。一个典型的示例是,若缺少索引的集群比,可能会导致通过索引对数据页的随机 I/O 成本的错误估算。

下面是为调优捕获的工作负载示例。用户从动态语句缓存中捕获应用程序 SQL 语句,并单击 Save All to Workload 创建工作负载。

图 12. 捕获的工作负载具有一些高成本的语句
该图显示了捕获的工作负载具有一些高成本的语句

第二个步骤是解释工作负载并调用统计顾问。

图 13. 统计顾问的建议
该图显示了统计顾问的建议

统计顾问显示,该工作负载中有 11 个表存在潜在的统计问题,也提供了 RUNSTATS 语句。如果用户想看到建议特定统计的详细原因,他们可以查看下面的详细报告。

图 14. 统计顾问的详细报告
该图显示了统计顾问的详细报告

如果用户对特定的表或列等的建议存有疑问,他们可以在报告中轻松地搜索名称。报告中列出了详细原因,如上图所示。有时,主要的原因是缺失、冲突或过时的统计数据所造成的。如果统计顾问发现潜在的数据倾斜或具有相关性,它会建议针对这些感兴趣的列或列组收集分布统计。

考虑到系统上还有其他工作,第三步是在方便的时候收集统计数据。在收集统计数据之后,用户使用第一个步骤中的方法再次捕获应用程序,以验证可能的改进。在下面的屏幕截图中,工作负载 DW3_B 在用户应用统计顾问的建议之前被捕获,而工作负载 DW3_Sn 在用户执行 RUNSTATS 作业之后被捕获。我们可以看到运行时间已经从 471.20s 缩短为 383.40s,CPU 时间已经从 127.21s 缩短为 93.17s。

图 15. 通过统计顾问比较调优结果
该图显示了通过统计顾问比较调优结果

第四步是重新解释工作负载,并运行索引顾问,以检查是否可以建议任何索引。

图 16. 索引顾问的建议
该图显示了索引顾问的建议

如果创建了建议的索引,用户则可以看到预计性能改进和预计磁盘空间消耗。显示某些工作负载的特征(如表基数、累计总成本和表引用计数)是为了审查索引建议。下面是索引建议的面板。

图 17. 深入研究建议的详细信息
该图显示了深入研究建议的详细信息

当用户查看每个索引建议时,他们可以查看受影响的语句和建议的原因,以验证该索引建议是否合理。此外,用户还可以通过对表进行排序来选择关注需要审查的重要的表,如下面突出显示的部分。

图 18. 根据表的重要性选择建议
该图显示了根据表的重要性选择建议

用户可以选择根据累计总成本对表进行排序,累计总成本的意思是涉及到该表的所有语句的总成本之和。通常情况下,在创建额外的索引时应考虑这些表,以提高整体性能。由于本文的重点之一是要确定缩小必要的调优工作范围的方法,以这种方式根据对象来锁定查询目标,是实现这一目标的另一种选择。在上面的示例中,用户只需选择三个表,因为它们在工作负载中占了最大比例的总成本。

第五步是重新解释工作负载,并再次调用统计顾问。其目的是为新添加的索引收集统计数据。用户可以看到新索引的 RUNSTATS。

图 19. 为新添加的索引收集统计数据
该图显示了为新添加的索引收集统计数据

最后一步是验证该应用程序的性能是否得到了提高。以下是新捕获的运行时数据,显示了在创建新索引后,性能得到了明显的提高。

图 20. 索引顾问的结果比较
该图显示了索引顾问的结果比较

在用户创建所有建议的索引并收集新索引的统计信息之后,最新捕获的工作负载是 DW3_In。运行时间从 383.40s 减少为 8.99s,CPU 时间从 93.17s 减少为 8.13s。


访问路径的稳定性

对于数据库管理员来说,所面临的最大挑战之一是管理成千上万个查询的访问路径,以维持其应用程序性能的稳定性。访问路径回归是应用程序性能退化的最常见原因之一。访问路径的变化有多种原因,如:

  • DB2 版本迁移或新的维护部署。
  • 统计数据更新,以反映数据量的变化。
  • 硬件升级。
  • 系统参数发生更改。
  • 物理数据库设计发生更改。

在绝大多数情况下,如果完整且准确的统计数据可用,DB2 优化器可以为每一个新的绑定/重新绑定产生相同的或更好的访问路径。然而,访问路径仍然有可能回归。

本文一直侧重于通过前瞻性分析来提高应用程序的性能,并提供最佳索引和统计,以便向 DB2 优化器提供一个访问路径选择的稳定基础。这些步骤也可能导致在统计数据或索引不是最优时减少回归。

并非所有 DBA 都有时间和技能来执行这种前瞻性分析。即使他们这样做了,仍然有可能存在访问路径的回归。因此,最好能了解有哪些其他解决方案可以减少遇到访问路径回归的问题,或者是可以执行影响分析,并找出能够迅速回到之前的良好性能的解决方案。

DB2 9 和 10 for z/OS 提供了一组有用的特性,可以帮助稳定跨 BIND 和 REBIND 的访问路径。DB2 9 for z/OS 提供了基本的计划管理特性,实现了跨 REBIND 的静态访问路径的备份和恢复(切换)。而 DB2 进一步扩展了这一特性,利用 APREUSE 选项支持之前跨 BIND/REBIND 重用的计划。

数据库管理员可以利用这些特性和 IOQWT 解决方案来管理访问路径,并实现稳定的应用程序性能。


比较访问路径

为了执行应用程序性能的风险评估,您应该能够预测在发生重要的环境变更后可能会发生哪些访问路径变更。IOQWT 提供了一个解决方案,在包级别或工作负载级别比较访问路径,以便在数千个查询中识别变更。

REBIND 之前和之后的包访问路径比较

为了管理 REBIND 之后的性能回归风险,建议在 REBIND 之前执行一次风险评估。您可以执行以下任务进行评估:

  • 在 EXPLAIN 表中保存感兴趣的包的当前访问路径信息。
  • 将感兴趣的包 BIND 到不同的集合 ID,并将新的访问路径信息填充到 EXPLAIN 表中。
  • 比较当前的访问路径和新的 BIND 操作所生成的访问路径,并识别访问路径的变更。
  • 对访问路径变更进行分析,并对回归的访问路径执行调优。

在后面的章节中,使用一个示例来展示如何对样例包 OQTPACK4 进行访问路径比较的流程。样例包 OQTPACK4 包括在集合 ID “PROD” 下绑定的五个查询。

填充访问路径信息

在 BIND/REBIND 上指定 EXPLAIN(YES),这是一个不错的做法,这样就可以在 EXPLAIN 表中保存访问路径信息。在 DB2 10 for z/OS 中,如果您原来没有利用 EXPLAIN(YES) 保存解释信息,可以执行 EXPLAIN PACKAGE 语句来提取 PLAN_TABLE。然而,必须已经在 DB2 9 或 DB2 10 for z/OS 上绑定了该包,并且只保存了 PLAN_TABLE 信息,而不是其他详细的解释表数据。

例如,下面的语句将填充访问路径信息:EXPLAIN PACKAGE COLLECTION PROD PACKAGE OQTPACK4。

通过将包绑定到不同的集合 ID 下并进行 REBIND 后,您可以获取访问路径信息。例如,您可以将包绑定到集合 ID “TEST”:BIND PACKAGE(TEST.OQTPACK4) MEMEBER(OQTPROG4)。

比较各集合 ID 之间的访问路径

IOQWT 提供了一个包级别的访问路径信息比较函数。您可以从一个工作负载调优项目中启动该函数。

图 21. 在 IOQWT 中启动工作负载比较
该图显示了在 IOQWT 中启动工作负载比较

IOQWT 将创建一个用于比较的工作负载。

图 22. 创建一个用于比较的工作负载
该图显示了创建一个用于比较的工作负载

通过输入来源集合 ID 和目标集合 ID,IOQWT 将生成一个访问路径比较结果的报告。

图 23. 查看比较结果
该图显示了查看比较结果

在报告中,将突出显示含有访问路径变更或预计成本变更的查询。即使报告显示新 REBIND 所产生的访问路径成本低于之前的访问路径,您也应该检查这些访问路径变更,因为新访问路径的预计成本可能是根据不准确的统计数据进行计算的。在 IOWQT 中,您可以详细查看查询的访问路径。

图 24. 比较访问计划的细节
比较访问计划的细节

如果没有发现明显的访问路径变更,您可以将 REBIND 安全地提交给集合 PROD。如果识别出任何访问路径回归,您可以利用计划管理函数执行单独的查询调优或锁定/回退回归的查询。请参阅 “利用 DB2 10 计划管理锁定访问路径” 和 “利用 DB2 9 经典计划管理进行回退” 部分,了解如何防止访问路径回归。


工作负载访问路径比较

准备动态查询的访问路径比较,比包级别的静态比较需要更多的准备,因为动态查询的访问路径没有存储在 DB2 目录中。您可以按照以下流程准备动态查询的访问路径比较:

  1. 创建一个动态查询的工作负载。
  2. EXPLAIN 工作负载,然后再进行可能会触发访问路径变更的任何活动(RUNSTATS、创造新的索引、应用 PTF 等)。
  3. 在完成可能会触发访问路径变更的活动后,再次 EXPLAIN 工作负载。
  4. 比较工作负载的最新访问路径和之前的访问路径。
  5. 对访问路径变更进行分析,并对回归的访问路径进行调优。

一般情况下,创建动态查询的工作负载后,在 IOQWT 中对工作负载级别的实际访问路径进行比较的后续过程与包级别比较的过程类似。例如,您可以在一个时间点从动态语句缓存中创建一个工作负载,然后比较在另一个时间生成的 EXPLAIN 结果。

图 25. 比较 EXPLAIN 快照
该图显示了比较 EXPLAIN 快照

即将讨论的 DB2 for z/OS 计划管理特性并不适用于动态查询。因此,更有可能需要使用单个查询调优来克服动态查询的回归,或使用优化提示来锁定它的访问路径。


利用 DB2 10 计划管理锁定访问路径

考虑到应用程序稳定性这个业务需求,客户可能不希望承担跨静态的 BIND 或 REBIND 的访问路径变更所带来的任何风险。

DB2 10 for z/OS 提供新的 REBIND(和 BIND)选项 APREUSE。在 APREUSE(ERROR) 选项下面,只有当包的所有访问路径都可以重用时,才接受 REBIND。这是使用 REBIND 防止访问路径发生变更的最谨慎的方法。例如,如果您想重用以前绑定的访问路径,您可以 REBIND 包 PROD.OQTPACK4,如下所示:REBIND PACKAGE(PROD.OQTPACK4) APREUSE(ERROR)

应该注意的是,虽然 APREUSE 可以减少您的访问路径回归的曝光,但它也限制了访问路径改进的机会。然而,当客户还不愿意寻求访问路径的改进机会时,这是一个可行的方法。这些机会可能会推迟到能够实现更多前瞻性分析的时候。

如果包最后绑定在 DB2 9 上,APREUSE 只可以在 DB2 10 中的第一次 BIND/REBIND 时使用。在 DB2 10 中的首次执行 BIND/REBIND 之后,后续的 BIND/REBIND 可以使用 APREUSE。


利用 DB2 9 经典计划管理进行回退

当访问路径的回归确实发生时,特别是在没有足够的时间进行深入分析时,很高兴知道您可能有一个备份,可以快速恢复。在这种场景中,假如一个新的 REBIND 可以开始成功运行包,您可以利用 DB2 9 计划管理特性迅速回退到以前的良好性能。

为了启用计划管理实现回退的能力,您必须指定 PLANMGMT(BASIC) 或 PLANMGMT(EXTENDED) 绑定选项,或将 ZPARM PLANMGMT 设置为 BASIC 或 EXTENDED。在 DB2 9 中,PLANMGMT 的默认值是 OFF,但在 DB2 10 中,默认值是 EXTENDED。例如,如果之前的 BIND/REBIND 使用 PLANMGMT=BASIC 来完成,您可以通过以下的 REBIND 命令将运行时结构回退到之前的 BIND/REBIND:REBIND PACKAGE(PROD.OQTPACK4) SWITCH(PREVIOUS)

此计划管理切换功能在 DB2 8 至 9 的迁移、8 至 10 的迁移、或 9 至 10 的迁移中可用。


结束语

本文强调了与工作负载调优有关联的益处,以及 IBM InfoSphere Optim Query Workload Tuner 如何成为许多步骤的简化和自动化工作的一个必不可少的部分,从而成功地改善您的应用程序的总拥有成本。

参考资料

学习

获得产品和技术

  • 使用 IBM 产品评估试用版软件 构建您的下一个开发项目,可直接从 developerWorks 下载获得。
  • 现在您可以免费使用 DB2。下载 IBM 软件下载:IBM DB2 Express-C 10.1,这是一个面向社区的 DB2 Express Edition 的免费版本,提供了与 DB2 Express Edition 相同的核心数据特性,并为构建和部署应用程序提供了坚实的基础。

讨论

  • 查看 developerWorks 博客 并加入 developerWorks 中文社区,developerWorks 社区是一个面向全球 IT 专业人员,可以提供博客、书签、wiki、群组、联系、共享和协作等社区功能的专业社交网络社区。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=840439
ArticleTitle=通过 Optim Query Tuner 调优 SQL,第 3 部分: 工作负载捕获和调优
publish-date=10152012