简介


对于刚涉足 DB2 领域的 DBA 或未来的 DBA 而言，新数据库的设计和性能选择可能会很令人困惑。在本文中，我们将讨论 DBA 要做出重要选择的两个方面：表空间和缓冲池。表空间和缓冲池的设计和调优会对 DB2 服务器的性能产生深远的影响，因此我们将着重讨论这些活动。
在我们的示例中，我们将使用 DB2 V8.1 企业服务器版。大多数示例也适用于低级版本。我们会让您知道某个示例是否只适用于V8.1。
在第1节中，我们将从定义表空间的类型开始，并将说明 DB2 如何将数据存储在表空间中。我们将介绍配置选项并向您介绍创建和管理表空间的整个过程。接下来，我们将着重讨论缓冲池，介绍缓冲池是什么以及如何创建和使用它。在第2节中，我们将结合这两个方面并讨论该如何组织缓冲池和表空间才能获得最佳性能。

第 1 节：定义

表空间
       数据库中的所有数据都存储在许多表空间中。可以认为表空间是孩子而数据库是其父母，其中表空间（孩子）不能有多个数据库（父母）。由于表空间有不同用途，因此根据它们的用途和管理方式将它们分类。根据用途有五种不同的表空间：

目录表空间
       每个数据库只有一个目录表空间，它是在发出 CREATE DATABASE 命令时创建的。目录表空间被 DB2 命名为 SYSCATSPACE，它保存了系统目录表。总是在创建数据库时创建该表空间。

常规表空间
       常规表空间保存表数据和索引。它还可以保存诸如大对象（Large Object，LOB）之类的长数据，除非这些数据显式地存储在长表空间中。如果某些表空间是数据库管理的空间（Database Managed Space，DMS），则可以将表及其索引分别放到单独的常规表空间中。我们将在本文后面定义 DMS 和系统管理的空间（System Managed Space，SMS）之间的区别。每个数据库中必须至少有一个常规表空间。创建数据库时指定该表空间的缺省名为 USERSPACE1。

长表空间
      长表空间用于存储长型或 LOB 表列，它们必须驻留在 DMS 表空间中。它们还可以存储结构化类型的列或索引数据。如果没有定义长表空间，那么将把 LOB 存储在常规表空间中。长表空间是可选的，缺省情况下一个都不创建。

系统临时表空间
      系统临时表空间用于存储 SQL 操作（比如排序、重组表、创建索引和连接表）期间所需的内部临时数据。每个数据库必须至少有一个系统临时表空间。随数据库创建的系统临时表空间的缺省名为 TEMPSPACE1。

用户临时表空间
       用户临时表空间存储已声明的全局临时表。创建数据库时不存在用户临时表空间。至少应当创建一个用户临时表空间以允许定义已声明的临时表。用户临时表空间是可选的，缺省情况下一个都不创建。

表空间管理
可以用两种不同的方式管理表空间：

系统管理的空间（SMS）
       SMS 表空间由操作系统进行管理。容器被定义成常规操作系统文件，并且是通过操作系统调用访问的。这意味着所有的常规操作系统功能将处理以下内容：操作系统将缓冲 I/O；根据操作系统约定分配空间；如有必要就自动扩展表空间。但是，不能从 SMS 表空间删除容器，并且仅限于将新的容器添加到分区的数据库。前一节中所说明的那三个缺省表空间都是 SMS。

数据库管理的空间（DMS）
        DMS 表空间是由 DB2 管理的。可以将容器定义成文件（在创建表空间时将把给定的大小全部分配给它们）或设备。分配方法和操作系统允许多少 I/O，DB2 就可以管理多少 I/O。可以通过使用 altER TABLESPACE 命令来扩展容器。还可以释放未使用的那部分 DMS 容器（从 V8 开始）。

下面是一个示例，说明该如何增大容器大小（V7 和 V8 都支持此功能）：


请注意，只有 V8 才支持将原始容器的大小调整得更小。

如何创建和查看表空间
当创建数据库时，将创建三个表空间（SYSCATSPACE、TEMPSPACE1 和 USERSPACE1）。通过使用 DB2 命令窗口（Command Window）或 UNIX 命令行，创建一个名为 testdb 的数据库，连接至该数据库，然后列出表空间：


下面的清单1显示了 LIST TABLESPACES 命令的输出。
清单 1. LIST TABLESPACES 命令的输出


上面所示的这三个表空间是通过 CREATE DATABASE 命令自动创建的。用户可以通过在该命令中包含表空间说明来覆盖缺省的表空间创建，但是在创建数据库时必须创建一个目录表空间和至少一个常规表空间，以及至少一个系统临时表空间。通过使用 CREATE DATABASE 命令或以后使用 CREATE TABLESPACE 命令，可以创建更多的所有类型的表空间（目录表空间除外）。

容器
      每个表空间都有一个或多个容器。重申一次，可以认为容器是孩子，而表空间是其父母。每个容器只能属于一个表空间，但是一个表空间可以拥有许多容器。可以将容器添加到 DMS 表空间，或者从 DMS 表空间中删除容器，而且可以更改容器的大小。只能将容器添加到某个分区中分区数据库上的 SMS 表空间，在添加之前该分区还未给表空间分配容器。添加新的容器时，将启动一个自动的重新均衡操作以便将数据分布到所有容器上。重新均衡操作不会妨碍对数据库的并发访问。

表空间设置
      可以在创建表空间时给它们指定许多设置，或者也可以稍后使用 altER TABLESPACE 语句时指定其设置。

页大小（Page size） 定义表空间所使用的页大小。所支持的大小为 4K、8K、16K 和 32K。页大小根据下表限定了可放到表空间中的表的行长度和列数： 表 1. 页大小的含义

页大小	行大小限制	列数限制	最大容量
4 KB	4 005	500	64 GB
8 KB	8 101	1 012	128 GB
16 KB	16 293	1 012	256 GB
32 KB	32 677	1 012	512 GB

表空间最多可包含 16384 个页，因此选择较大的页大小可以增加表空间的容量。

扩展块大小（Extent size） 指定在跳到下一个容器之前将写到当前容器中的页数。存储数据时数据库管理器反复循环使用所有容器。该参数只有在表空间中有多个容器时才起作用。

预取大小（Prefetch size） 指定当执行数据预取时将从表空间读取的页数。预取操作在查询引用所需的数据之前读入这些数据，这样一来查询就不必等待执行 I/O 了。当数据库管理器确定顺序 I/O 是适当的，并且确定预取操作可能有助于提高性能时，它就选择预取操作。

开销（Overhead）和传送速率（Transfer rate） 这些值用于确定查询优化期间的 I/O 成本。这两个值的测量单位都是毫秒，而且它们应当分别是所有容器开销和传送速率的平均值。开销是与 I/O 控制器活动、磁盘寻道时间和旋转延迟时间相关联的时间。传送速率是将一个页读入内存所必需的时间量。它们的缺省值分别是 24.1 和 0.9。可以根据硬件规格计算这些值。

CREATE TABLESPACE 语句的示例
下列语句将创建一个常规表空间。所讨论的所有设置都是为了进行说明。



如何查看表空间的属性和容器
指定 LIST TABLESPACES 命令的 SHOW DETAIL 选项将显示其它信息：



清单2显示了 USERSPACE1 表空间的输出。缺省情况下，将列出创建数据库时所创建的那三个表空间。
清单 2. LlST TABLESPACES SHOW DETAIL 命令的输出


要列出容器，我们需要使用以上输出中的 Tablespace ID：


清单 3. LIST TABLESPACE CONTAINERS 命令的输出


该命令将列出指定表空间中的所有容器。如上所示的路径指向容器物理上所在的位置。

缓冲池
一个缓冲池是与单个数据库相关联的，可以被多个表空间使用。当考虑将缓冲池用于一个或多个表空间时，必须保证表空间页大小和缓冲池页大小对于缓冲池所“服务”的所有表空间而言都是一样的。一个表空间只能使用一个缓冲池。
创建数据库时，会创建一个名为 IBMDEFAULTBP 的缺省缓冲池，所有的表空间都共享该缓冲池。可以使用 CREATE BUFFERPOOL 语句添加更多的缓冲池。缓冲池的缺省大小是 BUFFPAGE 数据库配置参数所指定的大小，但是可以通过在 CREATE BUFFERPOOL 命令中指定 SIZE 关键字来覆盖该缺省值。足够的缓冲池大小是数据库拥有良好性能的关键所在，因为它可以减少磁盘 I/O 这一最耗时的操作。大型缓冲池还会对查询优化产生影响，因为更多的工作可在内存中完成。

基于块的缓冲池
V8 允许您留出缓冲池的一部分（最高可达 98%）用于基于块的预取操作。基于块的 I/O 可以通过将块读入相邻的内存区而不是将它分散装入单独的页，来提高预取操作的效率。每个缓冲池的块大小必须相同，并且由 BLOCKSIZE 参数进行控制。该值等于块的大小（单位为页），从 2 到 256，缺省值为 32。

扩展存储器
DB2 不将扩展存储器用于缓冲区。但是，可以用扩展存储器来高速缓存内存页，使得从内存移出页变得更快。

CREATE BUFFERPOOL 语句的示例
下面是 CREATE BUFFERPOOL 语句的一个示例：


该缓冲池被分配给上面的 CREATE TABLESPACE 示例上的 USERSPACE3，并且在创建表空间之前创建该缓冲池。请注意，缓冲池和表空间的页大小都是 8K，两者是相同的。如果您在创建缓冲池之后创建表空间，则可以省去 CREATE TABLESPACE 语句中的 BUFFER POOL BP3 语法。相反，可以使用 altER TABLESPACE 命令将缓冲池添加到现有的表空间：


如何查看缓冲池属性
通过查询 SYSCAT.BUFFERPOOLS 系统视图可以列出缓冲池信息：


要找出哪个缓冲池被分配给了表空间，请运行下面这个查询：


可以在上一个查询中找到 BUFFERPOOLID，该查询能够看到每个表空间与哪个缓冲池相关联。

数据库如何保存表空间的可视化图表
既然已经描述了表空间和缓冲池是什么以及如何创建它们，那么就研究一下有关如何在数据库中将它们直观地组织起来的示例。

图 1. 表空间和缓冲池

该数据库有 5 个表空间：一个目录表空间、两个常规表空间、一个长表空间和一个系统临时表空间。没有创建用户临时表空间。另外有 8 个容器。在这个方案中，缓冲池可能如下分配：
将 BP1（4K）分配给 SYSCATSPACE 和 USERSPACE2
将 BP2（8K）分配给 USERSPACE1
将 BP3（32K）分配给 LARGESPACE 和 SYSTEMP1

[ 本帖最后由 darkbug 于 2007-5-28 13:42 编辑 ]

第 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™ 系统管理手册。

结束语
在本文中介绍了许多内容，但是应当了解的有关数据库设计和性能的知识决不仅限于此。着重讨论了数据库设计的两个比较大的问题，而没有深入研究查询优化和应用程序考虑事项的细节。设计数据库是第一位的，因为这是其它所有事情的前提，因此初始规划应该非常全面。

学习中

多谢，先下了。以后再慢慢学。