简介
曾听说过创造性压力吗?它属于那些伪精神哲学之一，它宣称互相作用的力会创造出作为斗争副产品的事物。这有点象小人书里面善与恶之间的斗争。现 在，我不想说所有软件工程师都是好人，或者所有硬件工程师都是坏人，但是在他们之间存在着创造性压力。正如 Joseph Campbell 所说的，“不要让您对科学不切实际的憎恶迷惑了您的双眼，以至看不到计算机芯片中的光辉境界。”如果整个表象浪潮一样涌出磁盘并冲入内存，那还能有什么比 这更浪漫呢?
有时侯，软件工程师会哀叹硬件发展的步伐太缓慢了：机器磁盘速度太慢、内存组太小并且时钟速度象蜗牛爬行。(当硬件发展赶上的时候，可能我们会 忘记 Java™ 应用程序曾经是那么慢。)当新一代硬件出现时，操作系统首先适应，但留给用户的却是，它们只能用 32 位体系架构运行 16 位或(气喘吁吁的)8 位 DOS 应用程序的痛苦。现在压力转到了软件工程师头上：他们什么时候才会重新编译应用程序并利用新硬件所提供的新数据类型和内存可寻址能力呢?在最终的分析中， 您将在 8086 上运行的 BASIC 与在 24 路 SMP 上运行的 C++ 进行比较时，运行“Hello World”程序所花费的时间大约与编写该程序所花费的时间一样长。
但是，数据库所要做的远不止是要向显示器输出“Hello World”。与 Web服务器软件期望更高速线路一样，数据库软件期望从磁盘速度、容量、可寻址内存的每次升级中尽可能获得好处。尽管应用程序程序员可能会抱怨必须为 32 位机器重新编译 16 位程序(它已经运行良好了)，但是数据库工程师喜欢这样的想法：在将数据排序、聚集或发送给用户之前把它保存在内存中而不是磁盘上。I/O 是如此众多要求过高工作负载的杀手 — 这正是您将 1 TB 的数据分散到 5 TB 的磁盘上的原因(更多的磁盘 = 更多的轴，这意味着更多并行的 I/O，至少在基准测试世界中是这样)。
现在，在 RISC 和 Sparc 世界中，64 位体系架构正逐步成为标准，它允许商业性 UNIX®(如 AIX®、HP-UX 和 Solaris 等)为您喜爱的关系数据库提供大量内存。32 位内存的可寻址能力大约等于 4 GB，而许多 UNIX 机器装有 20 到 100 GB 内存，您肯定希望使用这样大的内存。Intel 世界也不落后多少：现在，操作系统、编译器和数据库软件实验室里，正在 64 位 Intel 芯片上运行的 Linux 和 Windows 2000 是一个现实，而且不久会在您周围的网站上销售。
那么，如果硬件和操作系统都已经为使用巨大的内存做好了准备，并且数据库也能够利用大内存，那么您如何将它们结合起来并使之工作呢?使用 DB2® 版本 7，首先要弄清楚的是，在内部，DB2 假设使用 32 位内存和硬件。要利用更大的内存，必须告诉 DB2 可以使用它以及如何使用它。请勿责备 DB2 — 大多数 DB2 客户机和许多 DB2服务器在未来数年中将运行在 32 位 Intel 机器上。并且即使 DB2 在您机器上检测到有 96 GB 内存，谁又能肯定您希望 DB2 使用所有内存，而不是与其它应用程序共享这个内存呢?
当使用这种大内存时，您有几种选择。最显而易见的选择是创建 64 位 DB2 实例。现在，AIX、Solaris 和 HP-UX 上的 DB2 版本 7 都支持这种操作。如果您拥有版本 7.1，则必须下载修订包 1 以安装 64 位 DB2 库。如果您拥有版本 7.2 或更新版本，则不必为了创建 64 位 DB2 实例而安装修订包。要创建 64 位 DB2 实例，可以使用 db2icrt 命令，并指定参数 -w 的值为 64。例如：
db2icrt -w 64 -u db2fenc1 db2inst1 |
描述 64 位环境中 DB2 使用的手册位于：
http://www-4.ibm.com/cgi-bin/db2www/database/db2/udb/winos2unix/support/document.d2w/report?fn=db2q9e71frm3toc.htm
1 + 1 = 2。2 的 32 次方 = 极大的数。
每个 32 位 DB2 实例能够对 4 GB 内存寻址。通常，您希望将大部分内存给缓冲池专用。但是，AIX、HP-UX 和 Windows 上的内存分段会将最大缓冲池的大小限制在 4 GB 以内。即使是在 32 位世界中拥有十分干净的内存模型的 Solaris 上，用于 DB2 缓冲池的内存也不能超过 3.35 GB;4 GB 内存空间的其余内存必须专用于 DB2 的其它共享内存用途。(幸运的是，对于 64 位世界中的所有操作系统，内存模型都更干净。)在 HP-UX 上，32 位 DB2 实例所能够创建的最大缓冲池大约是 800 MB。在 HP-UX 上，只有通过使用 32 位 HP-UX 上的 Memory Windows 来运行多个实例，才能使用 1 GB 以上的缓冲池。(DB2 发行说明(Release Notes)中描述了 HP Memory Windows。)在 Windows 上，缓冲池被限制为 3 GB，AIX 上是 1.75 GB，而 Linux 上大约是 1 GB。
在运行 32 位 DB2 的大内存系统上，要将大量内存给予缓冲池，最简单方式就是在一个 DB2 企业扩展版(Enterprise-Extended Edition (EEE))配置中运行多个逻辑 DB2 实例。只需要运行操作系统的一个实例，这将有助于节省开销和允许多个 DB2 实例之间通过共享内存而不是通过 TCP/IP 或通信交换机来彼此通信。使用 DB2 的无共享体系结构，每个实例可以在它自己的数据库分区之内愉快地对 4 GB 内存寻址。在大多数 DB2 TPC-H 基准测试中 — 它通常让 DB2 EEE 在规模达 300 GB 或更大的数据库上运行决策支持查询 — 一个大型 SMP 为每个 DB2 节点划分多至 4 GB 内存(每个节点都是一个运行它自己的 DB2 实例的数据库分区)。
DB2 还可以使用其它三种方法来利用大内存机器。在 AIX、Solaris 和 Windows 上，DB2 支持扩充存储器(Extended Storage)(也称为 ESTORE)。这允许 DB2 将超过 32 位内存模型中最大可用内存的内存用于系统临时表(用于排序)和只读用户数据。在 DB2 从磁盘获取数据时就由 DB2 判断哪些数据是可以认为是只读，但是需要配置 DB2 以使用扩充存储器。
让我们考虑一种典型情况：您正在设计一个数据库，在其中希望将一个表尽可能多地放入内存。首先，更新数据库管理器配置并告诉它要使用多少扩充存 储段(num_estore_segs)。这个值的缺省设置为零。n 取多大值将取决于表有多大、可用的内存有多少以及您希望这个特定表用多少内存。假定我们正在使用 Solaris，它有 6 GB 内存 — 在 4 GB 内存空间之上的 2GB 内存用于扩充存储器(也称为 estore)：
update db cfg for sample using num_estore_segs n |
用“扩充存储器存储段大小”(estore_seg_sz)数据库配置参数来定义 estore 段的大小：
update db cfg for sample using estore_seg_sz 32000 |
现在您创建了一个缓冲池。对于本示例，我们将使用 8K 页面大小，尽管 16K 和 32K 页面大小也是允许的。(如果是在 Windows 上，要使用 2GB 以上的内存，则必须使用大于 4K 的页面大小。)必须为扩充存储器启用缓冲池，可以使用 EXTENDED STORAGE 关键字做到。 highmem 是我为这个缓冲池选择的名称。其大小 n 取决于您希望这个缓冲池占用的内存数量：
CREATE BUFFERPOOL highmem SIZE n PAGESIZE 8K EXTENDED STORAGE |
现在创建一个表空间，并将它分配到这个缓冲池：
CREATE TABLESPACE highmem_tbsp PAGESIZE 8K
MANAGED BY SYSTEM
USING ('C:highmemdir)
BUFFERPOOL highmem
