DB2 最佳实践: 关于数据库存储的最佳实践

核心提示：内容提要在一个网络和高度虚拟的存储世界中，正确的数据库存储设计对 DBA 或系统架构师来说似乎是一个令人恐惧的任务，DB2 最佳实践: 关于数据库存储的最佳实践，较差的数据库存储设计有可能在一个数据服务器上产生显著的负面影响， CPUs 的速度远远超过了磁盘，优化模式包括使用像 MDCs、MQTs、压缩、创建恰当的索引

内容提要

在一个网络和高度虚拟的存储世界中，正确的数据库存储设计对 DBA 或系统架构师来说似乎是一个令人恐惧的任务。

较差的数据库存储设计有可能在一个数据服务器上产生显著的负面影响。 CPUs 的速度远远超过了磁盘，要找出 I/O 限制并且在多数时间处于低于它们潜在能力性能低下的数据库服务器并不容易。

不过，一个好的消息是，比起得到的是绝对正确的结果，得到数据存储设计的错误更为重要。尝试理解存储内部堆栈并手动调整，数据库表和索引应该放置在哪个磁盘的哪一部分是一个锻炼，在镜头的虚拟存储世界中，这既不容易达到也不容易维持（对大多数的 DBA 来说）。

简单是保证良好数据库设计的关键。最基本要确保有一个足的磁盘够数目以保证系统不会变成 I/O 限制。

本文通过下面的数据库存储最佳实践、包括指南和建议，下面为一个健康的数据库服务器开了个处方：

磁盘和逻辑单元数（LUNs）

条带和条带化

事务日志和数据

文件系统 vs 裸设备

独立的磁盘冗余阵列（RAID）设备

注册变量和配置参数设置

自动存储

数据库存储介绍

在十年前，“磁盘”这个词是指一个物理主轴磁头和盘片。在今天的存储世界中，一个磁盘是存在于存储网络某个地方完全虚拟的实体，并且特可以是一个单独的物理磁盘、物理磁盘的一部分、一个 RAID 阵列或者一些 RAID 阵列的组合。

最近对文件系统的增强，比如直接和并发的 I/O，已经几乎消除了裸设备对文件系统的所有的性能优势。

当 CPU 处理器保持摩尔定律的时，它并没有应用到存储系统的速度上。不管像 SAN 和 NAS 中所介绍的存储通信的改变，还是比特在底层基础架构上如何存储基本上是一样的 - 机械的转子旋转多个磁盘片，在它上面编码比特信息。

转速增加，并使用 DRAM 和 NVRAM 来缓冲存储控制数据时有所帮助，这些持续取得的进步哪一个都无法跟上处理能力再过去十年中增加的数量级。结果就是和 CPU 速度相比，物理磁盘的速度越来越慢。这个速度差异每颗 CPU 需要一个日益增加的磁盘数目来保证系统不发生 I/O 限制。鉴于盘的能力，决定每个转子的实际能力已经有大幅度的提升了，然而要实现物理磁盘对每颗 CPU 内核有一个恰当的比例仍然非常困难。

鉴于存储、文件系统和 CPU 处理速度的变化，对于数据库存储供应和管理的最佳实践也在发展。过去一个 DBA 可能被建议去判断单独的表和索引应该放置在哪个物理磁盘上、在每块磁盘的哪个区域。在今天的虚拟存储世界中，对于大多数 DBA 过去的最佳实践是不切实际的。

这篇文章介绍的最佳实践是基于今天的存储系统发展的。

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

好的数据库存储设计有以下特征：

可预知的 I/O 和系统性能

均衡使用可用 I/O 带宽和能力 - 避免“热点”

动态管理很简单 - 例如添加新的存储

判断问题很简单

通过冗余实现高可用性

简单的数据库存储设计

“Make everything as simple as possible, but not simpler ”

Albert Einstein

在数据库存储设计的无数选择中，简单是系统架构师和 DBA 的秘密武器。这篇文档介绍的最佳实践提出了简单的经验，将对达到良好的数据库存储设计这个目标有所帮助。

简单，有时候就来自于对一个特定的表或表空间没有选择最优 I/O 特性，总有这么一种可能，一个富有经验的 DBA 拥有高超的存储技能并可以没有时间限制的去为一个非常重要的表或者索引配置一个存储。然而这样做的问题是，就算能达到设计的最佳性能，为了维护原始对象，这也经常造成对一个系统的管理变得更加复杂。

好的数据库存储设计的要点是，在一个动态系统上，实现所有目标应该是最初的系统设计的一部分，并应该在数据库运行过程中长期进行。这篇文档简单的最佳实践描述达到了这些目标并且几乎没有性能损失。

数据库存储成功的处方

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

像 DB2 数据库服务器这样的主机系统并不能直接访问物理磁盘（连接到存储控制器的），并且它们对 DBAs 也不是直接可见的。存储管理提供存像 LUNs 这样的储单元，它在主机系统上表现为真实的 SCSI 磁盘。然而，一个 LUN 是一个完全虚拟的实体，由一个存储管理器提供，并可以映射到任何磁盘组合。一个单独的 LUN 可能是一个 RAID 阵列、一个 RAID 阵列的一部分、单块磁盘、一块磁盘的一部分或者多个 RAID 阵列的“中继”。

当存储世界可能已经变得越来越虚拟化时，事实上数据仍然存放在机械的磁盘驱动上。不管是谁的第三方的存储子系统，最终数据都是存放在机械的磁盘驱动里，也就是物理磁盘。能从通过提供 LUN 得到的存储的带宽是和 LUN 包含实际磁盘数目成比例的。

当存储控制器高速缓存帮助提高存储带宽，DB2 数据库系统已经在缓冲池中缓存了相关数据。这使得它不大可能像存储控制高速缓存那样可以大量减少对物理磁盘的需求，以支持像 DB2 数据库服务器这样的 I/O 密集型系统。在一个经常有密集 I/O 的企业数据库系统中，最终的结果就是根本不能替代真正的物理硬盘。

除了传统的 SAN 存储控制器，存储虚拟化的附加层，对 DBA 而言高度抽象的物理磁盘被添进企业中。这些虚拟化的例子包括 San Volume Controller (SVC) 和 AIX VIOS 。这些虚拟化窗口可以提供令人满意的功能增强，比如迁移能力、透明、从一个 LUNs 集合到另外一个，或者为了共享光纤信道 Host Bus Adapter (HBA) 支持多个 LPARs 的能力。然而它们这么做是以产生包括在 I/O 路径上添加子系统为代价的，并且通过进一步虚拟化存储 , 常常使得 DBA 达到这个目的更加困难。

因此最佳设计的高性能 DB2 数据库服务器不包括任何额外的虚拟化，比如 SVC 或者 AIS VIOS 。如果一个企业的 I/O 基础架构需要用到这样的子系统，DBAs 需要持续确提供的保虚拟 LUNs 从真正专们的物理磁盘的到支持。

由于 CPU 处理速度，增加了一个大量的相对磁盘速度，一个好的调整标准是确保每个 CPU 有 15 到 20 个专用磁盘，这个数字可以通过应用像 DB2 压缩、多维集群（MDC）、固化查询表（MQT）这样的 I/O 技术，而得到减少并能更好的设计、计划和管理。

值得注意的是，在撰写本文的时候，磁盘的数目是假设处理器和磁盘技术是在企业中普遍的技术。包括 Power 5、Intel Xenon 和 AMD Opeteron 处理器。普遍的磁盘转速是每分钟 15000 转。可以预见，随着下一代处理器的普及，对 I/O 密集的数据库服务器而言，每个处理器内核将需要更多的磁盘。

如果只有太少的物理磁盘来保证 CPUs 忙碌，一个企业系统很快会发生 I/O 限制。不幸的是我们关心的是那些数据库性能相关的存储通信在物理磁盘数目方面，剩下大多数他的存储管理员考虑的是存储在空间上的需要

因为在过去十年中盘的大小已经得到了充分的提高每个 CPU 获得充足的磁盘数目变得更高了。

通常为每颗 CPU 内核提供 20 个磁盘并且每个 150GB 大小，你将拥有 3TB 的可用空间。为了满足性能需求每，颗 CPU 3TB 的可用空间会导致空闲空间。

在不考虑空间浪费的情况下，保证存储管理员不通过给其他用户提供空间（给其他数据库或其他应用程序）来利用这些空闲空间或者吧 LUN 分给其他数据库分区。

你可以适度利用这些空间作为在线备份或者归档日志被归档到磁带之前的临时空间。如果为了空间利用最大化而使用这个策略，你必须了解数据和备份共享了相同的磁盘。因此备份必须及时的被归档到外部存储目标，例如 Tivoli Storage Manager (TSM).

这个技术可以很好的利用多余的空间，因为它完全在 DBAs 的控制之下，比如什么时候进行备份；并且备份通常在非 I/O 吞吐量高峰执行。

由于预计 CPU 速度会持续增长，即使在额外并行状态下，内核尤其是时钟频率的趋势是每个 CPU 内核需要更多的物理磁盘，以确保数据库不发生 I/O 限制更为重要。而非之前的 DBAs 花费时间去确保他们通过良好的模式设计和利用 DB2 的高级功能，如 MDC、MQTs 和压缩，消除了尽可能多的 I/O 操作。

每个 non-DPF 的数据库服务器 /DPF 分区 有专用 LUNs 和文件系统

对于每个 non-DPF DB2 数据库服务器和每个 DPF 数据库分区专用 LUNs 是一个最佳实践。一个单独的文件系统应该被创建在每个这样的 LUN 上并且应该只被一个单独的 non-DPF DB2 书库服务器或者 DPF 数据库分区使用。

专用 LUNs 和每个 LUN 的文件系统保持了存储不去简单并有助于问题诊断。

对于 DPF 系统，这是推荐的并在 IBM Balanced Configuration Warehouse 得到遵守。

关于这个技术如何帮助问题判断的一个例子是，表上挑选不当的分区键将阻止一个查询得到全的并行性。当数据库分区有专用 LUNs 和文件时这个问题就变得很明显了，当你看到一组 LUNs 比其他 LUNs 更忙，因为一个分区拥有需要处理的所有的数据，而其他分区只有一点相关数据。

最多两次条带化

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

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

因为两层条带化对所有的系统都算足够了，要避免使用一个三层条带化，想操作系统逻辑卷管理器。逻辑卷管理器（LVM）条带化对于非 DB2 数据库系统的其它自己没有条带能力中间件来说是有好处的。

把 DB2 事务日志和数据分开

为了最好的可用性，把事务日志和 DB2 数据分或表空间分开，分别放在不同的磁盘和在不同的 LUNs 上。应该为每个 DB2 分区上的事务日志提供专门的磁盘，并且一般情况下有多个 LUNs 给它的表空间容器，或数据。

日志磁盘数目对数据磁盘数目的比例完全取决于工作负载，一个比较好的调整标准是 15% 到 25% 的磁盘给日志，75% to 85% 的磁盘给数据。

用文件系统替代裸设备 - 每个 LUN 一个文件系统

直接 I/O 和并行 I/O 已经几乎完全消除了为了性能需要使用裸设备的需求。文件系统提供了比裸设备要更好地管理能力，像一个文件系统可以作为一个容器被多个表空间使用。

一个 LUN 用于一个数据库分区时，应该被用于创建一个单独的文件系统给分区使用，即每个 LUN 一个文件系统。

每个 DB2 分区一般有：

一个事务日志文件系统 - 使用 LUN 创建，用于分区的事务日志。

多个数据文件系统 - 每个文件系统是使用它自己单独的 LUNs 创建，用于表空间数据。

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

RAID-10 能通过够容忍多个磁盘故障来提供极好的冗余。不过，RAID-10 的成本比 RAID-5 高。不像 RAID-10，RAID-5 只能容忍一个磁盘故障。

对于事物日志来书 RAID-10 是一个极好的选择。

如果可以承受，RAID-10 对数据 LUNs 也同样是极好的选择。另外，对数据 LUNs 一个好的选择是 RAID-5，它的成本比 RAID-10 低。

设置 DB2_PARALLEL_IO 注册变量

默认情况下，DB2 数据库管理器并不知道一个并行 RAID 设备被用于它的表空间容器。设置 DB2_PARALLEL_IO 注册变量让数据库系统知道这一点。

DB2_PARALLEL_IO 的语法允许你指定受影响的表空间和每个容器的并行度，即每个容器下面的磁盘数目。

例如，如果 RAID-5 4+1 LUNs 作为数据 LUNs 提供并且在每个 LUN 上创建了文件系统，一个合理的 DB2_PARALLEL_IO 设置如下：

db2set　DB2_PARALLEL_IO=　*:4

“ * ”通配符告诉 DB2 管理器应用这个设置到所有的表空间（就像我们打算条带化一切）而且每个容器的磁盘数是 4.

根据条带的大小来设置 EXTENTSIZE 子句的值

在一个 RAID 阵列中每个磁盘上连续的数据的总量叫作“条带”，而且这些分布在一个阵列中的组成所有条带的数据量，叫一个“条带”。

一般 RAID 条带大小是 32kb, 64kb, 128kb，等等。

一个 RAID-5 4+1z 阵列有一个等于 4 倍带大小的条带，因为在这个阵列里有 4 个 non-parity 磁盘。

表空间的 EXTENTSIZE 应该被设置成可以包含一个 RAID 条带的页码数目。

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

使用 NO FILE SYSTEM CACHING 子句

NO FILE SYSTEM CACHING 字句启用直接 I/O 或并发 I/O，无论哪个一个都适用于 DB2 数据库系统运行的操作系统平台。直接 I/O 或并发 I/O 使 DB2 I/O 操作在文件系统上像裸设备一样有效率。

从 DB2 通用数据库 8.2 版本开始，在 CREATE TABLESPACE 和 ALTER TABLESPACE 命令中就添加了对 NO FILE SYSTEM CACHINAG 子句的支持。

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

DB2 自动存储（AS）技术是一个简单而有效的方法来为一个数据库提供存储。使用 CREATE DATABASE 命令，存储是提供给数据库的而不是单独的表空间。例如：

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

这个命令创建了一个数据库，它有 3 个存储路径：data1、data2 和 data3 。这 3 个路径都是单独的文件系统，每一个都是使用一个专门的 LUN 创建的。

DBPATH 参数设置到另外一个使用 LUN 创建的单独的文件系统（/mydbpath），用于 DB2 事务日志。事务日志和 DB2 元数据都存在于这个文件系统。

DB2 数据库系统创建的默认的表空间（SYSCATSPACE、USERSPACE1 和 TEMPSPACE1）每个都拥有 3 个容器 - 每一个容器都在这 3 个存储路径下。

任何新的表空间在创建时不指定容器，也将使用条带化一切的方式。

例如，考虑下面 DB2 命令：

DB2　CREATE　TABLESPACE　MYTS

使用这个命令创建的 MYTS 表空间也有 3 个容器，在每个存储路径上有一个。

当使用自动存储并不意味你不能在这个数据库里创建系统管理表空间（SMS）或者数据库管理表空间（DMS），自动存储使你不需要定义它们。

因为 DB2 存储管理器使用一个简单的无处不在条带方法，自动存储的最佳实践是使用存储路径或者文件系统，而且它们在能力上没有区别。这确保并行性保持一致，因为一个存储路径不被过早填满因而导致一些表空间的一部分和其他部分有条带宽度差异。

当需要往数据库中添加空间时，尝试统一扩展现有的所有路径。这样在每个文件系统上增加相同的数量。

如果你不能统一扩展存储路径，使用 ALTER DATABASE 来添加一个新的路径集合。理想的情况是应该一起添加之前定义的相同数目存储路径。

例如，为了给之前创建的 MYDB 数据库增加空间，最好的选项是通过增加相同的数量来提高文件系统 /data1、 /data2 和 /data3 的能力。

如果不能，那么应该添加一组具有和原来相同 I/O 特征的新的存储路径（文件系统）

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

因为远离存储是统一大小，当它们装满就是一起满，表空间需要从额外的存储中为容器分配新的条带集 —每个容器路径一个。

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

这些参数的默认值是 AUTOMATIC 。 DB2 数据库管理器在为这些参数选择正确值上做得非常好；因此它们不需要手动调整。

建议 & 最佳实践
每颗 CPU 内核使用 15-20 DEDICATED 磁盘 为 non-DPFDB2 数据库服务器 /DPF 数据库分区分配 LUNs 最多条带化两次 把 DB2 事务日志和数据分别放在不同的磁盘和 LUNs 使用文件系统替代裸设备—一个 LUN 创建一个文件系统 对事务日志使用 RAID-10，对数据 LUNs 使用 RAID-10 或者 RAID-5 设置 DB2_PARALLEL_IO 注册变量 设置 RAID 条带大小的 EXTENTSIZE 通过使用 NO FILE SYSTEM CACHING 子句来使用直接 I/O 或者并发 I/O 对无处不在的条带化使用 DB2 自动存储对 NUM_IOCLEANERS、NUM_IOSERVERS 和 PREFETCHSIZE 使用 AUTOMATIC（默认）。

总结与结论

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

首先这看起来是违法直觉的，对复杂的事务进行简单化要好于进一步复杂化。虽然简单化并不总是那么容易，本文提供的最佳实践提供了成功设计数据库存储的一个很容易遵循的的方法。

首先，一个 DBA 的时间和精力最好花费在优化数据库模式上，而不是物理数据库存储。优化模式包括使用像 MDCs、MQTs、压缩、创建恰当的索引并删除不恰当的索引这样的功能。最后，如果没有比 1 更高的吞吐量或比低于 1 的 I/O 就不需要执行所有这些。