DBA 的美味甜点
Paul C Zikopoulos, IBM 数据库全球销售支持小组, IBM Toronto
Jessica Escott, DB2 Administration Tools 开发人员, IBM Toronto
2004 年 8 月
在 IBM DB2 Universal Database V8.1 中实现了许多功能强大的工具和监视器，这样 DB2 数据库可以真正开始监视自己的健康状态，而不必依赖 DBA。DB2 Stinger 重新设计了工具集，其监视功能更加优良，还增加了新的健康数据获取界面，从而丰富和扩展了 DB2 目前的自主计算功能。
简介
自主计算是 IBM® On Demand 商业模型中的核心领域。在 IBM DB2® Universal Database™（DB2）V8.1 中实现了许多功能强大的工具和监视器，这样 DB2 数据库可以真正开始监视自己的健康状态，而不必依赖数据库管理员（DBA）。DB2“Stinger”（本文发表之日在 www.ibm.com/db2/stinger上可找到 Sting open beta）重新设计了工具集，其监视功能更加优良，还增加了新的健康数据获取界面，从而丰富和扩展了 DB2 目前的自主计算功能。
我们撰写本文时考虑了几种用户的情况：熟悉 DB2 Health Monitor Center 的用户将从对一些 DB2“Stinger”新特性的概述中获益；尚未有机会试用这一工具的用户将会看到，随着 DB2 V7.2 服务终结期的来临，有足够吸引人的理由迁移到 DB2 V8.1 上来；其他用户如果有兴趣，也可以看看 IBM 是如何在实际产品中实现自主计算的能力的。不论您兴趣何在，本文的目的都是让您更好地理解 DB2 的现状和未来以及关于自主计算的一般原则。
DB2 与自主计算计划
本文的目标不是详细介绍自主计算的每一个细节；而是着眼于介绍自主计算的新特性（它们是 DB2“Stinger”的一部分）和一些已有的特性。不过本节将花费一些时间谈一谈一般性的自主计算知识，帮助您快速了解或更新背景知识。理解自主计算是理解这些新特性和已有特性有效性的关键。比如说，我们并不尝试取代 DBA。（这句话不仅仅是声明，我们希望某些 DBA 能轻装上阵，以开始试用这些新特性。）
了解自主计算的概念最简单的方法是考虑人体的神经系统，看看它是如何监视并调解自身环境的。我们喜欢进行大量的锻炼，人体和锻炼的关系很好地解释了自主计算的概念。
当我们开始跑步的时候，通常是从快步走开始。这个时候，我们的身体开始感觉到一种更加兴奋的动作，并请求将更多的氧气输送的我们的肌肉中；当然了，这是通过血液流速的增加实现的。当我们开始轻轻慢跑时，我们的身体开始出汗，以减轻慢跑引起的体温升高的状况；这时我们的身体感觉到一种更加兴奋的环境，从而根据这种环境对自身的参数（如呼吸频率、体内温度等等）进行调整。最后，当我们用最快的速度奔跑时，我们的肺会用尽可能快的速度吸入氧气，来支持整个过程。过了一会儿，有个人不跑了；不过这和自主计算没有关系（也许这种情况具有一般性的意义，但是和自主计算无关。）
前面的例子传达了一条信息：没有人告诉自己的身体（或者相互告知）开始加快呼吸，或者开始出汗，身体仅仅是根据一种动态的环境作出反应。所以现在我们知道，我们的身体就是具有自主性的（真是幸福啊），现在想象一下，如果数据库也可以具有这些性质，那该多好。想了解更多有关自主计算的知识么？请参阅下面参考资料一节中列出的文章。
比如说，如果出现大量排序操作，导致排序堆被溢出到磁盘上，那么性能就会受到影响。现在假设数据库足够聪明，可以感知到大量排序溢出到磁盘上，这时可以呼叫数据库管理员，把问题告诉他们。然而更好的方式是在大多数堆持续保留在磁盘上时，可以（根据 DBA 的设置）启动一段脚本，动态地改变给堆分配的内存数量，或者临时性地从其他较不活跃的堆中偷窃一些内存（这是 DB2“Stinger”中的新特性）。这就是自主计算！
在自主计算计划中，IBM 的目标是提供新的技术，以增加人类干涉对计算机系统的影响力，同时通过使用自动化、智能建议和学习，降低干涉的次数和复杂性。
图 1显示了自主计算的发展情况：
图 1. 自主计算的发展
任何计算机资源，不管是独立的软件应用程序、网络、还是整个系统，都在从人工控制向自动化管理方向发展。要学习更多有关自主计算成熟层次的知识，并了解每一个层次的典型特点，可参阅参考资料一节。
目前，DB2 的自主计算处于自主化发展过程中的可预见阶段（Predictive，即第三层）。DB2 Health Monitor 监视系统并提出修改建议。出现异常时，只有您编写了相应的脚本，DB2 才会自动进行操作（这一点使得 DB2 很像是处于自主计算系统的第 4 层）。
DB2 的目标是让 DBA 能够通过一组预先根据业务需求和 IT 基础设施定义的策略，为系统指定一些约束和目标。最终创建一个有感觉的，可以对外界产生反应的 DB2 系统。
理解这一概念的一个重要方面是，自主计算不是要取代 DBA。很显然，这种情况永远也不会发生。这种创新性的技术尝试达到的目标是改变 DBA 不断地将信息搜集到 DB2 监视器中，然后在出现问题时告知您这种工作方法。坦白地讲，DBA 面前的工作已经很多了，当您展望未来对数据持久化的需求时，DBA 们将无法跟上这个步伐。随着保存、分析和度量数据的不断增加，DBA 们每天必须完成的工作已经很多。DBA 们需要关注如何启用数据、设计数据和建立模型等等，DB2 让他们有机会实现这些目标。
回到跑步的例子上。我们在全速奔跑时不会持续检查体温和脚上的水泡。如果这些健康方面的警报拉响，我们的身体会用这种或者那种方式告知我们。
所以，从本质上讲，DB2 将系统健康诊断的模型翻转过来，原先是由 DBA 通过在不同的时候运行不同的监视器来搜集潜在和已有的问题，然后对大量数据进行分析，从中找出不健康的迹象（由于技巧水平和直觉的不同，这种分析不具有任何一致性），现在则是 DB2 自己监视健康状况，然后在满足潜在或已有非健康状态条件时通知指定的人员。
DB2 根据异常进行管理（management-by-exception）的模型是通过 DB2 的健康监视器实现的。它为 DBA 卸下了重担，使其不必了解如何设置监视环境、如何决定监视的内容、数据的含义是什么、数据之间的相关性如何等等。健康监视器知道监视什么、何时监视、如何评估、如何解决问题、如何采取可能的行动等等。当异常情况发生时，DBA（通过 SMTP 服务器、电子邮件、ADMIN 通知日志、NET SEND 消息等方式）得到通知，并获知如何处理。DBA 只需要安装 DB2 UDB V8，然后就可以去从事其他工作了，直到收到 DB2 UDB 通知为止。所有这些方法都有助于降低 TCO。
DB2 中的健康状况指示器
健康状况指示器是健康监视器的基础。每一个指示器都映射到数据库中特定对象（如实例、数据库、表空间等等）的某一方面的健康状况。
在 DB2“Stinger”中，DB2 监视的对象层次已经通过三种不同的健康指示器类型扩展为 4 种不同的层次（如 图 2所示）。
图 2. DB2 所监视的对象层次
DB2“Stinger”中的三种健康状况指示器包括：
DB2“Stinger”中的大多数指示器都是基于阈值的，它们关联着与系统健康状态有关的一些上界和下界，如 图 3中所示：
图 3. 基于阈值的指示器
例如，日志利用率是一个设有上界的阈值指示器。当日志利用率增长时，这些类型指示器的状态从正常变化到提醒、报警。当设有下界的指示器（例如，缓存命中率指示器）的值降低时，它将标识为不健康。
DB2“Stinger”中包括了一些新的健康类别指示器（如下所示）。DB2 “Stinger”中，总共有 18 个基于阈值的指示器、6 个基于状态的指示器以及 4 个基于集合状态的指示器，划分为 11 个不同的类别。所有这些健康指示器都在 DB2 System Monitor Guide & Reference中有详细的介绍。
- 应用程序并发（如死锁率）。
- DBMS（如实例的运行状态）。
- 数据库（如数据库运行状态）。
- 日志（如日志利用率）。
- 内存（如监视堆的利用情况）。
- 包与目录缓存，以及工作空间（如包高速缓冲区命中率）。
- 排序（如溢出排序的百分比）。
- 表空间存储（如表空间利用率）。
- 数据库维护（如辨别是否需要进行数据库备份；这一类别是 DB2 “Stinger”中新增的）。
- 高可用灾难恢复（如 HADR 日志延迟；这一类别是 DB2 “Stinger”中新增的）。
- 联邦数据库（如昵称状态；这一类别是 DB2 “Stinger”中新增的）。
通过 Health Center、CLP、或基于 C 的 API，可以为对象级或特定对象的健康状况监视器配置默认设置。例如，可以使用这三种方法中的任意一种实现如下配置：
- 阈值（提醒级和报警级）。
- 灵敏度（该值在生成提醒、报警或注意警报之前改变成“alertable”状态所需的最少时间；有了这种设置，临时性的使用峰值将不会引发警报。这是 DB2“Stinger”中新参数）。
- 应该求这个指示器的值，还是应该忽略。
- 针对提醒、报警或注意警报所采取的行动。这些行动中可包括任务、基于 DB2 或操作系统的脚本。
- 当发出提醒、报警和注意警报时是否应该运行一组脚本或任务。
在 DB2“Stinger”的开发过程中，Health Center 的配置接口已经进行了可用性测试，对其采取的修补措施可以对健康状况对象进行更好的分组，这样您进行设置时就更加容易了（请参阅 图 4）：
图 4. Health Center 快速启动面板
DB2“Stinger”的 DBA 可以使用 Health Indicator 配置快速启动面板深入查看或修改任何健康状况指示器设置。例如：
图 5. 健康状况指示器设置
配置通知可以通过 Health Center、CLP、或基于 C 的 API 实现。在 DB2“Stinger”中增加了通知故障诊断程序，以保证正确地设置通知，并且在生成警报之前正确地使用通知。
DB2 如何收集与健康相关的信息
DB2 按照一种不可配置的预定义时间间隔来收集与健康有关的信息（不过您可以配置 Health Center 的信息多长时间更新一次）。到达某个间隔级别时，健康监视器使用基本的快照监视器（您不需要打开任何东西）、本地操作系统 API （针对与文件系统有关的指示器）、存储在表中的统计信息等等，对系统的健康状况进行评估。一旦获得健康数据，就将收集到的评测结果与健康配置中的设置进行比较。
当分析基于状态的指示器时，如果结果不是正常值，就生成一个注意警报（attention alert），并运行任何配置的动作。如果基于阈值的指示器达到警报条件，就激活适当的 Warning 或 Alarm 行为和/或警报。
一旦超过某个间隔级别，健康监视器就转入“睡眠”状态，当下一个间隔到来时再唤醒。如果前一个间隔中识别出来的警报在下一次间隔到来时依然存在，那么 DB2 不会再次发出警报，也不会对此执行任何脚本化的行为。如果阈值从 Warning 状态变化到 Alarm 状态，也会正确执行 Alarm 配置中的适当行为。同样，如果某项警报从 Alarm 转换回 Warning，也会执行相应的行为。最后，如果间隔返回的值同时满足 Warning 和 Alarm 报警的阈值，那么只会触发 Alarm 阈值的行为。
图 6 展示了新的 DB2“Stinger”接口，该接口可用于设置突破阈值时的行为。请注意，新的选项和新接口一样允许您定义一组行为，可以在突破 Warning 或 Alarm 阈值时激发这些行为。
图 6. 设置突破阈值时执行的行为
DB2 可以为所有指示器记录下一组与健康有关的数据。典型的健康信息集包括：
- 所记录的值。
- 评估时间戳。
- 警报状态。
- 用来计算所记录的值并最终计算被监视对象健康状况的公式。
- 有关这个指示器的附加信息（包括 DB2 认为是健康的信息等等）。
- 关于以前发出的所有警报的历史记录。
db2.mon_heap_util 指示器的例子如 图 7所示：
图 7. 监视堆利用率的指示器
为了支持新的基于状态集的集合指示器，DB2“Stinger”中增加了一种新的健康数据集，其中包括与特定集合有关的数据，如对象名称、状态、警报时间戳以及其他细节。
DB2“Stinger”在对警报进行分组方面是很智能的。实例、数据库和表空间的警报都使用“最高严重性累积”算法，它可以显示健康指示器（或其子对象的健康指示器）已有的最严重警报。
访问健康数据
有很多界面可用于查看和响应警报和健康信息。特别是可以使用：
- Health Center
- Web Health Center
- Command Line Processor
- 基于 SQL 的函数
- C API
让我们分别研究一下。
Health Center
Health Center（如 图 8所示）是一个图形化的界面，它提供收集 DB2 健康信息的前端工具。Health Center 显示数据库环境的整体状态以及当前的所有警报。Health Center 是一种根据异常进行管理（management-by-exception）的工具，所以只有处于警报状态的健康指示器才是可见的（没有必要将 DBA 宝贵的注意力浪费在不构成问题的事情上）。
图 8. Health Center
在 DB2 V8.1.3 中，Health Center 得到增强，这样，当这个工具启动时，它不会强制连接到所有被监视的实例；而是通过左侧面板上树形视图展开实例健康信息，发生更改。还请注意，红、黄、绿三色的过滤器可用于去除没有问题的对象（这些是 DB2 V8.1.3 的新增特性）。
在 DB2“Stinger”中，健康中心经历了广泛的可用性测试，并利用新的底层接口和更智能的技术重新编写，以便指引您作出最合适的解决方案（更多是关于这些新特性的）。
另一个关键的增强是引入了 Recommendation Advisor。在 DB2“Stinger”之前，正确的行动建议几乎没有区分其权重（即一种行动路线并不会被推荐为比另一种更好），同时还是特定警报的详细信息中的一部分，如 图 9所示：
图 9. 在 Stinger 之前关于正确行为的建议
您可以看到，在这种情况下新任 DBA 要对健康警报作出响应，将会面对何种两难的境地。DBA 是应该增加容量不足堆的容量还是调整工作负荷？哪一种方法才能获得更好的结果？
在 DB2“Stinger”中，新增的 Recommendation Advisor 通过询问 DBA 一系列的问题和优先选择来推荐一种比其他更好的行动路线。Introduction 面板总结了所生成的警报的详细信息。您可以从下面的 图 10中看到为 DBA 提供的注意、报警、或者提醒的信息与细节，同时还有查看异常历史信息的选项。
图 10. Recommendation Advisor
Requirement 面板向 DBA 提出一系列与所生成的警报相关的问题。（我们对下面的 图 11进行了编辑，这样您就可以看到与排序溢出警报有关的所有问题。）
图 11. 排序溢出警报例子
根据 DBA 对该顾问提出的问题所作出的相应回答，Recommendation Advisor 会推荐一条行动路线，以帮助您解决问题。
从 图 12中可以看出，在 DB2“Stinger”中， 根据 DBA 对可用性等特征的优先选择，或以往的调整操作（如运行 Design Advisor）等的不同，DBA 可以获得根据行动路线分级别（它有助于解决该异常）的建议。
图 12. 分级别的建议
现在，DBA 可以从 recommendations 面板中选择一条行动路线，然后开始着手解决问题。例如， 图 13显示，Health Center 推荐了一个新的 SORTHEAP 值（请注意，还可以查看建议的详细信息）。
图 13. 健康中心建议示例
选择调整负载的选项将得到不同的行动路线；在这种情况下，将启动 Design Advisor。（这实际上是当 DBA 点击 Show All Recommendations 按钮时所显示的建议之一。在我们的例子中没有展示 Design Advisor，因为我们在第一个问题中已经指出曾经使用过这个工具。）
图 14. 启动 Design Advisor
对于那些依然相信命令行就是他们喜欢使用的 GUI 的管理员来说（您知道自己是不是这种人），Recommendation Advisor 的所有特性都是通过 DB2 Command Line Processor（DB2 CLP）提供的，如下所示：
图 15. 从 DB2 CLP 中查看建议
CLP 获取的信息与 Health Center 中显示的信息相同。实际上，建议是通过 DB2“Stinger”中的建议引擎在服务器上构建的，并用 XML 文档的形式存储该信息。当从 Health Center 访问这部分信息时，DB2 只是将 XML 文档进行解析并用图形化的方式显示出来，CLP 也使用了同一个文档。
Web Health Center
DB2 Web 工具中也提供了一个 Health Center 版本。可以将它看作“轻量级”的 Health Center。它适用于通常使用完整版的 Health Center，但目前离开了通常访问数据库的位置的 DBA。它可以从任何支持 Internet 浏览器的设备和媒介上访问，包括个人数字助理（PDA）、手机，等等。Web Health Center 提供的功能包括查看某个实例及其数据库对象的警报、查看警报的详细信息以及建议以及连接到 Web Command Editor，其中 DBA 可以远程输入基于 CLP 的命令。
图 16. Web Health Center
命令行处理器
基于健康的信息也可以通过 DB2 CLP，使用 GET HEALTH SNAPSHOT 命令来获得。GET HEALTH SNAPSHOT 命令与 GET SNAPSHOT 命令相似，并且可以在特定的数据库分区上全局使用。这一命令的语法如 图 17所示：
图 17. GET HEALTH SNAPSNOT 命令的语法
很多有经验的 DBA 使用这一方法获取与健康有关的信息，因为它非常简单快速。它获得的数据和 Health Center 相同，但是必须知道语法才能使用。
DB2“Stinger”在这条命令中增加了一个新的关键字。新增的 WITH FULL COLLECTION 选项返回 DB2 中为某个集合健康信息指示器所监视的所有对象的信息，而不论其健康状况如何。（如果没有这个选择，DB2 只会返回处于注意或自动化执行失败状态的集合对象。这个选项只能用在数据库级的健康快照中，因为集合健康指示器只在这一级别上定义。）
这条命令的输出示例如 图 18所示：
图 18. 使用 WITH FULL COLLECTION 选项的 GET HEALTH SNAPSHOT 命令输出示例
SQL 表函数
您也可以使用 SQL 表函数访问基于健康情况的 DB2 信息。SQL 表函数首先在 DB2 V8.1 中引入，并在 DB2 V8.1.2 中为健康监视进行了扩展。这些函数的基本功能是通过 SQL 获取快照信息，并用表的格式显示结果。因为 DBA 不需要用基于 C 的 API 或 JNI 封装程序编程来获取这些信息，所以这种方法很有用处。
系统提供的这三个表函数可以为所有被监视的 4 种对象类型返回与健康有关的信息。这些函数分为如下类别：
- HEALTH_<object type>_INFO：特定对象类型健康快照的头信息；其中包括最高严重警报状态。
- HEALTH_<object type>_HI：所有的健康指示器，包括公式。
- HEALTH_<object type>_HI_HIS：上面的表函数中列出的所有健康指示器的所有历史记录。
其中 < object type> 可以是 DBM（数据库管理员）、 DB（数据库）、 TBS（表空间）或 CONT（容器）中的一种。
下面的例子显示了如何以全局快照的方式为 SAMPLE 数据库的 db.spilled_sorts 选择健康指示器信息：
SELECT * from table ( HEALTH_DB_HI ( ‘SAMPLE’, -2 ) )
as HEALTH_DB_HI WHERE HI_ID = 1003
|
DB2“Stinger”增加了下面的新函数：
- HEALTH_DB_HIC、HEALTH_DB_HIC_HIS……列出集合对象和集合对象历史信息
- HEALTH_HI_REC……用 blob 的形式获取建议信息
HEALTH_HI_REC(IN SCHEMA_VERSION、IN INDICATOR_ID、IN DBNAME、IN OBJTYPE、IN OBJNAME、IN DBPARTITIONNUM、IN CLIENT_LOCALE、OUT REC_DOCUMENT)
下面的例子显示如何以英语的形式获得 SAMPLE 数据库所有分区上的 db.spilled_sorts 的建议：
CALL HEALTH_HI_REC (8010600, 1003, ‘SAMPLE’, 2, CAST (NULL as VARCHAR), -2, ‘En_US’, ?)
|
更多信息请参阅 DB2“Stinger”文档。
基于 C 的应用程序编程接口
最后，您可以使用 db2GetSnapshot C API 与 SQLM_CLASS_HEALTH 或 SQLM_CLASS_HEALTH_WITH_DETAIL 类通过编程获取这些信息。
结束语
我们不可能在本文中对 DB2 的自主计算能力作出评判。我们希望能够展示出目前 DB2 的一些强大特性，并让您体验一下 DB2“Stinger”中的新特性。
关于这种监视机制，人们问的最多的问题就是“性能如何”。我们的设计目标就是监视对工作负载的影响不能超过 1%——我们一直在坚持这个目标。事实上，当关键的自主特性超过这一目标范围时，系统不会缺省强制加以限制，而是给 DBA 返回一条通知，告诉他启用这样的特性（如 DB2“Stinger”中的 DB2 DB2 Activity Monitor ，我们会另行介绍）所带来的潜在性能降级。如果 1％ 的通知/性能损失对您而言不可接受，也可以关闭监视。
实际上，不论 DBA 是有经验的还是新手，不论您的商店有多大规模，都可以从 DB2 的自主计算能力中受益。 |
