内容提要
在一个网络和高度虚拟的存储世界中，正确的数据库存储设计对 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 数据分或表空间分开，分别放