developerWorks中国网站编辑团队, 编辑, IBM developerWorks中国网站编辑团队。

简介： 随着存储的网络化和高度虚拟化，对于 DBA或系统架构师来说，数据库存储设计似乎是一项极其复杂的任务。本文介绍通过一些易于学习的数据库存储最佳实践获得健全数据库服务器的秘诀，包括以下方面的一些指南和建议。

查看本系列更多内容

发布日期： 2010 年 6 月 21 日
级别： 初级
其他语言版本： 英文
建议: 0 (添加评论)

执行摘要

随着存储的网络化和高度虚拟化，对于 DBA 或系统架构师来说，数据库存储设计似乎是一项极其复杂的任务。

糟糕的数据库存储设计对数据库服务器有极大的负面影响。由于 CPU比物理磁盘快得多，所以常常可以发现性能糟糕的数据库服务器，它们面临非常密集的 I/O ，表现出来的性能离它们的真正潜能差好多倍。

好消息是，保证数据库存储的设计不犯错误，比获得完美的数据库存储设计更重要。在如今虚拟化存储的环境中，试图理解数据存储栈的内部结构，并手动调优数据库表和索引在物理磁盘上的存储位置，这些事情通常既不容易完成，也不易于维护（对于一般的 DBA 而言）。

简单性是良好数据库存储设计的关键。首先，要确保有足够的物理磁盘，以避免系统成为 I/O 密集型系统。

本文介绍通过一些易于学习的数据库存储最佳实践获得健全数据库服务器的秘诀，包括以下方面的一些指南和建议：

• 物理磁盘和逻辑单元数（LUN ）
• 条带（Stripe ）和条带化（striping ）
• 事务日志和数据
• 文件系统与原始设备
• 独立磁盘冗余阵列（Redundant Array of Independent Disks ，RAID ）设备
• 注册表变量和配置参数设置
• 自动化存储

注意：本文所述最佳实践用于在常规 OLTP 环境中部署 DB2 for Linux, UNIX and Windows。文中讨论的建议不一定适用于数据仓库环境，也不一定适用于将 DB2 数据库用作第三方软件底层数据库的环境。

回页首

数据库存储简介

存储区域网（Storage Area Networks ，SAN ）和网络连接存储（Network Attached Storage，NAS）从根本上改变了数据库存储世界。大约十年前，“磁盘”一词指的是具有磁头和碟片的物理磁盘。在如今的存储世界，“磁盘”是一个完全虚拟的实体，它位于存储网络上，可以是单独的物理磁盘、物理磁盘的一部分、RAID 阵列或者 RAID 阵列的某种组合。

最近在文件系统方面取得的进步，例如直接和并发 I/O ，让原始设备较之于文件系统的所有性能优势几乎消失殆尽。

虽然摩尔定律对 CPU 处理能力有效，但是并不适用于存储子系统的速度。尽管 SAN 和 NAS使存储通信发生了变化，但是决定如何存储比特的底层结构基本不变 — 机械主轴转动多个磁性材料的碟片，这些碟片上面是对信息编码后得到的比特。

虽然主轴速度有所提高，使用 DRAM 和 NVRAM的存储控制器上的数据缓存亦有所帮助，但是这些进步都无法赶上过去十年来处理能力的急剧提升。因此，相对于 CPU的处理速度，磁盘要慢得多。这种速度上的差异使得每个 CPU 核必须配备越来越多的物理磁盘，以确保系统不成为 I/O密集型系统。虽然决定每个物理磁盘实际容量的碟片容量有了很大的提高，但是仍然难以达到适当的物理磁盘数与 CPU 核的比例。

随着存储、文件系统和 CPU 处理速度的变化，数据库存储自动配置和管理的最佳实践也在演变。在过去，可能会建议 DBA将表和索引放到确切的物理磁盘上，甚至是每个物理磁盘的哪一部分上。但是在如今的虚拟化存储世界，对于一般 DBA 而言，过去的最佳实践显得不切实际。

本文提供的最佳实践则是围绕如今现实的存储环境而开发的。

请参阅“DB2 最佳实践: 物理数据库设计最佳实践”白皮书，获得关于数据库性能和数据库操作速度的相关信息。该白皮书和其他相关资料可从DB2最佳实践专题 获得。

回页首

良好数据库存储设计的目标

良好的数据库存储设计必须有以下重要特征：

• 可预测的 I/O 和系统性能
• 对 I/O 带宽和容量的均衡使用 — 避免“热点（hot-spot ）”
• 方便的持续管理 — 例如增加新存储
• 方便的问题诊断
• 通过冗余获得的高可用性

回页首

简单的数据库存储设计

“使一切尽量简单，但是不过于简单”
– Albert Einstein

在设计数据库存储时，需要做出很多的选择，简单化是系统架构师和 DBA的秘密武器。本文提供的最佳实践提出了一些简单的经验法则，它们将有助于实现良好数据库存储设计的所有目标。

这种简单化有时候要付出代价，即不能为特定的表或表空间选择最优的 I/O 特征。具有丰富存储技能的有经验的 DBA，以及时间充裕的存储管理员，往往会从物理磁盘中为特别重要的表或索引开辟一片存储。这种方法存在的问题是，这样做也许在设计时能取得最佳性能，但是为了维护最初的设计目标，最后往往会得到一个更难以管理的系统。问题诊断几乎总是很困难——最初认为足够用于特别重要的表或索引的存储带宽，随着时间的推移和应用程序的增长变得不够起来。

良好数据库存储设计的要点在于，在动态的系统上，所有目标在最初的系统设计时能够得到满足，且在数据库投入使用时仍然如此。本文描述的简单的最佳实践可以实现这些目标，且几乎不会牺牲任何性能。

回页首

数据库存储成功秘诀

考虑实际的物理磁盘，而不仅仅是存储空间

物理磁盘与存储控制器相连，DB2 数据库服务器等主机系统不能直接访问它们，DBA 也不能直接看到它们。存储管理员以逻辑单元数 1（logical unit numbers ，LUN ）的形式提供存储单元，而主机系统看到的则是真正的 SCSI 磁盘。但是，LUN是由存储管理员提供的完全虚拟的实体，可映射物理磁盘的任何组合。一个 LUN 可以是单一 RAID 阵列、RAID阵列的一部分、一个物理磁盘、磁盘的一部分或者多个 RAID 阵列的“元设备（meta ）”。

虽然存储世界变得更加虚拟化，但事实上数据仍然存储在机械磁盘驱动器上。无论使用哪家供应商的存储子系统，最终数据仍存储在机械磁盘驱动器上，也就是旋转的物理磁盘碟片上。LUN 可提供的存储带宽与组成它的实际物理磁盘的数量成正比。

虽然存储控制器缓存可帮助提高存储带宽，但 DB2数据库系统已经将相关数据缓存到它们的缓冲池中。这限制了存储控制器充分减少实际物理磁盘需求，以支持 DB2 数据库服务器等 I/O密集型系统的能力。在通常为 I/O 密集型的企业数据库系统中，最终结果是完全找不到实际物理磁盘的替代品。

除了传统的 SAN 存储控制器外，附加的存储虚拟化层也正在被添加到企业中，它们进一步为 DBA 抽象物理磁盘。这种虚拟化的例子有San Volume Controller (SVC) 和 AIX® VIOS 。这些形式的虚拟化可提供称心的功能增强，例如透明地从一组 LUN向另一组 LUN 迁移的能力，或者多个主机 LPAR 共享一条光纤通道 Host Bus Adapter (HBA)的能力。但是，这样做需要付出一定的代价，通常包括 I/O 路径中出现更多的子系统。此外，对于 I/O密集型系统，它们并不能减少对实际物理磁盘的需求。

处理高度虚拟化的存储

如本文简介部分所述，磁盘存储越来越多地被当做一种普通用品，可用存储空间常常被从其所在物理设备中抽象出来。

如果您的企业的 I/O 基础结构要求使用这样的存储系统，那么 DBA 需要继续确保所提供的虚拟 LUN真正由专用的物理磁盘组成。原因是：如果实际磁盘太少，跟不上 CPU 的速度，那么企业系统很快会变成 I/O密集型系统。不幸的是，虽然我们这些关心数据库性能的人是以实际磁盘数量来衡量存储需求的，但存储管理员却不同，他们只按空间的概念来考虑存储需求。虽然过去十来年碟片大小有了长足的进步，但若要增加每个 CPU 核的物理磁盘数而不仅仅是空间，只会变得越来越难。

更糟糕的是，数据库管理员知道需要多少物理磁盘来确保良好性能，却不得不为拥有太多空间而辩护。例如，假设有一个 CPU 核和 20个物理磁盘。这样的磁盘 -CPU 比例应该可以产生足够的 I/O 并行性来提供很好的性能。如果每个磁盘设备可以存储 150 GB ，那么每个CPU 核有大约 3 TB 的空间。如果有多个 CPU 核，每个核按 1:20 的比例配备物理磁盘，那么存储的总量将以惊人的速度增长。

虽然有这么多“空闲”的空间，但重要的是这样的存储并不会过量。例如，您可能想将一些未使用的存储分配给其他应用程序或进程。但是要记住，相互竞争的应用程序或进程发出太多的每秒 I/O 操作（I/O-operations-per-second ，IOPS）可能导致所有应用程序的性能下降。这意味着存储管理员应该抵制诱惑，不要将未使用的空间作为单独的 LUN 分配给 DBA 无权控制的其他应用程序。

现在，可以在将数据库备份到长期存储之前，将未使用的空间用作数据库在线备份或归档日志的 staging区域。这是非常合理的用法，因为当执行备份时，一切都在您的控制之下。换句话说，当使用这些设备时，完全由您（而不是其他未知的用户或应用程序）控制。您可以在不需要峰值 I/O 吞吐量的时候执行在线备份。

如果使用这样的策略来最大化空间使用率，那么要记住，为数据和备份使用相同的磁盘将不可避免地带来一定的风险。应该适时地将备份归档到外部备份目标，例如 Tivoli® Storage Manager (TSM) 。

由于 CPU 速度有望继续增长（增长方式是通过增加 CPU核提高处理并行性，而不是增加时钟频率），预期的趋势是，为确保数据库服务器不成为 I/O密集型系统，每个系统将需要越来越多的物理磁盘。因此，DBA 应通过良好的模式设计，并利用 DB2 数据库系统中的高级功能，例如 MDC 、MQT和压缩，尽可能消除 I/O 操作，这一点比以往更重要。

相对于碟片速度，CPU 处理速度有了更快的增长，因此好的经验法则是确保每个 CPU 核有 15 到 20个专用物理磁盘。通过使用多维集群（Multidimensional Clustering ，MDC ）等 I/O技术，以及良好的模式管理和设计，这个数字有可能减少。

值得注意的是，在撰写本文之际，此处所说的物理磁盘数量只针对企业中的普通处理器和磁盘技术。这包括 IBM POWER5™、Intel® Xeon® 和 AMD® Opteron ™ 处理器。普通的主轴速度是 15000 rpm 。当下一代处理器普及时，对于I/O 密集型数据库服务器，每个处理器将需要大量的物理磁盘。

为每个非 DPF DB2 数据库服务器 /每个 DPF 分区使用专用 LUN 和文件系统

最好不要在 DB2 服务器 / 分区之间共享 LUN 和物理磁盘。最佳实践是为每个非 DPF DB2 数据库服务器和每个 DPF数据库分区使用专用 LUN 。

将 LUN 专用于 DB2 服务器或分区确实会阻碍将组成该 LUN 的物理磁盘用于创建单独的 LUN ，虽然创建的 LUN的使用不大可能干扰那些磁盘的主要用途。但是，如上一节所述，您应该确保这些 LUN在您的控制之下，并谨慎地加以使用。之前讨论的将剩余空间用于备份和归档日志的 staging 区域就属于这样的用途。

单个的文件系统应该在每个这样的 LUN 上创建，并且应该专用于单个 DB2 服务器或 DPF 数据库分区。

专用的 LUN 和每个 LUN 上专用的文件系统可保持存储布局的简单性，并且有助于问题诊断。

对于 DPF 系统，建议遵循 IBM Balanced Configuration Warehouse 实践。

例如，当在一个表上选择了不恰当的分区键时，查询便不能获得应有的并行性，如果采用上述做法，这个问题就可轻易诊断出来。当 LUN和文件系统专用于数据库分区时，如果看到一组 LUN 的繁忙时间远多于其他 LUN，那么这个问题就变得很明显了，因为一个分区上存放了所有需要处理的数据，而其他分区上的数据则相对较少。

最多两次条带化

存储控制器直接在控制器固件中提供了杰出的 RAID条带化。应该将企业系统设计为使用存储控制器提供的条带功能。这么做的一个更方便的途径是让存储控制器暴露一个单独的 RAID 阵列，例如，让RAID-5 或 RAID-10 作为一个单独的 LUN 。然后，可以将一个或多个这样的 LUN 提供给 DB2 分区。

当把不止一个 LUN 提供给 DB2 数据库服务器或 DPF 数据库分区时，则使用 DB2 数据库系统容器更细的条带。

由于两次条带化对所有的系统都算足够了，要避免使用三次条带化，例如操作系统的逻辑卷管理器。逻辑卷管理器（LVM）条带化对于其他中间件有益，但是 DB2 数据库系统不同，DB2 数据库系统中没有足够的容量来进行自己的条带化。

将 DB2 事务日志与数据分开

为取得最佳可用性，应将事务日志和 DB2 数据或表空间分开，放到不同的物理磁盘和不同的 LUN 上。

应该为每个 DB2 分区提供一个有专用物理磁盘的 LUN 用于事务日志，此外，通常还需为表空间容器或数据提供多个 LUN 。

虽然日志物理磁盘相对于数据物理磁盘的比例很大程度上取决于工作负载，但较好的调整准则是 15% 至 25% 的物理磁盘用于日志，75%至 85% 的物理磁盘用于数据。

使用文件系统替代原始设备 — 为每个 LUN创建一个文件系统

由于性能的原因，直接 I/O 和并发 I/O几乎已经完全消除了使用原始逻辑卷的需要。文件系统比原始设备提供更好的可管理性，因为单个文件系统可用作多个表空间的容器。

为一个数据库分区配置的的每个 LUN 都应该创建一个单独的文件系统，供这个分区使用，也就是说，每个 LUN 一个文件系统。

每个 DB2 分区通常有：

• 一个事物日志文件系统 — 使用 LUN 创建，用于分区的事务日志。
• 多个数据文件系统——每个文件系统都使用它自己单独的 LUN 创建，用于表空间数据。

事务日志使用 RAID-10，数据使用RAID-10 或 RAID-5

RAID-10 提供极好的冗余，因为它可以经受多次物理磁盘故障。而 RAID-5 只能经受一次物理磁盘故障。但是，RAID-10增加冗余的代价是成本比 RAID-5 高很多。

如果将 RAID-10 同时用于日志和数据，那么将拥有更大的不惧磁盘故障的韧性。如果只能将 RAID-10用于存储数据或日志中的一种，那么将它用于日志，而将 RAID-5 用于数据。如果选择将 RAID-5同时用于日志和数据，那么仍然可以拥有非常有韧性的存储配置；但是，您会发现需要更大程度上依赖于数据库备份。将表空间 EXTENTSIZE 设置为RAID 条带大小（如果做不到，则设为一个有助于读取大块数据的大小）。

RAID 阵列中每个物理磁盘上连续数据的总量称作“条块（strip）”，横跨这些全部由条块组成的阵列的数据的总量则称作“条带（stripe ）”。

典型的 RAID 条块大小是 32kb 、64kb 、128kb 等。

RAID-5 4+1 阵列上的条带大小相当于条块大小的 4 倍。

表空间的 EXTENTSIZE 应该设为包括整个 RAID 条带的页数。

例如，一个使用 RAID-5 4+1 的系统，其条块大小为 128kb ，那么该系统上的条带大小为 512kb （128kb x 4）。如果使用的页大小为 8kb ，那么将 EXTENTSIZE 设为 64 （512kb/8kb ）较为合适。

在虚拟化存储环境中设置表空间盘区大小

有时候，无法知道给定 DB2 表空间容器的文件系统存储在哪个 RAID 阵列上。如果为数据库服务器主机和存储控制器配置的 LUN之间存在其他层或存储虚拟化，那么就会出现这种情况。在此情况下，当创建表空间时，应该将 EXTENTSIZE 设为一个有利于预取程序执行有效大块I/O 的数字。较好的经验法则是将盘区大小设为 256 KB 。 128 KB 或 512 KB 的盘区大小也是不错的选择。

EXTENTSIZE 的默认设置（32 个页面，由 DFT_EXTENT_SZ配置参数指定）大多数情况下应该能提供足够的性能。例如，如果数据库使用 8 KB 的页面，在不知道 RAID 条块大小方面的详细信息时，使用 32（8 KB x 32 个页面 = 256 KB ）的 EXTENTSIZE 应该足够了。即使对于 4 KB 或 16 KB 的页面，32 的EXTENTSIZE 仍可以分别得到 128 KB 或 512 KB 的盘区大小，这符合建议的范围。

设置 DB2_PARALLEL_IO实现最佳 I/O 并行性

默认情况下，在表扫描期间，DB2 for Linux, UNIX and Windows 的 I/O服务器或预取程序为每个表空间容器执行盘区大小的 I/O 。因此，EXTENTSIZE 不仅是 DB2的条带化单位，也是预取程序在连续预取期间使用的读 I/O 大小。

如果按照上一节中的最佳实践设置 EXTENTSIZE ，那么在包含每个 DB2 容器使用的文件系统的（单个）RAID阵列中，应确保一个盘区的数据横跨所有的驱动器，然后就不需要设置 DB2_PARALLEL_IO了，因为数据库管理器将自动从容器中的所有物理磁盘中并行地预取该盘区。

除了本文提供的方式外，还有其他方式可用于设置 EXTENTSIZE 和设计 DB2 系统的条带化。

在某些配置中，另一种方式是将 EXTENTSIZE 设为使连续数据横跨每个 RAID 阵列中的一个物理磁盘。也就是说，将EXTENTSIZE 设为条块大小，而不是上一节推荐的条带大小。在这样的配置中，在连续预取期间，每个表空间容器采用单个盘区大小的 I/O便不适用，因为它只能驱动文件系统所基于的 RAID阵列中的一个物理磁盘。对于这些系统，如果想让数据库管理器生成多盘区大小的预取请求，并行地驱动用于每个 DB2 表空间容器的物理磁盘，就必须设置DB2_PARALLEL_IO 。

DB2_PARALLEL_IO允许用户显式地指定每个容器下的物理磁盘数，以便为每个容器生成适当数量的预取请求。例如，如果每个表空间容器存在于一个由 RAID 5 4+1阵列支持的文件系统上，那么下面是合适的 DB2_PARALLEL_ IO 设置：

 db2set DB2_PARALLEL_IO=*,5 
 

“* ”表示该设置适用于所有表空间。5 表示在每个容器下有 5 （4+1）个物理磁盘，每个物理磁盘都应该由一个单独的预取程序所发出的单盘区大小的读请求来驱动。

以下算法将 DB2_PARALLEL_IO 设置考虑在内：

• 当 CREATE or ALTER TABLESPACE 语句上的 PREFETCHSIZE 选项设为 AUTOMATIC 时，计算每个表空间的预取大小。
• 当 num_ioservers 配置参数设为 AUTOMATIC 时，计算 I/O 服务器或预取程序的数量。

（请参阅“不要手动调优 NUM_IOCLEANERS 、NUM_IOSERVERS 和 PREFETCHSIZE配置参数”小节，获得相关建议。）

使用 NO FILE SYSTEMCACHING 子句

NO FILE SYSTEM CACHING 子句支持直接或并发 I/O ，其中任何一个都适合 DB2数据库系统所在的操作系统平台。直接或并发 I/O 有效地使 DB2 I/O 操作在文件系统上获得接近原始设备的性能。

在 DB2 Universal Database, Version 8.2 中，对 NO FILE SYSTEM CACHING子句的支持已经被添加到 CREATE TABLESPACE 和 ALTERTABLESPACE 语句中。从 Version 9.5 开始，对于那些支持直接或并发 I/O 的文件系统，例如 JFS2、GPFS™ 和 VxFS ，新创建的数据库已默认如此。

使用 DB2 自动化存储让条带化无处不在

DB2 自动化存储（AS ）技术是为数据库配置存储的一种简单而有效的方式。存储通过 CREATE DATABASE命令直接提供给数据库，而非表空间。例如：

 DB2 CREATE DATABASE MYDB ON /data1, /data2, /data3 
 DBPATH ON /mydbpath 
 

这个例子命令创建一个数据库，它有 3 个存储路径：data1 、data2 和 data3。每个路径都是一个单独的文件系统，每个文件系统都是通过专用的 LUN 创建的。（注意：除非另外指定，否则在使用 CREATE DATABASE命令创建数据库时将默认使用自动化存储。）

CREATE DATABASE 命令上的 DBPATH参数被设为另一个单独的文件系统（/mydbpath ），该文件系统是使用为 DB2 事务日志提供的 LUN 创建的。事务日志和 DB2元数据都存放在这个文件系统上。

DB2 数据库系统创建的默认表空间（SYSCATSPACE 、USERSPACE1 和 TEMPSPACE1 ）各有 3 个控制器 —对应 3 个存储路径。

任何未显式指定容器而创建的新的表空间也是使用随处条带化的方法创建的。

例如，考虑以下 DB2 语句：

 DB2 CREATE TABLESPACE MYTS 
 

使用 CREATE TABLESPACE 语句创建的表空间 MYTS 有 3 个容器，每个容器对应一个存储路径。

虽然使用自动化存储不妨碍在同一个数据库中定义系统管理空间（SMS ）或数据库管理空间（DMS）的表空间或文件，但是自动化存储通常会消除这方面的需要。

由于 DB2存储管理器使用简单的随处条带化方法，自动化存储的最佳实践是使用容量一致的存储路径或文件系统。这样可确保并行性保持一致，不至于使某个存储路径过早地被填满，而导致某些部分的表空间的条带化宽度不同于其他表空间。

当需要为数据库增加空间时，应尽量均衡扩展所有已有的路径。也就是说，等量地增加每个文件系统的容量。

如果不能均衡扩展存储路径，那么使用 ALTER DATABASE 命令的 ADD STORAGE ON子句增加一组新的（大小均等的）存储路径。这组新的存储路径应该与原有存储路径有相同的 I/O功能。理想情况下，应该同时添加与之前定义的存储路径数量相同的存储路径。

例如，为了给之前创建的数据库 MYDB 增加空间，最佳选择是等量增加文件系统 /data1 、/data2 和 /data3的容量。

如果做不到，那么应该增加一组新的存储路径（文件系统），它们应该与原有存储路径（文件系统）具有相同的 I/O 特征：

 DB2 ALTER DATABASE ADD STORAGE ON /data4, /data5, /data6 
 

由于原有存储路径大小相同，它们要填满也是一起填满，表空间需要从额外的存储中为容器分配新的条带集 — 每个容器对应一个新的存储路径。

不要手动调优NUM_IOCLEANERS、NUM_IOSERVERS 和 PREFETCHSIZE 配置参数

这些参数的默认值是 AUTOMATIC 。DB2 数据库管理器能够很好地为这些参数选择适当的值。因此，通常不需要对它们进行手动调优。

最佳实践小结

• 每个 CPU 核使用 15-20 个专用物理磁盘
• 确保 LUN 中未使用的空间不脱离控制
• 为非 DPF DB2 数据库服务器 / DPF 数据库分区使用专用 LUN
• 最多两次条带化
• 将 DB2 事务日志和数据分开，放在不同的物理磁盘和 LUN 上
• 使用文件系统替代原始设备 —为每个 LUN 创建一个文件系统
• 对事务日志使用 RAID-10 ，对数据 LUN 使用 RAID-10 或 RAID-5
• 将表空间 EXTENTSIZE 设为 RAID 条带大小；如果 EXTENTSIZE 与条块大小相同，考虑使用 DB2_PARALLEL_IO 配置参数增加预取并行性。
• 通过 NO FILE SYSTEM CACHING 子句使用直接或并发 I/O
• 使用 DB2 自动化存储让条带化无处不在
• 为 NUM_IOCLEANERS 、NUM_IOSERVERS 和 PREFETCHSIZE 使用 AUTOMATIC （默认值）

回页首

结束语

手动将数据库表和索引映射到单独的物理磁盘和物理磁盘的一部分，这是十年前的最佳实践。驯服复杂、虚拟化、网络化存储的关键是使数据库存储设计尽可能简单。

虽然这看似违反直觉，但对复杂的事务进行简单化要好过进一步复杂化。虽然保持简单性并不总是那么容易，本文提供的最佳实践为成功的数据库存储设计提供了易于遵循的秘诀。