DB2 V9.7 for Linux, UNIX, and Windows

进行配置以实现良好的性能

某些类型的 DB2® 部署的配置高度可调，InfoSphere® Balanced Warehouse®（BW）或者 SAP 系统中的那些部署就是如此。

对于 BW 而言，硬件因素（例如 CPU 数目、内存量相对于 CPU 数目的比率、磁盘的数目和配置以及版本）将根据确定最佳配置时进行的全面测试预先指定。对于 SAP 而言，未准确地指定硬件配置；但是，提供了许多样本配置。此外，SAP 最佳实践提供了建议的 DB2 配置设置。如果您正在将 DB2 部署用于提供了经过精心测试的配置准则的系统，那么通常应该利用那些准则以代替更通用的经验法则。

假定您有一个未掌握其详细硬件配置的建议系统。您的目标是，确定几项关键的配置决策，以使系统实现良好的性能。此步骤通常在系统启动并运行前执行，因此，您对系统的实际运行情况的了解可能非常有限。在某种程度上，您必须根据您对该系统将要执行的任务的了解进行“最佳猜测”。

硬件配置

在配置系统以提高性能时，CPU 容量是其中一项主要的独立变量。由于所有其他硬件配置通常都由 CPU 容量决定，因此，预测给定工作负载所需的 CPU 容量并不容易。在商业智能 (BI) 环境中，合理的估算是，每个处理器核心处理 200-300 GB 的活动原始数据。对于其他环境而言，比较好的方法是根据一个或多个现有 DB2 系统来测量所需的 CPU 容量。例如，如果新系统需要处理的用户数增加 50%，并且运行的每个 SQL 语句都至少与现有系统中的 SQL 语句一样复杂，那么假定所需的 CPU 容量也增加 50% 比较合理。同样，还应该考虑其他在 CPU 使用率方面预计有所变化的因素，例如不同的吞吐量需求或者在使用触发器或引用完整性方面的变动。

在根据可用的信息很好地认识 CPU 需求之后，就可以逐步确定硬件配置的其他方面。虽然您必须考虑数以千兆字节或兆兆字节计的所需系统磁盘容量，但性能方面的最重要因素是每秒 I/O 次数 (IOPS) 这一容量，即每秒的数据传输兆字节数。实际上，此因素由涉及到的各个磁盘的数目确定。

情况为何如此？在过去这十年，CPU 在速度方面取得了难以置信的巨大进步，但磁盘在其容量和降低成本方面取得的进步更大。磁盘寻道时间和传输率方面也有所改善，但却落后于 CPU 速度方面的进步。因此，为了实现现代系统所需的总体性能，使用多个磁盘比以往更加重要，对于将要执行大量随机磁盘 I/O 操作的系统而言更是如此。通常，我们总是希望使用尽量少的磁盘来存储系统中的全部数据，但这通常会导致性能非常差。

对于 RAID 存储器，或者对于可独立寻址的驱动器，经验法则是为每个处理器核心至少配置 10 到 20 个磁盘。对于存储服务器，建议采用类似的数目；但是，在此情况下，需要更加小心谨慎。存储服务器上的空间分配通常与容量而非吞吐量更为相关。您最好充分了解数据库存储器的物理布局，以确保逻辑上相分离的存储器不会意外重叠。例如，对于 4 路系统而言，合理的分配可能是 8 个各包含 8 个驱动器的阵列。但是，如果全部这 8 个阵列共享相同的 8 个底层物理驱动器，那么与 8 个阵列分布于 64 个物理驱动器的情况相比，此配置的吞吐量将大幅下降。

最好为 DB2 事务日志预留一些专用（非共享）磁盘。这是因为，日志的 I/O 特征与 DB2 容器有很大的不同，日志 I/O 与其他类型 I/O 之间的竞争关系会引起日志记录瓶颈，在需要执行大量写活动的系统中尤其如此。

通常，RAID-1 磁盘对每秒能够为多达 400 个具有合理写密度的 DB2 事务提供足够的日志记录吞吐量。吞吐率越高或者日志记录量越大（例如批量插入期间的情况），就需要越大的日志吞吐量，此吞吐量可以由 RAID-10 配置中通过写高速缓存磁盘控制器连接到系统的附加磁盘提供。

由于 CPU 与磁盘实际上按不同的时间刻度工作（纳秒与微秒），因此，需要使它们相分离才能实现合理的处理性能。这就是内存所起的作用。在数据库系统中，内存的主要用途是避免执行 I/O，因此在某种程度上，系统的内存越多，性能就越好。幸运的是，内存成本在过去几年间大幅下降，现在，带有数十到数百千兆字节 (GB) 的 RAM 的系统已很常见。通常，每个处理器核心 4 到 8 千兆字节对于大多数应用程序而言已足够。

AIX 配置

为了实现良好性能而需更改的 AIX® 参数相对较少。下列建议假定您使用的 AIX 的级别为 5.3 或更高级别。同样，如果存在已适用于您的系统的特定设置（例如 BW 或 SAP 配置），那么这些设置应该优先于下列通用准则。
  • VMO 参数 LRU_FILE_REPAGE 应该设置为 0。此参数控制 AIX 是否牺牲计算页或文件系统高速缓存页。此外，minperm 应该设置为 3。这两个值都是 AIX 6.1 中的缺省值。
  • 最初，可以保留 AIO 参数 maxservers 的缺省值，即每个 CPU 运行 10 个服务器。系统进入活动状态后，将按如下方式对 maxservers 进行调整：
    1. 收集 ps -elfk | grep aio 命令的输出并确定是否所有异步 I/O (AIO) 内核进程 (aioserver) 都耗用相同的 CPU 时间量。
    2. 如果是这种情况，那么表明 maxservers 的设置可能太小。请将 maxservers 增大 10%，然后重复步骤 1。
    3. 如果某些 aioserver 耗用的 CPU 时间少于其他 aioserver，那么表明系统至少已有所需的 aioserver。如果使用较少 CPU 时间的 aioserver 所占的百分比超过 10%，那么请将 maxservers 减小 10% 并重复步骤 1。
  • AIO 参数 maxreqs 应该设置为 MAX( NUM_IOCLEANERS x 256, 4096 )。此参数控制未完成的 AIO 请求的最大数目。
  • hdisk 参数 queue_depth 应该基于阵列中的物理磁盘数。例如，对于 IBM® 磁盘，queue_depth 的缺省值是 3，建议的值是 3 x number-of-devices。此参数控制可排队磁盘请求的数目。
  • 磁盘适配器参数 num_cmd_elems 应该设置为所有与适配器相连接的设备的 queue_depth 之和。此参数控制可以进行排队以便发送到适配器的请求数。

Solaris 和 HP-UX 配置

对于在 Solaris 或 HP-UX 上运行的 DB2 而言，可以使用 db2osconf 实用程序来检查内核参数以及根据系统大小提供建议。db2osconf 实用程序允许您根据内存和 CPU 来指定内核参数，此外，也可以借助于将当前系统配置与预期的将来配置作比较的常规缩放因子来进行指定。一种好的做法是使用缩放因子 2，或者，如果正在运行大型系统（例如 SAP 应用程序），那么请使用更大的值。通常，db2osconf 为您配置 Solaris 和 HP-UX 提供了良好的起始点，但它未提供最佳的值，这是因为它无法考虑当前以及将来的工作负载。

Linux 配置

DB2 数据库管理器自动更新关键的 Linux 内核参数以满足各种配置的需求。

有关更多信息，请参阅内核参数需求 (Linux)

DB2 数据库分区功能

有关是否使用 DB2 分区数据库环境的决策通常并非仅仅基于数据量，而更多地基于工作负载。作为一般性的准则，大多数分区数据库环境部署隶属于数据仓储和商业智能领域。对于大型的复杂查询环境，强烈建议您使用分区数据库环境，这是因为它的无共享体系结构具有出色的可伸缩性。对于不大可能迅速增大的较小型数据集市（最大可达 300 GB）而言，通常最好选择 DB2 企业服务器版（ESE）配置。但是，分区数据库环境能够使大型或快速增长的 BI 环境受益匪浅。

通常，在典型的分区数据库系统中，每个数据分区有一个处理器核心。例如，包含 n 个处理器核心的系统有可能将目录存放在分区 0 中，并有 n 个附加的数据分区。如果目录分区的使用量较大（例如，用于存放单分区维表），那么也可以为其分配一个处理器核心。如果该系统将支持非常多的并行活动用户，那么每个分区可能需要两个核心。

作为一般性的指南，您应该在每个分区大约存储 250 GB 活动原始数据的情况下进行规划。

InfoSphere Balanced Warehouse 文档提供了有关分区数据库配置最佳实践的深入信息。此文档还包含有关非 Balanced Warehouse 部署的实用信息。

代码页和整理顺序选项

代码页或代码集以及整理顺序选项除了影响数据库行为以外，还将对性能产生重大影响。Unicode 的使用非常广泛，这是因为，与传统的单字节代码页相比，它使您能够在数据库中表示更多的字符串。对于 DB2 V9.5 中的新数据库而言，Unicode 是缺省代码集。但是，由于 Unicode 代码集使用多个字节来表示某些单个的字符，因此会增加磁盘和内存需求。例如，UTF-8 代码集（这是其中一种最常用的 Unicode 代码集）使用 1 到 4 个字节来表示每个字符。从单字节代码集迁移到 UTF-8 所引起的平均字符串扩展系数非常难以估算，这是因为，此系数取决于多字节字符的使用频率。对于典型的北美内容而言，通常不会进行扩展。对于大多数西欧语言而言，使用重音字符通常会导致扩展接近 10%。

除此之外，相对于单字节代码页，使用 Unicode 会导致耗用额外的 CPU 时间。首先，如果发生扩展，那么处理较长的字符串时需要更多工作。其次，更重要的一点是，与单字节代码页所使用的典型 SYSTEM 整理顺序相比，更为复杂的 Unicode 整理顺序所使用的算法（例如 UCA500R1_NO）的成本更高。成本提高的原因是，以文化方面正确的方式对 Unicode 字符串进行排序比较复杂。受影响的操作包括排序、字符串比较、LIKE 处理和索引创建。

如果需要使用 Unicode 才能正确地表示数据，那么请谨慎地选择整理顺序。
  • 如果数据库将包含多种语言的数据，并且该数据的正确排序顺序极为重要，那么请使用其中一种在文化方面正确的整理顺序（例如 UCA500R1_*）。根据数据和应用程序的不同，相对于 IDENTITY 顺序，这可能会导致性能开销提高 1.5 到 3 倍。
  • 在文化方面正确的整理顺序既有规范化版本也有非规范化版本。规范化整理顺序（例如 UCA500R1_NO）将执行附加的检查以处理格式不正确的字符，而非规范化整理顺序（例如 UCA500r1_NX）不执行这些检查。除非处理格式不正确的字符将引起问题，否则请使用非规范化版本，这是因为避免执行规范化代码有助于提高性能。也就是说，即使在文化方面正确的非规范化整理顺序的成本也非常高。
  • 如果正在将数据库从单字节环境移至 Unicode 环境，但对是否包含各种语言的内容没有严格要求（大多数部署都是这种情况），那么可感知语言的整理顺序可能比较适合。可感知语言的整理顺序（例如 SYSTEM_819_BE）利用了许多 Unicode 数据库只包含一种语言的数据这一事实。它们与单字节整理顺序（例如 SYSTEM_819）使用同一种基于查找表的整理算法，因此非常高效。通常，如果原始单字节数据库中的整理行为可接受，那么只要语言内容在移至 Unicode 后未显著更改，那么就应该考虑使用在文化方面有感知能力的整理顺序。相对于在文化方面正确的整理顺序，这将产生非常大的性能增益。

物理数据库设计

初始 DB2 配置设置

DB2 配置顾问程序（也称为 AUTOCONFIGURE 命令）采用您提供的基本系统准则并确定一组良好的起始 DB2 配置值。AUTOCONFIGURE 命令能够提供相对于缺省配置设置的实质改进，这是获取初始配置值的建议方法。通常，您需要根据系统特征对 AUTOCONFIGURE 命令生成的建议进行一些附加的微调工作。

下面是一些有关使用 AUTOCONFIGURE 命令的建议：
  • 从 DB2 V9.1 开始，尽管 AUTOCONFIGURE 命令将在数据库创建时自动运行，但您最好还是显式地运行 AUTOCONFIGURE 命令。这是因为，通过显式地运行此命令，您可以指定“关键字/值”对，从而有助于为系统定制结果。
  • 在数据库中填充适当数量的活动数据之后，请运行（或重新运行）AUTOCONFIGURE 命令。这将为此工具提供更多有关数据库性质的信息。用于填充数据库的数据量十分重要，其原因在于，这将影响缓冲池大小计算之类的工作。数据过多或过少都将导致这些计算的准确性下降。
  • 对于 AUTOCONFIGURE 命令的重要关键字（例如 mem_percent、tpm 和 num_stmts），尝试使用不同的值，以便确定受这些更改影响的配置值以及影响程度。
  • 如果您正在试验不同的关键字和值，那么请使用 APPLY NONE 选项。这使您有机会将建议与当前设置 进行比较。
  • 由于缺省值可能不适合于您的系统，因此请对所有关键字指定值。例如，mem_percent 的缺省值为 25%，这对于专用的 DB2 服务器而言太小；在这种情况下，建议的值是 85%。

DB2 自主与自动参数

最近的 DB2 数据库产品发行版显著增加了在实例或数据库启动时自动进行设置或者在操作期间动态地进行调整的参数的数目。对于大多数系统而言，自动设置所提供的性能将仅次于非常仔细地进行手动调整的系统。这尤其得益于 DB2 自调整内存管理器 (STMM)，此管理器动态地调整数据库内存分配总量以及 DB2 系统中的四个主要内存使用者：缓冲池、锁定列表、程序包高速缓存和排序堆。

由于这些参数将逐个分区地进行应用，因此，在分区数据库环境中使用 STMM 时应该小心谨慎。在分区数据库系统中，STMM 将持续测量单一分区（此分区由 DB2 系统自动选择，但所作的选择可以覆盖）的内存需求并将堆大小更新“推送”到所有已启用 STMM 的分区。由于所有分区都使用相同的值，因此在分区之间的数据量、内存需求和一般活动水平非常一致的分区数据库环境中，STMM 的效用最佳。如果少数分区的数据量或内存需求有所偏斜，那么应该对那些分区禁用 STMM 并允许 STMM 对更为一致的分区进行调整。例如，对于目录分区，通常应该将 STMM 禁用。

对于数据分布不均匀的分区数据库环境（在这种环境中，建议您不要进行持续的跨集群内存调整），可以在“调整阶段”有选择地临时使用 STMM 来帮助确定良好的手动堆设置：
  • 对一个“典型”分区启用 STMM。对于其他分区，STMM 仍处于禁用状态。
  • 在内存设置稳定之后，请将 STMM 禁用并以手动方式将受影响的参数“固定”为经过调整的值。
  • 在其他具有类似数据量和内存需求的数据库分区（例如同一个分区组的分区）中，部署经过调整的值。
  • 如果系统中有多组相互分离的数据库分区包含类似的数据量和数据类型并扮演类似的角色，那么重复此过程。

通常，配置顾问程序在适用的情况下将选择启用自主设置。这包括 RUNSTATS 命令执行的自动统计信息更新（非常有用），但不包括自动重组和自动备份。后两项功能可能也非常有用，但您必须根据环境对其进行配置和调度才能获得最佳结果。缺省情况下，自动统计信息概要分析功能应该保持处于禁用状态。此功能的开销相当高，因此只应该在受控环境下临时用于分析复杂的语句。

显式的配置设置

某些参数没有自动设置，配置顾问程序将不会设置这些参数。您需要显式设置这些参数。这里，只讨论对性能有所影响的参数。
  • logpath 或 newlogpath 确定事务日志的位置。即使配置顾问程序也无法为您确定日志的存储位置。如上所述，最重要的一点是，它们不应与其他 DB2 对象（例如表空间）共享磁盘设备，也不应留在数据库路径下的缺省位置。理想情况下，应该将事务日志放在吞吐量足以确保不会引起瓶颈的专用存储器上。
  • logbufsz 确定事务记录器内部缓冲区的大小，以 4 KB 页计。缺省值（只有 8 页）过小，无法在生产环境中提供良好的性能。配置顾问程序始终会增大此参数，但可能并不足够，这取决于输入参数。通常，256-1000 页的值是不错的范围，并且在数据库服务器整体方案的内存总量中只占非常小的一部分。
  • mincommit 控制组落实，这将致使 DB2 系统尝试同时对 n 个落实事务进行批处理。对于当前事务记录器设计而言，这不大可能是期望的行为。请保留 mincommit 的缺省值 1。
  • buffpage 确定分配给每个将大小定义为 -1 的缓冲池的页数。最佳实践是，忽略 buffpage，并显式设置在 SYSCAT.BUFFERPOOLS 中有条目的缓冲池的大小或者让 STMM 自动调整缓冲池大小。
  • diagpath 确定各种非常有用的 DB2 诊断文件的位置。此参数对性能的影响通常非常有限，但在分区数据库环境中的情况可能并非如此。在所有分区中，diagpath 的缺省位置通常是通过 NFS 安装的共享路径。最佳实践是，对于每个分区，覆盖 diagpath 并指定本地的非 NFS 目录。这将防止各个分区尝试更新同一个文件并写入诊断消息。而是，这些消息将保存在每个分区的本地位置，从而大大减少争用情况。
  • DB2_PARALLEL_IO 不是配置参数，而是 DB2 注册表变量。DB2 系统经常使用由磁盘阵列（操作系统将其视为单一设备）组成的存储器或者跨多个设备的文件系统。因此，在缺省情况下，DB2 数据库系统每次只对表空间容器发出一个预取请求。此行为基于对以下事实的了解：对单一设备发出的多个请求将被序列化。但是，如果容器驻留在磁盘阵列中，那么就有机会同时向其分派多个预取请求，而不会进行序列化。这就是 DB2_PARALLEL_IO 所起的作用。此参数告知 DB2 系统，可以并行地向单一容器发出多个预取请求。最简单的设置是 DB2_PARALLEL_IO=*（表示所有容器都驻留在多个磁盘中，在本例中，假定磁盘数为 7），但其他设置也控制并行度以及受影响的表空间。例如，如果您知道容器驻留在由 4 个磁盘组成的 RAID-5 阵列中，那么可以将 DB2_PARALLEL_IO 设为 *:3。特定的值能否提高性能还取决于扩展数据块大小、RAID 段大小以及使用同一组磁盘的容器数。

与 SAP 和其他 ISV 环境相关的注意事项

如果正在为 SAP 之类的 ISV 应用程序运行 DB2 数据库服务器，那么可能有一些兼顾到特定应用程序的最佳实践准则。最直接的机制是 DB2 注册表变量 DB2_WORKLOAD，可以将它设为一个值以便启用要针对特定环境和工作负载进行优化的聚集注册表变量。DB2_WORKLOAD 的有效设置包括：1C、CM、COGNOS_CS、FILENET_CM、MAXIMO、MDM、SAP、TPM、WAS、WC 和 WP。

其他建议和最佳实践也可能适用，例如代码页或代码集以及整理顺序选项，这是因为它们必须设为预先确定的值。有关详细信息，请参阅应用程序供应商的文档。

对于许多 ISV 应用程序（例如 SAP Business One）而言，AUTOCONFIGURE 命令可以成功地用于定义初始配置。但是，此命令不应用于 SAP NetWeaver 安装，原因是 SAP 安装期间应用了一组初始的 DB2 配置参数。此外，SAP 有一种功能强大的备用最佳实践方法（SAP 注意事项），此方法描述了首选的 DB2 参数设置；例如，SAP 注意事项 1086130 - DB6：DB2 9.5 标准参数设置。

使用 DB2 分区数据库环境时，请特别注意 SAP 应用程序。SAP 主要将分区数据库环境用于它的 SAP NetWeaver Business Intelligence (Business Warehouse) 产品。建议的布局将 DB2 系统目录、维和主表以及 SAP 基本表放在分区 0 中。与其他 DB2 分区数据库环境安装相比，这将在此分区中产生另一工作负载。由于 SAP 应用程序服务器在此分区中运行，因此可能会将多达 8 个处理器分配到此分区。随着 SAP BW 工作负载的并行度变得更高，并且在同时运行许多短查询的情况下，SAP BI 的分区数通常小于其他应用程序情况下的分区数。换而言之，每个数据分区需要多个 CPU。

父主题： 影响性能的因素