SMART 程度更高的 DB2

Sam S. Lightstone,IBM
Guy M. Lohman, IBM
Bryan F. Smith, IBM
Randy Horman, IBM
Jim Teng, IBM

2002 年 12 月

IBM 使 DB2 朝着自我维护的方向发展，这样可以保证帮助 DBA 从容应对他们的工作负载。

IBM 使 DB2 朝着自我维护的方向发展，这样可以保证帮助 DBA 从容应对他们的工作负载。
如果您的数据库象冰箱一样易于管理，它会根据一些按钮的设置自动调整其操作，并且能够启动定期对数据“除霜”的维护操作，而无需您介入，这该有多好？这就是 IBM 自我管理和资源调优（Self-Managing And Resource Tuning (SMART)）项目的目标：降低调优和管理 DB2 通用数据库（UDB）的成本。

尽管数据库的大小近年来增长迅猛，但总体拥有成本（TCO）的主要增长部分是人员成本。要感谢摩尔定律和激烈的竞争，硬件和软件的单位成本在持续下降。但熟练的应用程序开发人员和 DBA 却日益稀少且昂贵。Aberdeen Group 在 1998 年做的研究表明，一个使用了 5 年、拥有 25 个用户实现的先进工业 RDBMS，其培训、维护和实现的人员成本占其 TCO 的 81％。去年，D.H. Brown Associates 的 TCO 报告比较了用于数据仓库和在线事务处理（OLTP）应用程序的两种先进的数据库产品，发现在所有情况下，人员成本都占据 TCO 一大部分。

数据库功能的升级和对数据库大小、连接性、可用性和异构性的不断增长的需求增加了管理负担。包含几十太字节（terabyte）数据的数据仓库并不罕见。诸如 SAP 之类的流行应用程序通常创建为数超过 20,000 的表，并同时支持几千个用户。系统设计人员要考虑到关于硬件平台、模式设计、约束和参照完整性、主键和索引、实现的视图（materialized view）、表如何在磁盘中分配，以及不共享、全部共享或 SMP 群集拓扑的复杂决策。设计之后，数据库要求大量的人员投入，以进行构建、配置、测试、调优和操作。DBA 要处理表的重新组织、数据统计信息收集、备份控制、安全性建模和管理、灾难恢复规划、配置和性能调优、问题分析等事项。

这些压力从数据库扩展到所有 IT 部门。现代硬件和软件系统的复杂性和 IT 专业人员的日益短缺威胁到了 IT 业的发展，就象用于自动电话呼叫的电子交换技术出现之前，人工电话接线员的短缺威胁到电话网络的发展一样。

IBM 研究主管 Paul Horn 去年发表了一则关于自主计算（autonomic computing）的声明，以促进自我管理、自我配置、自我修复、自我优化和自我保护程度更高的硬件和软件系统的研究和开发。术语“自主”源于人体的神经系统，该系统会自动调节心跳和呼吸、愈合伤口、处理食物，以及执行其它基本功能。Horn 写道：“自主系统必须预测需要，并且允许用户将精力集中到他们要完成的事情上，而不是考虑如何组建计算系统来让他们完成任务。”

DB2 SMART 项目只是 IBM 正在进行的众多自主计算项目中的一个。其它项目包括一个类似的针对 WebSphere 的 SMART 项目，以及针对 IBM 服务器的 eLiza 项目。今年年初，IBM 任命了一个负责自主计算的副总裁（Alan Ganek）来促进和协调自主计算的各项倡议。

SMART 世界中的 DBA
DB2 SMART 项目旨在创建一种技术，以可以减少 DB2 操作中的人工介入和成本。它建立在 DB2 现有自我管理技术上，并对其进行扩展，它将使 DB2 可以：

在系统正在使用时，动态调整每个配置参数
根据工作负载，扩展和收缩内存使用
自动概要分析工作负载，建议并创建索引、分区、群集、摘要表等以提高性能
自动检测维护操作（包括重新组织、统计信息收集、备份、复制和重新联编）的需要、估计其持续时间、并对其进行调度
观察实际性能并利用该信息来改进操作
当性能不符合 DBA 的期望时，建议应采取的操作
预测问题，如内存不足或磁盘空间限制，并提前通过传呼或电子邮件通知某人。

这些发展会意味着 DBA 的消亡吗？不。但它们将意味着重复管理任务的终结，让 DBA 将更多时间花到新的应用程序上，而花较少时间去“灭火”。DBA 将有机会在实现建议之前先对其评估并进行选择。一旦满意了系统建议，DBA 就可以让 DB2 来自动采取操作，然后只需听取报告就行了。

DB2 什么时候将管理自己呢？并不是一个特性或功能就可以使 DB2 具有自主能力。但是，IBM 正在开发几项新技术，它们将在今后的发行版中提供。在近期，您就会看到支持更多自主行为的基础设施特性、引导您做选择的向导和评估可能性的建议程序。但在设计过程中，当自主意识象现在的性能和可用性一样普及之前，SMART 项目将不会结束。

SMART 项目涉及到两个 IBM 研究中心、两个 IBM 开发实验室和一个 IBM 的高级研究中心，它是高校、政府以及公司研究和开发机构的协作成果。它还是跨平台的，最初针对 z/OS 与 Linux、Unix 和 Windows。总之，IBM 打算最终在所有平台上支持相同的能力。

DB2 的自主特性
虽然 DB2 还不象冰箱一样易于管理，但它已经有了一些自主特性。我们将首先回顾 DB2 for z/OS and OS/390 以及 DB2 for Linux、Unix 和 Windows 中现有的一些特性。

Query Optimizer。DB2 Query Optimizer 会自动确定执行声明性 SQL 查询的最佳方法。它结合使用将用户（或查询生成器）编写的查询转换成标准的、易于优化的查询的功能强大的查询重写规则以及生成和评估大量用于执行查询的备用计划的详细的成本模型。优化器会自动确定任何现有的自动摘要表（AST），也叫作实现的视图，是否对查询有益。如果是这样，优化器会路由该查询，以在不改变用户应用程序中查询的情况下使用 AST。它使用有关每个表的大小和每一列分布的统计信息来建立用户可能提交的任何查询必须处理多少行的模型。它甚至会自动分析计算 CPU 速度、存储设备、和网络连接的机器群集（在不共享环境中）或站点（在联邦环境中）等因素，根据机器环境修改其成本模型。DB2 for Linux、Unix 和 Windows 平台中的 Query Optimizer 甚至有一个元优化器，它使用试探性规则来自动确定何时查询太复杂而无法使用动态编程来枚举可能的连接（join）顺序。发生这种情况时，优化器用“贪婪”算法在每次迭代中选择最“便宜”的连接，这种算法可以节省优化时间和间隔。

自动选择并行度。在多 CPU 平台中，查询优化包括自动设置和调整查询和实用程序的并行度（执行操作所需的独立任务的数量）。对于任何查询，DB2 会分析如何访问表以及瓶颈在哪里，并在没有外部输入的情况下，在运行时选择最佳的并行度。复杂的查询可以从查询内的并行处理中获益，而简单查询则可以避免并行处理基础结构的开销（上下文切换和通信成本）。在执行每个查询时确定它的最佳并行度消除了编译期间复杂的负载均衡需求。

DB2 装入实用程序利用一系列并发（并行）的子任务进行数据预取、格式化和写到磁盘存储器。通过估量表的特征和 CPU 的数量，该实用程序会自动确定缓冲和排序所需的内存，以及所需子代理的数量，以实现最佳 I/O 和 SMP 并行性。

检测部分磁盘写操作。DB2 使用专利技术来保护数据完整性，即当它从磁盘读取页面时，自动检测不完整 I/O 产生的受损数据。该方法利用一致性位来验证正在从磁盘读入缓冲池的页不是一个部分页，或者尚未受到损坏。当读入页面时，DB2 会验证所有位是否相同。如果有些位不相同，DB2 会指出这是一个部分页面写操作或磁盘损坏。

应用程序控制和调优。应用程序控制最重要的方面是控制应用程序的使用和使可用的资源最大化。DB2 提供了一种机制，根据已提交准备执行的和目前正在执行的应用程序消耗的资源来控制这些应用程序。第一种控制叫作“预测性控制器”，因为它使用 Query Optimizer 对每个查询希望消耗的相关资源的估计，以限制大量涌入的查询，或可能使服务器饱和的长时间运行的查询。第二种叫作“反应控制器”，因为它监控实际消耗的资源，以防止失控的查询浪费资源。示例包括运行了太长时间的查询、读取或修改太多页面的查询，或消耗太多锁而没有执行 COMMIT 的查询。这两种控制器都提供了一种有效的方法来防止您的系统受到一些错误应用程序的影响，这些应用程序会使当前正在执行的查询缺乏资源，并增加系统颠簸。

在 z/OS 平台上，Resource Limit Facility（RLF）包含了预测和反应控制器。z/OS Workload Manager 向连接到 DB2 的应用程序提供可以在最少使用的 DB2 成员上运行的能力，因此还可以均衡 Parallel Sysplex 上的入站工作负载。

在 Linux、Unix 和 Windows 平台上，DB2 Query Patroller 提供了预测控制器；而反应控制器就简单地称为“Governor”。根据 DBA 为每个用户建立的策略的指导，Query Patroller 使用当前系统负载和优化器对入站查询的估计来安排其执行的优先次序并进行调度。查询执行完成后，作为一个可选项，可以通过邮件或者利用 Job Accounting 表中的项来触发自动用户通知，以允许跟踪数据库使用的历史记录。Governor 是由一个配置文件控制的，该配置文件包含了一些规则，用于限制由特定应用程序或用户所消耗资源（如 CPU 时间、运行时间、读或写、或者获得的锁）。可能的规则操作包括提高或降低应用程序的优先级，或者迫使它离开系统。

Performance Expert。新的 DB2 Performance Expert 提供了被动监控，而且还将跟踪和监控数据收集到一个性能数据仓库中。DBA 可以查询这些捕捉到的数据。可以根据历史数据（与系统更改相关，如增加存储器）运行一组报告，以标志警告并给出建议。另一个 Performance Expert 组件 — Buffer Pool Analyzer 收集缓冲池活动数据，并建立缓冲池中的对象更改模型（包括大小），这样 DBA 就无需更改生产系统就可看到结果。IBM Data Management Tool 组中的其它工具提供了捕捉并分析性能数据和提供查询建议的能力。请参阅参考资料以获取更多信息。

DB2 for LINUX、UNIX 和 WINDOWS
几个现有特性是专用于每个平台的。我们将从专用于分布式平台的特性入手。

Index Wizard。DB2 Index Wizard 于 1999 年引入 V6，它根据自动捕获或者用户提供的一个或多个 SQL 查询（包括 INSERT 、 UPDATE 和 DELETE ）的工作负载，建议表的索引，从而辅助数据库的物理设计。Index Wizard 利用 Query Optimizer 的详细性能模型，建议和评估最有希望的候选索引，从而提高搜索效率。使用 Query Optimizer 代码本身避免了维护多余的外部代码，而且确保了优化器将实际为工作负载选择建议的索引。Index Wizard 是一个作为客户机应用程序运行的实用程序，它以两种新的 EXPLAIN 方式调用 DB2 编译器： RECOMMEND INDEXES 和 EVALUATE INDEXES 。在 RECOMMEND INDEXES 方式中，优化器为可以应用断言的列的各种组合创建一个“虚拟索引”描述符，创建“有趣的”顺序（用于 ORDER BY 、 GROUP BY 或连接），或者对给定查询提供仅索引访问。然后它派生出这些虚拟索引的统计信息，并经历正常的查询优化的整个过程，以挑选使用虚拟和实际索引的最佳计划。如果所选择的计划引用虚拟索引，那么就将它作为候选索引报告给客户机实用程序，以供 EVALUATE INDEXES 方式考虑。Index Wizard 建议要创建的索引、估计它们的存储大小和它们对指定工作负载中的每个查询的性能影响，并且标识不再需要的索引。

如果在 z/OS 上捕获到工作负载并且在 Linux、Unix 或 Windows 上创建了模型数据库，那么可以在 DB2 for z/OS 平台上使用 Index Wizard 来建议或确定索引。同一技术会建议一些您随后在 z/OS 平台上可以创建的索引。有关更多信息，请参阅参考资料。

服务实用程序（db2support）。为了简化服务状态中数据收集和问题确定的过程，DB2 包含了一个名为“db2support”的实用程序，该实用程序会自动确定 IBM Service 需要什么诊断信息，然后收集这些信息，并将信息打包到一个 zip 文件中。该文件包含了硬件特征（包括 CPU、网络和存储器的详细信息）、操作系统和数据库产品级别和配置，以及许多数据库诊断文件和控制结构。系统描述数据以 HTML 格式存储，以便于浏览。此外，db2support 提供了一个可选交互方式，在该方式中，会通过关于问题方案的特定问题的决策树指导用户。实用程序和操作员之间产生的对话会捕获到一个 XML 文件中。所有这些信息都收集到一个文件中，并经过压缩，以便用于有效传输。通过自动收集和捕获一组综合系统信息，这个实用程序简化了产品支持，并减少了解决问题的时间。

Performance Configuration Wizard。Performance Configuration Wizard 自动确定超过 35 个配置参数的最佳值，这些配置参数对于系统性能至关重要，它们包括主要数据库操作（如数据高速缓存、排序和联网）的系统内存分配和操作参数（如数据库服务器代理、I/O 子代理的数量和日志记录频率）。要这样做，它根据自动检测出的数据库系统的特征（包括系统 RAM、存储磁盘的数量和 CPU 的数量）和调用程序为响应一些简单问题而指定的工作负载的特征，评估每个配置参数的设置。用户问题假设了最低的技能级别。Performance Configuration Wizard 派生出每个配置参数的值，作为每个系统特性的加权函数。但是，数据库“消费者”（数据高速缓存、排序、网络内存等）的系统内存分配必须看作是零和博奕。这些参数是根据数据库体系结构和可用的系统内存在组合模型中确定的，该模型考虑到了每个消费者的约束。

可以通过图形界面或可编程 API 来调用该向导。许多将 DB2 用于其关系存储的商业数据库应用程序会通过可编程 API 调用这个建议程序。

今天的 Z/OS
现在，让我们按照类别来看看 z/OS 平台上 DB2 的一些现有自主特性。

系统监控和控制。每个 DB2 新发行版都有被称作系统参数或 ZPARM 的新开关和按钮。在 V7 中，可以在线更改这些参数中的绝大多数。可以从这个特性开发其它许多自主特性，因为可以在不中断应用程序的情况下更改这些参数。V7 还引入了 Real Time Statistics。作为对 RUNSTATS 数据的补充，这些统计信息记录了自上次 REORG 或 RUNSTATS 之后 INSERT 、 UPDATE 和 DELETE 的次数。DB2 还跟踪已更改页面的数量和百分比。可以使用这些统计信息来确定是否要执行 REORG 、 RUNSTATS 或 COPY 实用程序。

z/OS 平台上的 DB2 拥有 z/OS Workload Manager。Workload Manager 提供了操作系统级别的基于目标的性能管理，它允许混合工作负载以共享资源，并防止长时间运行的工作（如一些查询或实用程序）影响短时间运行的工作的性能。这是通过使用周期老化技术来“扼杀”长时间运行工作实现的。

DB2 for z/OS 中的其它系统管理特性包括自动排序技术选择、主 DB2 地址空间中的自动存储池收缩和自适应缓冲区管理。自适应缓冲区管理包括了诸如根据访问路径的当前特征动态地启用或禁用预取操作和实时更改预取数量等技术。

操作维护和恢复。与 RUNSTATS 和 COPY 结合使用， REORG 实用程序可以与更新正在重新组织的对象的应用程序同时运行。这种能力适用于表空间和索引。为了帮助启用自动操作，COPY 和 REORG 实用程序允许您指定控制实用程序行为的标准。例如，如果已经更新的页面少于 2％，您也许想要跳过获取表空间或索引的映象副本。如果更改的页面多于 2％，但少于 15％，您也许想要获取增量副本。如果更新的页面多于 15％，您也许想要获取完整的映象副本。这些阈值是在实用程序调用时指定的参数。同样，您可以提供 REORG 实用程序的标准。

在恢复操作期间，如果确定某个映象副本已遭损坏，DB2 会自动后退到另一个映象副本。如果它检测到一个不完整的或受损的页面，DB2 就会启动恢复进程来自动修复这种情况。在 Parallel Sysplex 中，如果 Coupling Facility 由于某种原因发生故障，系统会在不中断应用程序的情况下，自动切换到另一个 Coupling Facility。

许多 z/OS DBA 使用 DB2 Automation Tool 检测异常情况并自动生成可以调度的实用程序作业。

最新的发展
最新系列的新 DB2 工具和 DB2 UDB V8.1 for Linux、Unix 和 Windows 结出了 DB2 SMART 项目工作的最初果实。我们将讨论这些新特性的示例。

Recovery Expert。DB2 Recovery Expert 于今年年初发布，它组合了日志分析、过滤的日志子集创建和对象定义版本资源库，让用户可以指定恢复目标。该工具分析可用的恢复资产，并建议要选择的技术。例如，如果需要将一组表恢复到 5 分钟以前，Recovery Expert 可能会建议对日志进行分析，以便生成 UNDO SQL 来实现恢复。虽然宣称这个产品只适用于 DB2 for Linux、Unix 和 Windows 平台，但现在它的许多组件都可以作为独立产品在 z/OS 上使用：DB2 Log Analysis Tool、DB2 Change Accumulation Tool 和 DB2 Object Restore Tool。

Maintenance Advisor。Maintenance Advisor 是一个跨平台工具，它检查 DB2 统计信息（z/OS 上的实时统计信息）并建议应该运行什么维护实用程序。它可以构建脚本或 JCL，并且可以调度维护任务。Maintenance Advisor 包含了 GUI 工具以及存储过程 API 和命令行界面。

DB2 V8.1 中的 SMART
DB2 UDB V8.1 for Linux、Unix 和 Windows 平台包含了许多新的 SMART 特性。以下是主要特性的示例。

Configuration Advisor。Performance Configuration Wizard 经过重大改进，作为 Configuration Advisor 出现。使用新算法的最新实验已经产生了巨大的进步，尤其是对于 OLTP 和批处理数据库系统。图 1显示了使用业界标准的 OLTP 基准测试的两个实验的结果。实验是对两个不同的工作负载执行的。对于每个工作负载，都使用缺省“现有的”设置、由新的 Configuration Advisor 建议的设置和由给定几天时间调优数据库配置的专家确定的设置来测量系统吞吐量。对于这两个工作负载，Configuration Advisor 的设置在某些方面优于缺省设置。更令人吃惊的是，对于第一个工作负载，Configuration Advisor 实现了专家所实现的吞吐量性能的 91.3％，而对于第二个工作负载，这个数字是 98.4％。

图 1 ：比较 Configuration Advisor 设置与缺省和专家设置的系统吞吐量性能。

自主健康评估。在 SMART 项目早期，对 DBA 的调查显示，一个常见难题是能否容易地评估 DB2 是否达到了最佳性能，如果没有，如何确定最佳补救措施。SMART 项目对这个问题的回答是一个名为 Health Monitor 的新工具，它包括一个在数据库引擎中以无人照管方式运行的监控程序代理和一些用于获取健康状态、解决方案建议和监控程序配置的工具。Health Monitor 寻找数据库中的不健康信号，通过电子邮件消息、传呼或写到通知日志中的记录发出健康警报。当发出健康警报时，它还可以运行校正脚本或任务。支持工具（用于查看实时和历史健康警报、显示和启用可选的建议解决方案操作的执行，以及支持配置更改）有 Health Center GUI 应用程序（桌面和 Web 版）、命令行处理器命令和“C”API。Health Monitor 涵盖了如存储器使用情况、高速缓存和排序的内存消耗、日志记录行为和应用程序并发性等数据库的健康问题。

即将问世
这些最新公布的 DB2 中的自主特性只是 SMART 团队添加到 DB2 后继发行版中的一系列自主技术的开始，从除去 DBA 任务中苦差事的关键基础结构能力和工具开始，发展到把 DB2 提升为下一级别系统自动化和自控的更成熟的工具。虽然我们不能提供当前研究项目的完整描述，但项目的这个子集提供了 DB2 将来能力的一些有趣内幕。

Design Advisor。正如我们前面注意到的，Index Wizard 只建议要创建或删除的索引。但选择索引只是 DBA 要做出的众多物理数据库设计决策之一。冗余地实现 AST 中的聚合查询结果可以大大提高查询的性能，但也会消耗磁盘空间，而且当派生出它们的表被更新时，这些结果也需要更新。在 DB2 UDB for Linux、Unix 和 Windows V8.1 中，已经将 AST 扩展成包含了非聚合查询和重命名的实现的查询表（MQT），以便更精确地反映这个更广泛的作用。相同的功能即将在 z/OS 平台上出现。

即使对于知识丰富的 DBA，明智地选择要定义哪些 MQT 也是一个难题。而 MQT 就象存储表本身一样，也需要索引以便正确执行。此外，在分区环境中，必须在节点中间最优地对这些 MQT（和所有基表）进行分区，以便最小化执行连接、聚合等操作的查询所需要的再分区。即使经验丰富的专家也很难预测这些设计决策的交互方式。

Linux、Unix 和 Windows 平台上的 Index Wizard 将被扩充，用最佳 MQT 和用于每个存储表分区的建议，扩展其索引的建议。为更好地反映这个更广泛的职责，它的名称已经改成了 Design Advisor。和以前一样，Design Advisor 将利用 DB2 Query Optimizer 的详细成本模型来建议每个查询的最佳候选，并有效地评估全局解决方案。新的 MQT 组件将利用新的多重查询优化来寻找可以让众多查询受益的 MQT，而不是只预先计算一些关键查询。作为可选项，它还可以使用对选定候选 MQT 的内容进行的采样来更好地估计它们的最终大小。新的分区组件将利用 Query Optimizer 为每个查询计算好的值得关注的分区，为每个这样的分区生成备用计划，然后让 Query Optimizer 选择首选计划。然后，对于每个表，它只使用这些候选分区中的一个来评估工作负载中的所有查询，以寻找最佳的全局解决方案。

在线模式更改（模式进化）。这个特性是 DB2 for z/OS 中自主基础结构的关键部分之一，它让您可以在不发生中断或使包或视图无效的情况下，更改几乎所有模式问题。为什么这很重要？成功的应用程序不是静态的。表会被修改，列也可能会从表和索引中被删除，列的数据类型会改变，索引需要重命名，需要添加分区等等。必须在线做这些更改。在某些情况下，在 REORG 实用程序可以将所有对象修复成单一版本的模式之前，需要做多次更改。

实用程序增强。该特性也在 DB2 for z/OS 上，它期望实用程序（如 LOAD RESUME）可以进行在线增强，而且期望当允许完全在线 SQL 访问时拥有构建索引的能力。统计信息建议程序将告诉您是否应该收集未建索引列上的列统计信息或未均匀分布的数据，就象在 DB2 for Linux、Unix 和 Windows 平台上执行的一样。（目前，DB2 for z/OS 上的 RUNSTATS 只收集已建索引列上的这些统计信息。）您是否曾经想要获取已分区的表，并调整分区的范围键，以便更平均地均衡所有分区？好，请寻找 REORG 实用程序的再均衡分区扩展。

用于安装的 Managed System Infrastructure（msys）。Msys 正在研究之中，预计它向 z/OS 平台提供 Configuration Advisor 类似的功能。通过类似于面试的过程，可以用适当的系统参数设置安装新的 DB2 子系统或数据共享组，其耗时只是传统安装的一小部分。

利用实时统计信息。由于在提供基础结构的 z/OS 上提供了实时统计信息（即将在 Linux、Unix 和 Windows 平台上实现），下一步就是使用它们。我们以前提到的 Maintenance Advisor 恰好可以做这件事。也可以让 DB2 Automation Tool 来使用这些统计信息。

更多特性
我们讨论的特性只是通过 SMART 进行研究的特性中的一个小示例。正在研究工作中的还有：

表分组。您是否曾想拥有发现或描述可用作其它过程输入的一组相关对象的能力？对，这就是 Data Management Tool 组所要做的。这个分组功能可以从系统管理的参照完整性（RI）、触发器、绑定包中的 SQL 语句，甚至是 DB2 日志中发现表的关系。也可以将用户管理的 RI 定义成这种分组工具。结果是对象关系资源库，它可以由其它工具（如 DB2 Recovery Expert）使用。这样，当恢复两个表时，Recovery Expert 会提醒您，最近创建的第三个表拥有对其中一个表的系统管理的 RI，而且在最近一次检查 DB2 日志时会找到第四个表，它也要与第一个表在同一个工作单元中被更新。Recovery Expert 将帮助您确定在恢复操作中要一起恢复的表的集合。正在开发的其它工具也将利用这个分组信息。

在查询优化中学习。DB2 Query Optimizer 使用的成本模型取决于对计划的每一步中要处理的行数的估计。这个所谓的基数模型反过来取决于数据库的统计信息，该统计信息用于估计查询中每个断言的选择度。每次更新之后更新统计信息都会产生一个锁定热点，这样就会用 RUNSTATS 实用程序定期更新它们。因此，统计信息可能会暂时过时或不完整。Query Optimizer 将每个断言的选择度相乘，当然要假设所有断言都是独立的。当违反这一假设时，作为 Query Optimizer 模型基础的假设偶尔会产生错误，这些错误足以对计划的选择产生负面影响。

作为 SMART 项目一部分开发的 DB2 Learning Optimizer（LEO）可以自动地自我验证 Query Optimizer 的基数模型。LEO 使用执行模块收集计划的每一步的实际基数。查询完成之后，LEO 会将实际数量与优化器的估计值做比较，以生成调整因子，以便在将来拥有类似断言的查询优化中使用。这样，随着时间的推移，LEO 通过累计它查询最多的数据库的附加统计信息，真正从它的错误中吸取了教训。请注意，LEO 的方法非常通用，而且可以改正任何操作序列的结果，不仅仅是单个表的访问或甚至是断言的应用。虽然 LEO 首先在 DB2 for Linux、Unix 和 Windows 上建立了原型，但该方法可用于所有 DB2 产品。

Meta-Optimizer。DB2 for Linux、Unix 和 Windows 平台让用户调整每个查询经历的优化数量。如果用户指定优化级别 5（系统缺省值），DB2 就会使用有关查询复杂程度和数据库大小的简单的直观推断来进行自动调整。正在开发的针对这个 Meta-Optimizer 的更复杂模型可以自动且可靠地确定每个查询的优化的适当数量。

再接再励
您在 DB2 中享受到的许多自我管理特性只是冰山一角 — 也许还有更多您没有意识到。在即将问世的发行版中，可以在 DB2 中找到更多 SMART 特性，并且可以从许多其它 IBM 硬件和软件产品中找到不断增加的自主行为。当然，最终目标是减少您需要查看的，并在幕后处理一切 — 就象您的冰箱那样。

作者简介
Sam S. Lightstone是 IBM 加拿大多伦多实验室的 DB2 性能和高级技术经理，负责 DB2 SMART 项目。可以通过 light@ca.ibm.com与他联系。

Guy M. Lohman是 IBM 阿尔马登研究中心（位于加利福尼亚州圣何塞市）的高级优化经理。可以通过 lohman@almaden.ibm.com与他联系。

Bryan F. Smith是 IBM 硅谷实验室（位于加利福尼亚州圣何塞市）Data Management Tools 组的资深技术成员。可以通过 bfsmith@us.ibm.com与他联系。

Randy Horman是 IBM 加拿大多伦多实验室负责管理工具开发的经理。可以通过 horman@ca.ibm.com与他联系。

Jim Teng是 IBM 硅谷实验室（位于加利福尼亚州圣何塞市）的一名杰出的工程师，它专长于 DB2 for z/OS and OS/390。可以通过 jteng@us.ibm.com与他联系。

返回顶部

下一篇：自动化的将来 >>