以前，2GB 的虚拟存储器似乎足够。如今，它是一种更宝贵的资源。这里将描述如何小心地管理它。

简介
如果您负责管理和维护 DB2 for z/OS 或 DB2 for OS/390 子系统，那么您将设法确保您的掌管满足它的需要：足够的 CPU 周期、足够的大型机内存和足够的磁盘空间等等。但您考虑过子系统能否提供足够的虚拟存储器了吗？

以前，大多数 DB2 用户没有十分关注 DB2 for OS/390 的虚拟存储器需求。而且，由于一些新生的 zSeries 开发，它将再次成为一个较低的优先级。然而，现在您必须了解 DB2 在虚拟存储器方面的需求以及如何提供它所需要的东西。

供与求
大约二十年前，我在就职的 IBM 分支部门参加过一次会议，在那里我听到了大型机技术方面的突破性进展公告。重要新闻是 MVS 扩展体系结构（MVS Extended Architecture，MVS/XA） — 它是 OS/390 的前身，且是大型机操作系统的重大更新。最卓越的 MVS/XA 特性是可用于地址空间的虚拟存储器容量从以前的极限 16MB 激增至 2GB（那时，还宣布是 308X 系列服务器的中央存储器最高可配置到 2GB）。

在 MVS/XA 之前，我们的技术支持人员曾花大量时间帮助大型系统客户充分利用这宝贵的 16MB 虚拟存储器。由于 MVS/XA 提供的地址空间大小增加到 128 倍，所以我不知道虚拟存储器约束是否会再次成为大型机站点的问题。

大约在同一时间，蓝色巨人宣布了新制的 DBMS — DB2。DB2 for MVS 开发人员知道 MVS/XA 将带来什么，他们设计了可以利用大量虚拟存储器的 DBMS。然而，在早期，DB2 用户往往在 DB2 地址空间中仅分配一小部分可用存储器。许多 DB2 v.1 用户将所有数据库对象分配给 BP0，将 10000 个缓冲区（40MB）或更少的缓冲区分配给该池。过去，10MB 的环境描述符管理器（EDM）池已经相当大了。谁还需要 2GB 的空间呢？

推动需求
您瞧，DB2 for MVS 最初被定位于决策支持应用程序的优秀 DBMS，现在已经成为操作应用程序环境方面的巨大成功。组织需要使用 DB2 进行事务和批处理，这具有高级别的吞吐量和次秒（subsecond）响应时间。为了适应性能需求，人们配置了越来越大的 DB2 缓冲池，以在大型机内存中高速缓存更多的数据。与 RELEASE（DEALLOCATE） 程序联编选项结合使用的受保护的 CICS-DB2 线程提高了 EDM 池空间需求。如列表预取和多索引访问之类的优化器增强功能产生了对特定排序池的需要。表空间压缩以大的磁盘空间节省换取更多的虚拟存储器消耗。

不久以后，2GB 的地址空间容量开始看上去相当有限。它真的会在 DB2 环境中用完，用尽这一资源的含意是严重的：用完，则 DB2 子系统会失败。在我从事 DB2 咨询的那段时间里，与我合作过的一家公司遭遇了这种失败。数据库团队再三扩大缓冲池配置以增加性能 — 但是一次性增加太多了。

在 DB2 地址空间中用完虚拟存储器是一个严重问题，但可以通过监控和考虑周到的空间分配来避免这个问题。

DBM1：“老爸”
在多个 DB2 for OS/390 地址空间中，真正需要大量虚拟存储器的是数据库服务地址空间，通常称为 DBM1。

DBM1 虚拟存储器“消费者”包括：

• 缓冲池。公共配置有多个池，一些池有数万个缓冲区（或者更多）。
• EDM 池。我提到过持久线程（如 CICS-DB2 受保护线程）和 RELEASE(DEALLOCATE) 联编选项（联合使用它们以增加应用程序 CPU 效率）如何通过增加池中不可偷窃页面的百分比来提高 EDM 池的使用。目前，DB2 站点还有更多开放数据集（10000 个数据集这一旧限制早就不存在了），这意味着 EDM 池中驻留更多的数据库描述符。但消耗 EDM 池的真正大型驱动程序是动态语句高速缓存，这是一种 DB2 特性，可以显著地为某些应用程序减少动态 SQL 的 CPU 成本。大量使用这一能力的安装有时会使 EDM 池的大小变成好几百兆字节。
• 行标识（RID）池。该池用于优化器存取路径技术（如列表预取、混合连接和多索引访问）附带的 RID 排序。缺省大小是 4MB，某些站点要求该值更大。
• 排序池。DB2 将两个区域的 DBM1 地址空间用于数据排序：缓冲池和排序池。排序池的缺省大小是 1MB，在遇到许多大的、并发且与 SQL 相关的排序的站点中该值通常会大量地增加。
• 压缩词典。任何拥有压缩数据的数据集都有一个相关压缩词典，大小通常为 64KB（被分区的表空间的每个分区是一个数据集）。每个拥有压缩数据的开放数据集的压缩词典被装入 DBM1 地址空间。
• 各种控制块。DBM1 地址空间包含与 DB2 虚拟缓冲池和高性能池、开放数据集和线程（用户和系统）相关联的控制块。总的说来，这些控制块通常至少占用数十兆字节的虚拟存储器（在具有大量并发线程和开放数据集的站点上占用的虚拟存储器更多）。
• DB2 代码。不要忘记：DB2 代码占据几个兆字节的空间。

谨记：并非 DBM1 地址空间中的所有虚拟存储器都为 DB2 所专用。如同所有的 OS/390 地址空间一样，DBM1 包括如扩展的公共存储区（ECSA）之类的公共区域。这些公共区域越大，DBM1 中用于我所列出的虚拟存储器消费者的空间就越少。

您处于控制之下
最大的 DBM1 存储器消费者是我所列出的池。通过 ZPARM 参数和 DB2 命令设置这些池的大小，它们不会超出您所指定的限制，您对此可以确信无疑。同上，ECSA 和其它公共存储区的大小由 OS/390 或 z/OS 系统程序员设置。

DBM1 存储器的其它“消费者”与工作负载和数据库相关。例如，获得压缩词典。您的开放压缩数据集越多，DBM1 中所需的空间就越多以容纳相关的压缩词典。

您准备好创建将容纳压缩数据的分区表空间了吗？如果准备就绪，那么在确定您将定义的分区数目时，请考虑压缩词典。如果 100 和 200 个分区都适合您的需求，则可以选择较小的数目，以减少压缩词典空间需求。

适当地使用压缩。简单的方法就是将差不多所有东西都进行压缩；然而，这意味着有许多压缩词典。请记住：压缩会增加大多数数据更改操作（例如， UPDATE 、 INSERT 和 LOAD ）的成本。您想为压缩那些本来不会占据大量空间的表而付出这样的代价吗？压缩甚至会使表空间变得更大：小型压缩表空间加上相关压缩词典的大小会超过未压缩的表空间大小。

对于与 DB2 线程相关的控制块所消耗的虚拟存储器，您无计可施。工作负载需要多少线程，您就需要多少线程。DB2 数据共享的好处之一是：应用程序线程在 DB2 数据共享组的成员之间传播。在这种环境中，可以通过如下方法来进一步推动这种传播效应：将 Parallel Sysplex 中的每个大型机分割成多个 OS/390 逻辑分区，每个分区都装有属于数据共享组一部分的 DB2 子系统。

从 DBM1 中除去
释放 DB2 数据库服务地址空间中虚拟存储器的一个好方法是将东西从 DBM1 中移走。高性能池正好为这个方法提供了一个极好的机会。如果您的大型机有扩展存储器，那么请考虑创建一些高性能池并减小相应虚拟缓冲池的大小。例如，可以将具有 20000 个缓冲区的 BP1 更改成这样的配置：10000 个缓冲区在 BP1 中，而 10000 个缓冲区在 HP1 中。性能应该大致相等，如果可以为每个除去的虚拟池缓冲区添加几个高性能缓冲区，那么性能可能还会得到改进。（例如，我宁愿 BP1 中有 10000 个缓冲区， HP1 中有 20000 个缓冲区，而不是 BP1 中有 20000 个缓冲区。）如果您想尝试这种方法，请与 OS/390 系统程序员协调，确保您的系统有支持高性能缓冲区的扩展存储器。不要使虚拟缓冲池太小 — 谨记：高性能池仅用于清空（未更新的或更新的且具体化的）页面。

我早先提到过：真正大的 EDM 池常常由于动态语句高速缓存而变得真的很大。这里有一条好消息，从 DB2 for OS/390 V6 开始，您可以将用于动态语句高速缓存的 EDM 池部分放入数据空间。

也可以将虚拟缓冲池放入数据空间（从 DB2 V6 开始）。以这种方法重新部署缓冲池会大大减少 DBM1 虚拟存储器使用，这个许诺使许多人都想尝试一下。然而，要知道在扩展硬件寻址环境之外将缓冲池放入数据空间并不可取。扩展硬件寻址是指一种能力，通过这种能力，在 IBM zSeries 服务器上运行的 z/OS 操作系统（或 OS/390，在某个发行版级别）可以使用大于 2GB 的字节可寻址的大型机内存（也称作中央存储器）。

关于扩展寻址，存在一些困惑。一些人认为它是指虚拟存储器地址空间大小的增加。事实上，这种增加会发生，但它至今还没有发生。目前，扩展可寻址能力是中央存储器所具备的能力。虚拟存储器地址空间仍限制在 2GB。

那么扩展硬件寻址有什么好处呢？在大型机上有大于 2GB 的中央存储器能让您在系统上运行额外的 2GB 地址空间而不必没命似地调页。如果将大的缓冲池放在数据空间中，而服务器上只有 2GB 的中央存储器，则将进行多次调页，这对性能不利。在这种系统上，以虚拟缓冲池空间换取扩展存储器中的高性能池空间将是一个更佳的措施。如果 zSeries 机器的中央存储器大于 2GB 而且您想将缓冲池放在数据空间中，则尽量采用这种方法。

密切注视 DBM1 虚拟存储器
您需要将缓冲池或 EDM 池的一部分放入数据空间吗？您需要将虚拟缓冲池缓冲区改为高性能池吗？您需要减少压缩词典空间需求吗？视情况而定。

您的 DBM1 虚拟存储器使用率如何？如果您不知道，则需要查明。这样做的一个方法是通过 OS/390 或 z/OS 监控程序产品。或者，如果正在运行 DB2 V7，则可以使用通过名为 IFCID 225 （通过 DB2 统计跟踪，类 6 激活）的跟踪记录收集的信息。通过将 IFCID 225 数据用作输入，DB2 监控程序可以为您产生详细制订 DBM1 虚拟存储器利用率的统计报告。

无论这样或那样，都不要太接近 2GB 限制。您应该设法备有至少 200MB 的缓冲器。如果该缓冲器下降到 100MB 以下，那么 DB2 子系统的可用性会有危险。

另一个聪明做法是：在 IDUG、SHARE 或 IBM 数据管理会议上设法与 IBM DB2 开发团队的 John Campbell 联系。John 知道 DB2 for OS/390 and z/OS 虚拟存储器利用率的详细情况，其他人很少知道（他的确教过我有关这方面的一些东西）。参加他关于该主题的演示，或者在午餐时坐在他旁边 — 认真作好笔记。告诉他是 Catterall 介绍您来的。