让DB2数据库使用所有内存的方法 （4）

   来源：DB2 开发者园地    作者：Blair Adamache

假定您同时面临两种最糟糕的情况：一方面数据库必须迅速，另一方面您又无法预测其中的数据增长或去花费大量时间对其进行维护，那怎么办呢？您可能会问：如果有些事情很重要，为什么不将 DBA 资源用于它呢？但老板并不总是理性的。幸运的是，关系数据库架构设计师们并不是仅有的花费大量时间决定如何使用大内存机器的人：操作系统专家也在研究这个问题。您将需要做一个信念上的飞跃，将所有数据放置到 SMS 表空间，并将文件系统用作容器。（也可以使用 DMS 来做这件事，但是在为容器定义文件大小时，还必须计划数据增长）。现在，查看所有 4 GB 内存地址以上的空间并将它用于文件系统高速缓存，是操作系统的任务。幸运的是，由于大多数数据库运行在大型 SMP 上，并且能够通过利用应用程序来达到其性能目标，这推动了系统设计师们挖掘出大内存机器的潜能，以将频繁访问的数据保存在内存中。而这正是人们希望数据库缓冲池所做的：将经常访问的数据保存在内存中，而其余的仅留在磁盘上。

　　别在家里尝试这个操作！（在工作中、在老板的系统上尝试。）

　　也许在结束关于内存的文章之前，有必要提醒您不要忘记系统里的其余部分。毕竟，如果您有 96 GB 内存，而磁盘上就可能有不止 96 GB 的数据 — 正等着吞没您的系统并将它送入页面调度的痛苦状态。本文的重点是尽可能多地使用内存。毕竟，您为它花了钱，那么为什么不使用它并使之物有所值呢？按照这种思想，不要忘记您购买的其余硬件。您希望软件使用所有的内存，但也希望所有处理器做它们的那部分工作 — 对所有的磁盘也是如此。正如在 1 MB PC 上将应用程序限制到 640 K 内存不能充分利用可用资源一样（因此比它应有的速度要慢），如果您的一个处理器以 100% 运行，而其它以 25% 运行，这时，您的处境就很尴尬了 — 一个处理器的工作负载已达到了极限，而其余处理器什么也不做。（这种情景就好象您在建筑工地上看到一个人正在拿铁锹工作，而他的同事却袖手旁观。）这正是 DB2 EEE 可以帮助您的地方；它的无共享体系结构被设计成简洁地将所有工作和数据公平地划分给可以使用的内存、CPU 和磁盘。出于这个原因，对于决策支持无共享体系结构是很理想的。对于那些事务型工作负载，您必须监视热点：如果发生了 CPU 或磁盘中的一个子集工作过重的现象，为什么会发生这种现象呢？是因为所有任务繁重的客户机都连接到同一节点了吗？幸运的是，EEE 允许您将客户机连接分布到所有节点。是否应该将数据移到这些节点上的许多小表中，这样在进行更新操作时，就避免了对分布在所有节点的一个大表进行操作的情况。小表的缺点在于：当您希望得到一个需要来自每个节点上行的结果集时，必须进行 UNION 操作。还有，不要怕在无共享体系结构上运行 OLTP。在撰写本文时（2001 年 4 月），TPC-C 测试结果表明：前六名都是集群的无共享数据库。

　　工作负载平衡还意味着将表空间分布到多个磁盘，这样多个磁盘可以同时返回数据，因而也就启用了并行 I/O。这里，在三个变量之间存在创造性压力：磁盘、内存和处理器。运气好的话，您的每种资源都充足，并且可以在它们之间进行工作负载平衡来构建一个系统，对于您所花费的时间和投资的金钱，这个系统是物有所值的。至于还没有使用的硬件呢？唔，至少它使硬件销售代表挣得大笔佣金可以到夏威夷度假。而且，如果没有其它原因，那么您是否曾发现自己在夏威夷钓鱼而您的小艇和海浪搏斗时，这些额外的硬件和一根绳索就会形成一个可靠的锚。

　　关于作者

　　Blair Adamache 是 IBM多伦多实验室里有十七年工作经验的老手。他相信如果从 1970 年到 1995 年的每次棒球赛都统计到一个关系表而每次投掷都占一行的话，那么我们将可以证明 Dwight Evans 和 Bobby Grich 应当进棒球名人堂（Baseball Hall of Fame）。 本文最初发表于 DB2 开发者园地，须经许可才能转载。本文所表达的是作者的观点，而非 IBM 观点。