DB2基础：表空间和缓冲池

核心提示：表空间组织通常应该将目录表空间和系统临时表空间作为 SMS 分配，没有必要拥有多个具有相同页大小的临时表空间，DB2基础：表空间和缓冲池(4)，通常只需一个具有最大页大小的临时表空间就够了，突出的问题在于是否要将用户数据分割到多个表空间中，为了方便您的学习，我们在下面提供了其它联机参考资料，一个考虑因素是页的利用率，不

表空间组织

通常应该将目录表空间和系统临时表空间作为 SMS 分配。没有必要拥有多个具有相同页大小的临时表空间，通常只需一个具有最大页大小的临时表空间就够了。

突出的问题在于是否要将用户数据分割到多个表空间中。一个考虑因素是页的利用率。不能将行分割到不同的页，因此具有长行的表需要有合适的页大小。但是，一个页上的行不能超过 255 个，因此具有较短行的表不能利用整个页。例如，在页大小为 32K 的表空间中放置行长度为 12 字节的表，它大约只能利用每个页的 10%（即，（255 行 * 12 字节 + 91 字节的开销） / 32k 页大小 = ~10%）。

如果表很大，这只是一个考虑因素，因此浪费的空间就非常大。它还会使 I/O 和缓存的效率降低，因为每个页的实际有用内容很少。如果可以将表放到具有较小页的表空间中，以及可以充分利用较大的页大小，那么最常用的访问方法将确定哪一个更好。如果通常是顺序访问大量行（该表可能进行了群集），那么比较大的页大小会比较有效。如果随机访问行，那么较小的页大小可以允许 DB2 更好地利用缓冲区，因为同样的存储区域可以容纳更多页。

一旦根据页大小对表进行了分组，那么访问频率和类型将确定把数据进一步分组到独立的表空间中是否有意义。每张表根据自己被最频繁访问的方式，可以具有一组最有效的表空间设置：PAGESIZE、EXTENTSIZE 和 PREFETCHSIZE。上面已介绍了 PAGESIZE。EXTENTSIZE 是在将数据写入到下一个容器之前写入到当前容器中的数据的页数（如果表空间中存在多个容器的话）。

PREFETCHSIZE 指定在执行数据预取时将从表空间读取的页数。当数据库管理器确定顺序 I/O 是适当的，并且确定预取操作可能有助于提高性能时，会使用预取操作（通常是大型表扫描）。比较好的做法是将 PREFETCHSIZE 值显式地设置成表空间的 EXTENTSIZE 值与表空间容器数的乘积的倍数。例如，如果 EXTENTSIZE 是 32，并且表空间中有 4 个容器，那么理想的 PREFETCHSIZE 应当是 128、256 等等。如果一个或多个频繁使用的表需要的这组参数的值不同于那些最适用于表空间其它表的性能的参数值，那么将这些表放入单独的表空间可能会提高整体性能。

如果预取操作是表空间中的重要因素，那么请考虑留出一部分缓冲区用于基于块的 I/O。块大小应当等于 PREFETCHSIZE。

缓冲池的利用率

使用多个用户表空间的最重要原因是管理缓冲区的利用率。一个表空间只能与一个缓冲池相关联，而一个缓冲池可用于多个表空间。

缓冲池调优的目标是帮助 DB2 尽可能好地利用可用于缓冲区的内存。整个缓冲区大小对 DB2 性能有巨大影响，这是因为大量的页可以显著地减少 I/O 这一最耗时的操作。但是，如果总的缓冲区大小太大，并且没有足够的存储器可用来分配给它们，那么将为每种页大小分配最少的缓冲池，性能就会急剧下降。要计算最大的缓冲区大小，DB2、操作系统以及其它任何应用程序都必须考虑其它所有存储器的利用率。一旦确定了总的可用大小，就可以将这个区域划分成不同的缓冲池以提高利用率。如果有一些具有不同页大小的表空间，那么每种页大小必须至少有一个缓冲池。

拥有多个缓冲池可以将数据保存在缓冲区中。例如，让我们假设一个数据库有许多频繁使用的小型表，这些表通常全部都位于缓冲区中，因此访问起来就非常快。现在让我们假设有一个针对非常大的表运行的查询，它使用同一个缓冲池并且需要读取比总的缓存区大小还多的页。当查询运行时，来自这些频繁使用的小型表的页将会丢失，这使得再次需要这些数据时就必须重新读取它们。

如果小型表拥有自己的缓冲池，那么它们就必须拥有自己的表空间，因此大型查询就不能覆盖它们的页。这有可能产生更好的整体系统性能，虽然这会对大型查询造成一些小的负面影响。经常性地进行调优是为了实现整体的性能提高而在不同的系统功能之间做出的权衡。区分功能的优先级并记住总吞吐量和使用情况，同时对系统性能进行调整，这是非常重要的。

V8 所引入的新功能能够在不关闭数据库的情况下更改缓冲池大小。带有 IMMEDIATE 选项的 altER BUFFERPOOL 语句会立刻生效，只要数据库共享的内存中有足够的保留空间可以分配给新空间。可以使用这个功能，根据使用过程中的周期变化（例如从白天的交互式使用转换到夜间的批处理工作）来调优数据库性能。

物理存储器组织

一旦将表分布到多个表空间中，就必须决定它们的物理存储器。表空间可以存储在多个容器中，并且它可以是 SMS 或 DMS。SMS 更容易管理，对于包含许多不同的小型表的表空间（例如目录表空间），尤其是那些包含 LOB 的表的表空间而言，SMS 可能是个不错的选择。为了降低每次一页地扩展 SMS 容器的开销，应当运行 db2empfa命令。这会将数据库配置参数 MULTIPAGE_ALLOC 的值设置成 YES。

DMS 通常有更好的性能，并且它提供了分别地存储索引和 LOB 数据的灵活性。通常应当将一个表空间的多个容器分开存放在单独的物理卷上。这可以提高某些 I/O 的并行性。当有多个用户表空间和多个设备时，应当考虑应用程序逻辑，这样就可以尽可能平均地在这些设备上分配工作负载。

RAID 设备有它们自己的特殊考虑。EXTENTSIZE 应该等于 RAID 条带大小或者是它的倍数。PREFETCHSIZE 应该等于 RAID 条带大小乘以 RAID 并行设备数（或者等于该乘积的倍数），这个值应该是 EXTENTSIZE 的倍数。DB2 提供了自己的注册表变量，允许您增强您的特定环境。通过执行下面这个命令，可以在一个容器中启用 I/O 并行性：

db2set DB2_PARALLEL_IO=*

另一个注册表变量 DB2_STRIPED_CONTAINERS=ON 可以将容器标记大小从一个页更改成整个扩展块，因此就能使表空间扩展块和 RAID 条带一致。

至于性能评估的其它方面，要知道某个更改是否有益，唯一稳妥的方法就是进行基准测试。如果物理组织发生了更改，那么执行该任务稍微有些复杂，这是因为这时要更改表空间必须要付出相当大的精力。最实用的方法就是减少设计阶段中的案例数，这样的话稍后需要进行基准测试的案例就比较少了。只有在性能极其重要并且不同的设计之间有可能存在显著的性能差别时，才值得花时间和精力进行严格的基准测试来比较设计。应当把重点放在缓冲池上，确保没有将它们分配到虚拟内存中，并确保以最有效的方式利用它们。

有关移动数据库的考虑事项

在将数据库移到另一个系统之前，始终应该重新评估它的调优参数和物理组织，即便这些系统是同一种平台也应如此。在实际情况中，DBA 将经过良好调优的数据库从具有 1 GB 内存的 Windows 服务器复制到具有 256 MB 内存的膝上型计算机中。在服务器上进行连接所花的时间小于一秒，而在膝上型计算机中却要用掉 45 分钟。通过减少缓冲池大小和其它内存参数就能解决这个问题。

如果平台不一样，那么这个问题就变得更难了。即使是在 UNIX 和 Windows 之间进行移动，在一个系统上已是最佳性能，在另一个系统上却未必如此。如果复制数据库是为了进行生产，那么应当重复调优过程。如果必须将数据库移到 zSeries™，那么这里讨论的某些内容则不适用，而应该参考有关的手册和红皮书。在 iSeries 系统上，物理设置和调优是在数据库环境之外一起完成的，应当参考 iSeries™ 系统管理手册。

结束语

我们在本文中介绍了许多内容，但是您应当了解的有关数据库设计和性能的知识决不仅限于此。我们着重讨论了数据库设计的两个比较大的问题，而没有深入研究查询优化和应用程序考虑事项的细节。设计数据库是第一位的，因为这是其它所有事情的前提，因此您的初始规划应该非常全面。为了方便您的学习，我们在下面提供了其它联机参考资料，这样您就可以继续学习有关本主题的内容。