分类：
2008-04-12 23:42:07
| 来源：DB2 开发者园地 作者：Blair Adamache |
|
简介
曾听说过创造性压力吗？它属于那些伪精神哲学之一，它宣称互相作用的力会创造出作为斗争副产品的事物。这有点象小人书里面善与恶之间的斗争。现在，我不想说所有软件工程师都是好人，或者所有硬件工程师都是坏人，但是在他们之间存在着创造性压力。正如 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。例如： |
