db2的表空间和缓冲池
第 2 节：性能含义一般而言，在物理设备上设计如何放置表空间和容器时，目标是使 I/O并行性和缓冲区利用率达到最优。要实现这个目标，应当全面了解数据库设计和应用程序。只有这样您才能确定类似于下面这样的问题：将两张表分隔到不同的设备会不会产生并行 I/O，或者，是否应当在单独的表空间中创建表以便可以对它进行完全缓冲。
设计新数据库的物理布局应当从设计表空间的组织开始：
[*]第一步是确定表设计所给出的约束。这些可能会导致必须使用多个常规表空间。
[*]第二步是考虑如果让表空间中的表具有不同的设置，是否有可能显著提高性能。
[*]一旦作出了一个试验性的表空间设计，那么就必须考虑缓冲池的利用率。这可能会使前面的表空间设计产生一些变化。
[*]最后，必须给表空间分配容器。
这个是一个有反复的过程，应该通过压力测试和基准测试验证该设计。很显然，实现最佳的设计可能需要花费大量精力，并且仅当数据库性能必须可能是最佳时才能证明设计是最佳的。通常：
[*]从最简单的可行设计入手。
[*]只有根据测试证明有充分的性能理由时才增加复杂性。
通常，为了降低管理和保持一个较为简单的数据库设计的复杂性，稍微降低一点性能是值得的。DB2 具有一种非常成熟的资源管理逻辑，往往不用进行精心的设计就能产生非常好的性能。
表空间组织
通常应该将目录表空间和系统临时表空间作为 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™ 系统管理手册。
页:
[1]