Paul Zikopoulos
高级专家, DB2 Competitive Technologies Team, IBM Toronto Lab
2005 年 7 月 21 日

了解 IBM® DB2® Universal Database™（DB2 UDB）V8.2.2 如何通过自安装、自我调优和自我配置数据库更进一步缩短创造价值的时间（time-to-value）的细节。这是三部分系列中的第 1 部分，该系列将深入探讨 DB2 V8.2.2 版本所附带的新功能、特性和益处（以及一些打包更改）。第 1 部分将查看 DB2 V8.2.2 版本中的新管理特性以及打包和授权更改。

简介
2005 年 4 月下旬，IBM 发布了最新版本的 IBM DB2 Universal Database for Linux, UNIX®, and Windows®（DB2）产品 DB2 V8.2.2（对于遵循 Fix Pack 命名约定的人们来说，该产品称作 Fix Pack 9）。

这个最新版本是在 DB2 V8.2 版本（以前称作“Stinger”）的基础上构建的，与 SAP 及其客户的关键关系也推进了其中许多新特性的集成。实际上，DB2 V8.2.2 标志着与 SAP 之间更紧密联系（已经持续了 10 多年）的开始，在 DB2 与 SAP 之间做出了广泛的承诺，扩展了各个方面的业务，包括销售、营销和开发。

您不是 SAP 客户并且疑惑 DB2 V8.2.2 如何可以带来帮助？除了作为 470 亿美元企业应用软件市场中的领头羊，SAP 还拥有 26,000 多位客户，运行着 88700 多个 SAP 软件安装。从用于解决中小型公司需求的不同解决方案到企业级（enterprise-scale）解决方案 —— 即使您不是一位 SAP 客户，也可能会具有相同的兴趣列表（wish-list）。我的意思是，有谁不想要产品更易于使用，具有更少的锁定竞争，最少化存储管理，更易于访问管理数据等呢？十分坦白地说，从来没人问过我 IBM 是否可以使 DB2 更慢一些，或更难于使用，或不那么可用 —— 您应该已经明白了。

现在更是如此，标记 V8 已经逐渐开始代表一种平台，借由该平台，对于您选择用于编程的任何大型机语言，都可以通过引导开发人员的生产力来降低成本，通过自安装、自我调优、自我修复和自我配置数据库来拉平创造价值的时间曲线，而在许多平台上，这一切都是构建在具有卓越性能的高可用、可伸缩的数据库引擎之上的。

这是三部分系列中的第 1 部分，该系列深入探讨了 DB2 V8.2.2 版本所附带的新功能、特性和益处（以及一些打包更改）。我无法涵盖 DB2 V8.2.2 中的每一个细节和功能 —— 即使我编写包含 5 个部分的系列 —— 因此，我决定挑选出我认为 V8.2.2 中所要了解的最重要的特性。

在第 1 部分中，我将大体概览一下 DB2 V8.2.2，讨论一些打包和定价更改，并详细描述许多必然会让数据库管理员（DBA）高兴的新特性。

在该系列的第 2 部分中，我将深入介绍 DB2 V8.2.2 中有益于性能的一些增强，并展示如果空谈不如实践，那么 DB2 V8.2.2 无疑就是用于实践的。除了仅仅对于该版本所取得的性能结果表示欢欣，我还将着重介绍为锁定和多维集群（multi-dimensional clustering，MDC）表而实现的一些特定的增强。

在该系列最后的第 3 部分中，我将讨论用于 Windows 平台的特定增强，并补充一个综合性的小节以包含需要谈论的其他内容。

DB2 V8.2.2 版本概览
那么，您需要 DB2 V8.2.2 的摘要版本吗？DB2 V8.2.2 版本的目标是提供与 SAP 应用程序无缝集成且只需维护最少资源的数据库。我们发现对 SAP 需求的关注有助于争取上千名对于降低其总体拥有成本感兴趣的现有的和潜在的客户 —— 而且，我们已经得到回应！

从高层次来看，DB2 V8.2.2 是一种集成的 SAP 数据库解决方案，用于提供企业特性以简化：

• 安装 通过“默默地”使 DB2 成为 SAP 安装过程的一部分 —— 您可以在 V8.2.2 中隐藏 DB2 安装的所有细节，在需要时，仅仅向终端用户呈现状态条。
• 配置 通过使用新的 SAP DB2 配置“调节器（knob）” —— 一个针对 SAP 环境优化 DB2 的配置参数。
• 存储管理 包含单点管理自动化以及针对数据库的统一页面大小。
• 故障检修 具有一个服务工具，该工具自动收集所有必要的问题判断信息，以便能够更快获取问题的解决方案。
• 并发性 通过用于特定 SAP 并发性优化的增强优化器完成，以助于减少由于锁定造成的竞争或性能下降。
• SAP BW 的高效性 通过关键的 BI 有关对象，如 MDC 表，以获得更快的性能。
• 等等！

打包和定价
虽然本小节中的一些信息不是 V8.2.2 版本中的，但是我认为这些信息有助于您跟上一些已经四处宣布的主要更改 —— 就在该版本发布不久之前。

从 2005 年 1 月 28 日开始，所有 DB2 服务器版本（Express、Workgroup Server、Workgroup Server Unlimited 和 Enterprise Server）都可以将 64 位的存储器模型用于数据库应用程序中。当您围绕具有 64 位支持的 4 路 SMP 机箱上所运行的 DB2 Workgroup Server Unlimited Edition 思考可取的授权考虑时，较之竞争者，那实际上是以极其吸引人的代价获得的数据库。

在 2005 年 5 月，IBM 还宣布了用于双核处理器的新定价图，双核处理器是基于 x86（Intel 的 EM64T 和 AMD 的 Opteron 芯片组）和 OpenPower 710/720 服务器技术的。对于这些架构而言，客户基本上按照物理处理器或处理器上的内核来付款。除此之外，IBM 还宣布了对于静态和动态子容量（sub-capacity）授权（授权一台服务器上的分区）的官方支持，以响应从服务器合并（consolidation）到大型“可分割（carvable）”SMP 服务器的趋势。我已经写了关于这些主题的另一篇文章，其中包括了这些授权更改的所有细节，以及对于技术本身的概述。

从 DB2 V8.2.2 开始，同样可以在 AMD 驱动的 Windows 服务器上与 64 位的存储模型一起使用 DB2 的副本。该支持是在 Microsoft 正式使得支持该处理器架构的 64 位 Windows 副本可用之后实现的。此外，DB2 V8.2.2 还包含了对于 EM64T 的支持 —— Intel 对于 AMD 的 32 位/64 位芯片组互操作性的响应。

Sun Microsystems 最近发布了他们 Solaris 操作环境的版本 10，并包含了对于这一新版本中诸如区域（zone）等关键特性的支持。虽然不支持先在全局区域（global zone）上安装 DB2，然后再继承到其他区域，但在一个或多个本地区域上直接安装 DB2 却没有限制。

您可能意识到了这一点，也可能没有意识到，但是每个 DB2 Connect（从 V8.1.4 开始）或 DB2 服务器（从 V8.1.2 开始）都带有 Mobility on Demand 的免费副本（DB2 Everyplace）。V8.2.2 版本添加了对于最新移动 Windows 平台的支持，包括用于平板 PC 的版本。

最后，SAP 的未来版本将在 SLES 9 上构建，SLES 9 使用 2.6 内核。在 DB2 V8.2.2 之前，DB2 配送为两个不同的安装映像，以用于 IA32 和 x86-64 硬件。为了为 DB2 和 SAP 创造更好的测试环境，DB2 V8.2.2 将为基于 2.6 内核的发行版（即 SLES9 和 RHEL4）配送特定的映像，而为基于 2.4 内核的发行版配送其他映像。

从 DB2 V8.2.2 开始，在 x86-64 或 IA64 硬件上安装用于 Linux 的 DB2 时，您必须确保基于您的发行版的内核级别选择正确的映像。实际上，安装程序将阻止在您的发行版上安装错误的安装映像。图 1 展示了安装程序正阻塞在采用 2.4 内核的工作站上进行的基于 2.6 内核安装映像的安装：

图 1. 确保使用与您的发行版的内核级别相应的映像

提供这不同的映像有助于我们为 SAP 确保更好的操作环境，为处理器利用更新的编译器，以及确保内核级别之间不存在不兼容的问题。

管理增强
该版本中，许多管理增强都是由对 SAP 的关注所驱动的。从更易于访问管理数据到 DB2 数据的“lights-out”存储管理，有许多数据库管理员（DBA）都对 DB2 V8.2.2 中的管理增强兴奋不已。实际上我可以说，除了 DB2 V8.2.2 开创性取得的性能，本小节中所列出的特性总的来说就是该版本的“精华”。

单点存储管理
V8.2.2 版本中，我最喜欢的为 DBA 提供的特性之一就是我将称作单点存储管理（SPSM）的特性。理想情况下，诸如 SAP 等应用程序需要利用高可用和可伸缩的数据存储引擎，该存储引擎对终端用户和管理人员来说是不可见的，并且只需要进行尽可能少的管理干预。

在 DB2 V8.2.2 中，可以为数据库预先定义存储路径，如图 2 所示：

图 2. 通过自动存储创建数据库的 DDL

在 DB2 V8.2.2 使用该语法创建数据库时，就通过将之关联一条或多条存储路径（一条存储路径本质上就是一个文件系统或目录），将数据库创建为自动存储数据库。在这样的数据库中，您可以接着创建称作自动存储表空间（它们仅仅可以作为 DMS FILE 表空间使用）的东西。对于这些表空间，您不要指定用于存储的容器列表。而是由 DB2 基于与该数据库相关联的存储路径自动分配容器，并给定一个可选的初始大小。这些自动存储表空间实际上使用 DMS FILE 基础设施，并默认自动调整大小。基本上，DB2 处理与表空间关联的所有存储管理任务 —— 完全联机并且不需要人工干预。您也可以创建由 DB2 自动管理的默认表空间，但是 TEMPSPACE1 将仍然默认地创建为 SMS 表空间。这一新特性还允许 DBA 使用 SQL API 添加新的存储器。为了使用这个新特性，您必须使用 V8.2.2+ 级别上的新数据库。

DBA 将特别喜欢自动扩展 DMS FILE 表空间的功能。它减轻了监控活动的负担，并且对基于 DMS 表空间缺少已分配存储器的潜在停机做出了响应。它们可以发送增长增量、最大容量、初始大小等特征数据。这些自动存储表空间可以随着您表空间的填满，自动扩展现有的容器（或创建新的）。在 DB2 V8.2.2 之前，只有 SMS 表空间在需要空间时可以自动增长。如果您耗尽了 DMS 表空间上的空间，就会收到一条错误 SQL0289N Unable to allocate new pages in table space。在 DB2 V8.2.2 中，可以自动扩展任何基于 FILE 的 DMS 表空间（DMS RAW 表空间不支持该特性）。现在，不会获得错误 SQL0289N，DB2 将相应地增加表空间中最新范围的容器。

此外，容器中最新范围的自动调整大小将不会导致重新平衡（rebalance），以避免运行时的性能问题（请记住，DB2 V8.1.2 引入 throttling 来控制 REBALANCER 实用程序，因此这里有许多选项）。当然，只有文件系统中存在空间让容器增长，自动调整大小组件才开始起作用。

该特性不是默认启用的，除非使用 V8.2.2 中新的自动存储表空间特性 —— 它才是默认的。通过按照每个分区指定值，分区数据库环境中也支持自动调整大小特性。

对于表空间，CREATE TABLESPACE 命令已经通过 MANAGED BY AUTOMATIC STORAGE 选项进行了更新，以创建各自的这些表空间。如果您没有指定管理选项，这实际上就是新的默认值。

下面的图 3 中展示了 DB2 V8.2.2 中关于自动存储的这些新特性及其选项的一些示例：

图 3. 使用 DB2 V8.2 中一些新的自动存储特性

这是另一个例子，说明了与 SAP 的合作关系如何有助于为 DB2 的更好版本做出贡献。SAP 使用 DMS 表空间，但他们希望其用户拥有更多关于数据库存储模型的易于使用的特性。这个新方法将 DMS 表空间中您所喜欢的所有特性（性能和灵活性）与 SMS 表空间的易于使用（存储分配等）相融合。即使您不使用 SAP，为数据库提供单点存储管理的功能也可以帮助大家。

SAP 调优调节器
为了拉平为 SAP 环境设置 DB2 所用的配置时间，DB2 V8.2.2 引入了一个 SAP 调优“调节器”。DB2 V8.2.2 中为 SAP 工作负载设计了许多内部和外部的特性和更改（该调节器将解决的部分内容也曾包含在前面的版本中）。许多这些特性是通过注册表变量或配置参数来启用的。例如，下列注册表变量都将启用建议在 SAP 环境中使用的特性：db2_reduced_optimization、db2_interesting_keys、db2_correlated_predicates、db2_evaluncommitted、db2_skipdeleted、db2_object_table_entries，等等。

为了使 DB2 上 SAP 的配置和维护更加透明，您可以使用 DB2 V8.2.2 中的 SAP 调优调节器来设置 DB2 环境，以便为 SAP 进行优化。这个“调节器”是作为一个注册表变量 DB2_WORKLOAD 来实现的，您可以将该变量设置为 SAP。若要禁用 SAP 设置上运行的 DB2，就只要将 DB2_WORKLOAD 注册表变量设置为 NULL，并重新启动数据库实例。

该特性减轻了确保为您的环境启用所有 SAP 特性以及为此正确设置相应注册表变量的复杂性。十分简单，只要在 SAP 设置上设置 DB2。在将来，如果我们为 SAP 添加更多增强，在应用升级时，您将不必执行额外的工作，因为您的数据库将被设置为操作 SAP。想一想在微波炉上按下爆玉米花的按钮 —— 您不确定它将如何发生，但是当您将一袋爆玉米花放入微波炉中，并按下该按钮时，将出现完美结果。

您可以使用 db2set -gd DB2_WORKLOAD=SAP 命令来列举这个聚集注册表变量的默认设置，如下面的图 4 所示：

图 4. 使用新的 SAP 调优调节器来获得简单的 SAP 优化

统一的数据库页面大小
许多客户喜欢利用 DB2 支持多种页面大小（4 KB、8 KB、16 KB 和 32 KB）这一优势。取决于应用程序的类型，使用不同的页面大小可以证明非常有益。例如，诸如 OLTP 的应用程序一般受益于较小的页面大小，因为操作趋向于为快速更新单行检索。同时，基于商业智能的工作负载可能受益于较大的页面大小，因为在经常进行扫描、聚集或排序等的一页上可以存储更多数据。客户可能选择利用较大的页面大小以在页面上获得更多数据 —— 例如，16 KB 的页面大小可以支持容量超过 64 GB 的表。

当您在 DB2 中创建数据库时，将默认地创建 3 个表空间：SYSCATSPACE、TEMPSPACE1、USERSPACE1。在 DB2 V8.2.2 之前，SYSCATSPACE 是内部硬编码的，因此是在 4 KB 页面大小中创建的。DB2 同样总是需要一个也是 4 KB 页面大小的系统临时表空间。出于这些理由，在 DB2 中创建新数据库时，会创建一个支持 4 KB 页面的默认缓冲池。

这意味着如果客户需要为数据库利用不同的页面大小，就必须处理混合页面（mixed-page）环境（可以获得性能益处）和随之而来的管理复杂性。如果客户需要强制实施统一的页面大小（假设他们需要使用 8 KB 页面大小），就可以删除 USERSPACE1 表空间，并用该页面大小创建新的表空间 —— 但是他们仍然无法改变 SYSCATSPACE 表空间，或者改变必须存在一个至少 4 KB 临时表空间的事实。最终的结果是，如果客户需要为其环境使用统一的页面大小，则必须管理至少 2 种页面大小。

DB2 V8.2.2 增加了用一个不同于 4 KB 的初始页面大小（您可以选择 DB2 所支持的任何页面大小）创建数据库的能力。这使得您可以选择需要的任何页面大小，并且在整个数据库仍然维护一个缓冲池和统一的页面大小。在用统一的页面大小创建数据库时，只需要一个匹配该页面大小的缓冲池（即使它不是 4 KB）。例如，如果用 8 KB 页面大小创建一个新的数据库，那么所有表空间默认的缓冲池将是 8 KB。

出于信息化目的，DB2 V8.2.2 中添加了一个名为 PAGESIZE 的新数据库配置参数。如图 5 中所示。

图 5. 在数据库中使用统一的页面大小

为了不将事情弄复杂，而是针对某种工作负载，我们已真正看到了通过统一页面大小带来的性能增长，因为没有将内存分成几段。您必须亲自体验您的应用程序、数据、工作负载以及这个新特性。

在一次扫描中为声明的全局临时表进行 CREATE INDEX 和 COLLECT STATISTICS
DB2 在 V7 中 引入了声明的全局临时表（DGTT），然后在 DB2 V8.1 将其特性进行了扩展。DGTT 的 V8.1 实现包含了在全局临时表上创建索引，以及支持对其执行 RUNSTAT 实用程序以便优化器更好地理解其发行版的能力。当使用大型 DGTT 时，统计数据和索引对于性能是至关重要的。

在 DB2 V8.2.2 中，DGTT 得到了增强，因此您可以在 DGTT 上通过一条命令创建索引并收集统计数据：CREATE INDEX WITH COLLECT STATISTICS。这条新命令允许您在对基表的一次扫描中收集统计数据，并构建索引，而不像这些特性的以前实现那样需要进行两遍扫描。这将为操作节省大量时间，特别是对于通常要广泛使用 DGTT 的大型数据仓库环境而言。图 6 中展示了这条新命令的例子。

图 6. 在对基表的一次扫描中收集统计数据和创建索引

更易于访问 DB2 管理信息
DB2 V8.2 中的许多命令都有它们自己的 CLP 语法和相应的 API；然而，没有一种通过 SQL API 调用 DB2 命令的标准方法。因为许多命令都有基于 C 的 API，所以这使得用基于 Java 的编程来执行命令特别艰巨，因为必须在 JNI 包装器中包装这些命令。

DB2 V8.2.2 现在以存储过程的形式提供了一个类似 SQL 的接口，可以用于向 DB2 传递一些（很快就会增长为一系列）DB2 CLP 命令，而无需使用迂回方法。基本上，这些存储过程充当了 CLP C API 的包装器，并在动态结果集中返回操作结果。

DB2 V8.2.2 是第一个可以通过存储过程处理 CLP 命令调用的版本。新的 ADMIN_CMD 存储过程基本上充当了 CLP 的包装器（它甚至包括分析器）。在 DB2 V8.2.2 中，通过 ADMIN_CMD 例程支持下列命令：

• DESCRIBE
• REORG INDEXES
• REORG TABLE
• UPDATE DATABASE CONFIGURATION
• RUNSTATS
• PRUNE DATABASE HISTORY
• EXPORT（仅用于服务器端 —— 命令中使用的路径必须是服务器上有效的全限定路径，且该路径必须可通过设防的（fenced）用户 ID 访问。）

ADMIN_CMD 例程驻留在 SYSPROC 模式中，并且在 DB2 V8.2.2 级别的任何新数据库中进行自动创建。如果您已经有一个存在的数据库，并需要使用该存储过程所提供的功能，就需要在安装 DB2 V8.2.2 之后使用 db2updv8 实用程序更新您的数据库。

ADMIN_CMD 存储过程也利用 SQLCA 支持，该支持是为 DB2 V8.2 中的存储过程添加的。这就允许将 SQLCA 信息从管理 API 返回给调用该管理命令的 SQL 接口。

这个新的基础设施在许多方面都有益于客户机。除了能够适合跨家族产品的实现基础，如果将来向任何命令添加新选项，客户机都只要更新传递给存储过程以加以利用的字符串变量。不需要迁移目录，或学习新符号，而最好的一部分就是，如果添加了任何选项，现有的脚本将总是继续工作。

图 7 展示了从命令编辑器（Command Editor）输入 CALL ADMIN_CMD('DESCRIBE SELECT * FROM EMPLOYEE') 命令的例子：

图 7. 使用 ADMIN_CMD 命令调用 CLP 命令

DB2 V8.2.2 还带来了快照监控 UDF 的增强。在 DB2 V8.2.2 之前，一些监控 UDF 和存储过程都不包括各自应用程序编程接口（API）所返回的某些信息。为了交付与 DB2 V8.2.2 中其他访问方法类似的一组函数，已经添加了一组新的例程以确保所返回的所有信息对任何检索方法而言都相同。计划将来的 DB2 版本将对管理 UDF 使用标准化的命名约定，因此我们不是修改现有的函数，而是决定在 DB2 V8.2.2 版本中引入新标准。

下列列表详细描述了新的函数名以及这些 UDF 可用于什么：

• SNAP_GET_DB 获得数据库信息
• SNAP_GET_TBSP to 获得表空间信息
• SNAP_GET_TBSP_PART 获得特定分区的表空间信息
• SNAP_GET_CONTAINER 获得容器信息
• SNAP_GET_STO_PATHS 获得容器路径信息
• SNAP_GET_TAB to 获得表信息
• SNAP_GET_DYN_SQL 获得动态 SQL 信息
• SNAP_GET_DETAILLOG 获得详细的日志信息

图 8 展示了从返回已更新监控信息的 Development Center 中调用 UDF：

图 8. 使用 UDF 返回 DB2 信息

如果这些表函数在 DB2 的下一版本中发生改变，客户就需要一种方法来维护与其购买的利用这些表函数的应用程序（如 SAP）或他们自己的本土应用程序的向下兼容性。为了支持向下兼容，创建了图 8 中所示的表函数上的快照监控视图。这些视图保证存在于 DB2 后续版本中。每个视图将基于底层基于监控的 UDF 的 SELECT *，并且将在 SYSCATV82 模式下创建。

在图 9 中，您可以看到我正通过使用视图代替前一图中的表函数，调用相同类型的信息：

图 9. 使用视图调用与图 8 中相同的信息

DB2 V8.2.2 还增强了 get_db_config 存储过程的输出。在 DB2 V8.2.2 之前，该存储过程中不返回通过检索数据库配置信息的 CLP 方法所返回的一些信息。从 DB2 V8.2.2 开始，向 get_db_config 存储过程的输出添加了所有遗漏的参数。此外，还对该例程返回的其他参数进行了一些修饰工作，以获得更好的可读性以及与检索的 CLP 方法的一致性（例如，COLLATE_INFO 列的行为像现在的 CLP 版本一样；在 DB2 V8.2 中，它显示空白文本）。为了使用该例程，DB2 V8.2.2 中需要一个 8 KB 页面的用户临时表空间。如果不存在这样的标空间，则将向用户或应用程序返回 SQL0286N 错误。

DB2 V8.2.2 还提供了使用 SQL 获得服务器系统细节信息的能力。有一组新的 UDF 允许远程客户机获得 DB2 服务器的有关细节，包括机器、产品和实例信息等。这些 UDF 是在数据库创建时创建的。（当然，您需要正确的授权以获得它们）。

这个新特性是为帮助他们环境中的 DBA，以及使用 DB2 持久存储其应用程序数据的 ISV 而设计的。例如，您或许拥有一个远程工具，需要知道它是否使用 DB2 ESE 或 DB2 Express 服务器 —— 用于功能启用或授权。在 DB2 V8.2.2 之前，该信息只能通过管理 API 获得。

新例程是在 sqlescat.h 中定义的，并且放置在位于 sqllib/bin/routine 目录下新的 db2envinfo 库中。新例程有：

• SYSPROC.ENV_GET_SYS_INFO 返回系统信息
• SYSPROC.ENV_GET_PROD_INFO 返回环境信息
• SYSPROC.ENV_GET_INST_INFO 返回实例信息

图 10 中展示了这三个新信息 UDF 的例子：

图 10. 使用 UDF 检索系统、环境和实例信息

您甚至可以使用结构化查询语言（SQL）来查看 DB2 注册表的设置。众所周知（或刚刚了解），DB2 正在进行首创工作，使得通过 SQL 代替其他各种方法（API、命令等）访问管理功能。SQL 管理例程和视图使得 DBA 和应用程序开发人员更易于查询和修改其 DB2 系统的状态。当然，可以容易地将存储过程和函数暴露为 Web 服务，以获得进一步的管理可扩展性。

正如我前面所提到的，DB2 V8.2.2 添加了通过调用简单的表函数查询当前（有效）DB2 注册表变量配置的功能。在监控远程 DB2 服务器的注册表配置时，该方法将特别方便，无需物理上真正登录每台服务器以显式地使用 db2set 命令。

在 DB2 V8.2.2 中，当使用分区数据库环境时，该函数将仅仅返回用户所连接分区的注册表设置。如果您连接了一个分区并希望检索另一分区的有效设置，就必须在调用该表函数之前，首先连接这个新分区。该限制将在将来的 FixPack、更新或版本中去除。

图 11 中展示了查看系统 DB2 注册表设置的例子：

图 11. 使用表函数查看 DB2 服务器的当前注册表设置

最后，有一个新的 ADMIN_LIST_HIST() 基于 SQL 的 UDF 来检索 DB2 History 文件中所存储的信息。在 DB2 V8.2.2 之前，您必须使用 LIST HISTORY CLP 命令或相应的 API 来检索信息。ADMIN_LIST_HIST() UDF 使 DBA 无需用程序检索该信息。该 UDF 是只读函数，然而，对于 DB2 History 文件的删除和更新只可以通过 PRUNE HISTORY 和 UPDATE HISTORY 命令执行。

下面的图 12 中展示了该命令的例子：

图 12. 使用例程查看 DB2 history 文件 - 它是只读成员

正如您可以看到的，DB2 V8.2.2 版本的绝大部分从管理角度提高了人员的产生力 —— 但是，该版本中不仅仅有管理增强。

结束语
DB2 V8.2.2 具有许多增强，我们只是触及了表面的东西。在该系列的第 2 部分中，我们将深入介绍这些特性，它们为 DB2 在当今市场中拥有的性能领导地位做出了贡献。