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

核心提示：简介曾听说过创造性压力吗？它属于那些伪精神哲学之一，它宣称互相作用的力会创造出作为斗争副产品的事物，让DB2数据库使用所有内存的方法，这有点象小人书里面善与恶之间的斗争，现在，I/O 是如此众多要求过高工作负载的杀手 — 这正是您将 1 TB 的数据分散到 5 TB 的磁盘上的原因（更多的磁盘 = 更多的轴

简介

曾听说过创造性压力吗？它属于那些伪精神哲学之一，它宣称互相作用的力会创造出作为斗争副产品的事物。这有点象小人书里面善与恶之间的斗争。现在，我不想说所有软件工程师都是好人，或者所有硬件工程师都是坏人，但是在他们之间存在着创造性压力。正如 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，至少在基准测试世界中是这样）。