DB2最佳实践DB2数据库存储机制

DB2最佳实践:DB2数据库存储机制执行摘要随着存储的网络化和高度虚拟化，对于DBA或系统架构师来说，数据库存储设计似乎是一项极其复杂的任务。糟糕的数据库存储设计对数据库服务器有极大的负面影响。由于CPU比物理磁盘快得多，所以常常可以发现性能糟糕的数据库服务器，它们面临非常密集的I/O，表现出来的性能离它们的真正潜能差好多倍。好消息是，保证数据库存储的设计不犯错误，比获得完美的数据库存储设计更重要。在如今虚拟化存储的环境中，试图理解数据存储栈的内部结构，并手动调优数据库表和索引在物理磁盘上的存储位置，这些事情通常既不容易完成，也不易于维护（对于一般的DBA而言）。简单性是良好数据库存储设计的关键。首先，要确保有足够的物理磁盘，以避免系统成为I/O密集型系统。本文介绍通过一些易于学习的数据库存储最佳实践获得健全数据库服务器的秘诀，包括以下方面的一些指南和建议：物理磁盘和逻辑单元数（LUN）条带（Stripe）和条带化（striping）事务日志和数据文件系统与原始设备独立磁盘冗余阵列（RedundantArrayofIndependentDisks，RAID）设备注册表变量和配置参数设置自动化存储注意：本文所述最佳实践用于在常规OLTP环境中部署DB2forLinux,UNIXandWindows。文中讨论的建议不一定适用于数据仓库环境，也不一定适用于将DB2数据库用作第三方软件底层数据库的环境。数据库存储简介存储区域网（StorageAreaNetworks，SAN）和网络连接存储（NetworkAttachedStorage，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）”方便的持续管理—例如增加新存储方便的问题诊断通过冗余获得的高可用性简单的数据库存储设计“使一切尽量简单，但是不过于简单”–AlbertEinstein在设计数据库存储时，需要做出很多的选择，简单化是系统架构师和DBA的秘密武器。本文提供的最佳实践提出了一些简单的经验法则，它们将有助于实现良好数据库存储设计的所有目标。这种简单化有时候要付出代价，即不能为特定的表或表空间选择最优的I/O特征。具有丰富存储技能的有经验的DBA，以及时间充裕的存储管理员，往往会从物理磁盘中为特别重要的表或索引开辟一片存储。这种方法存在的问题是，这样做也许在设计时能取得最佳性能，但是为了维护最初的设计目标，最后往往会得到一个更难以管理的系统。问题诊断几乎总是很困难——最初认为足够用于特别重要的表或索引的存储带宽，随着时间的推移和应用程序的增长变得不够起来。良好数据库存储设计的要点在于，在动态的系统上，所有目标在最初的系统设计时能够得到满足，且在数据库投入使用时仍然如此。本文描述的简单的最佳实践可以实现这些目标，且几乎不会牺牲任何性能。数据库存储成功秘诀考虑实际的物理磁盘，而不仅仅是存储空间物理磁盘与存储控制器相连，DB2数据库服务器等主机系统不能直接访问它们，DBA也不能直接看到它们。存储管理员以逻辑单元数1（logicalunitnumbers，LUN）的形式提供存储单元，而主机系统看到的则是真正的SCSI磁盘。但是，LUN是由存储管理员提供的完全虚拟的实体，可映射物理磁盘的任何组合。一个LUN可以是单一RAID阵列、RAID阵列的一部分、一个物理磁盘、磁盘的一部分或者多个RAID阵列的“元设备（meta）”。虽然存储世界变得更加虚拟化，但事实上数据仍然存储在机械磁盘驱动器上。无论使用哪家供应商的存储子系统，最终数据仍存储在机械磁盘驱动器上，也就是旋转的物理磁盘碟片上。LUN可提供的存储带宽与组成它的实际物理磁盘的数量成正比。虽然存储控制器缓存可帮助提高存储带宽，但DB2数据库系统已经将相关数据缓存到它们的缓冲池中。这限制了存储控制器充分减少实际物理磁盘需求，以支持DB2数据库服务器等I/O密集型系统的能力。在通常为I/O密集型的企业数据库系统中，最终结果是完全找不到实际物理磁盘的替代品。除了传统的SAN存储控制器外，附加的存储虚拟化层也正在被添加到企业中，它们进一步为DBA抽象物理磁盘。这种虚拟化的例子有SanVolumeController(SVC)和AIX®VIOS。这些形式的虚拟化可提供称心的功能增强，例如透明地从一组LUN向另一组LUN迁移的能力，或者多个主机LPAR共享一条光纤通道HostBusAdapter(HBA)的能力。但是，这样做需要付出一定的代价，通常包括I/O路径中出现更多的子系统。此外，对于I/O密集型系统，它们并不能减少对实际物理磁盘的需求。处理高度虚拟化的存储如本文简介部分所述，磁盘存储越来越多地被当做一种普通用品，可用存储空间常常被从其所在物理设备中抽象出来。如果您的企业的I/O基础结构要求使用这样的存储系统，那么DBA需要继续确保所提供的虚拟LUN真正由专用的物理磁盘组成。原因是：如果实际磁盘太少，跟不上CPU的速度，那么企业系统很快会变成I/O密集型系统。不幸的是，虽然我们这些关心数据库性能的人是以实际磁盘数量来衡量存储需求的，但存储管理员却不同，他们只按空间的概念来考虑存储需求。虽然过去十来年碟片大小有了长足的进步，但若要增加每个CPU核的物理磁盘数而不仅仅是空间，只会变得越来越难。更糟糕的是，数据库管理员知道需要多少物理磁盘来确保良好性能，却不得不为拥有太多空间而辩护。例如，假设有一个CPU核和20个物理磁盘。这样的磁盘-CPU比例应该可以产生足够的I/O并行性来提供很好的性能。如果每个磁盘设备可以存储150GB，那么每个CPU核有大约3TB的空间。如果有多个CPU核，每个核按1:20的比例配备物理磁盘，那么存储的总量将以惊人的速度增长。虽然有这么多“空闲”的空间，但重要的是这样的存储并不会过量。例如，您可能想将一些未使用的存储分配给其他应用程序或进程。但是要记住，相互竞争的应用程序或进程发出太多的每秒I/O操作（I/O-operations-per-second，IOPS）可能导致所有应用程序的性能下降。这意味着存储管理员应该抵制诱惑，不要将未使用的空间作为单独的LUN分配给DBA无权控制的其他应用程序。现在，可以在将数据库备份到长期存储之前，将未使用的空间用作数据库在线备份或归档日志的staging区域。这是非常合理的用法，因为当执行备份时，一切都在您的控制之下。换句话说，当使用这些设备时，完全由您（而不是其他未知的用户或应用程序）控制。您可以在不需要峰值I/O吞吐量的时候执行在线备份。如果使用这样的策略来最大化空间使用率，那么要记住，为数据和备份使用相同的磁盘将不可避免地带来一定的风险。应该适时地将备份归档到外部备份目标，例如Tivoli®StorageManager(TSM)。由于CPU速度有望继续增长（增长方式是通过增加CPU核提高处理并行性，而不是增加时钟频率），预期的趋势是，为确保数据库服务器不成为I/O密集型系统，每个系统将需要越来越多的物理磁盘。因此，DBA应通过良好的模式设计，并利用DB2数据库系统中的高级功能，例如MDC、MQT和压缩，尽可能消除I/O操作，这一点比以往更重要。相对于碟片速度，CPU处理速度有了更快的增长，因此好的经验法则是确保每个CPU核有15到20个专用物理磁盘。通过使用多维集群（MultidimensionalClustering，MDC）等I/O技术，以及良好的模式管理和设计，这个数字有可能减少。值得注意的是，在撰写本文之际，此处所说的物理磁盘数量只针对企业中的普通处理器和磁盘技术。这包括IBMPOWER5™、Intel®Xeon®和AMD®Opteron™处理器。普通的主轴速度是15000rpm。当下一代处理器普及时，对于I/O密集型数据库服务器，每个处理器将需要大量的物理磁盘。为每个非DPFDB2数据库服务器/每个DPF分区使用专用LUN和文件系统最好不要在DB2服务器/分区之间共享LUN和物理磁盘。最佳实践是为每个非DPFDB2数据库服务器和每个DPF数据库分区使用专用LUN。将LUN专用于DB2服务器或分区确实会阻碍将组成该LUN的物理磁盘用于创建单独的LUN，虽然创建的LUN的使用不大可能干扰那些磁盘的主要用途。但是，如上一节所述，您应该确保这些LUN在您的控制之下，并谨慎地加以使用。之前讨论的将剩余空间用于备份和归档日志的staging区域就属于这样的用途。单个的文件系统应该在每个这样的LUN上创建，并且应该专用于单个DB2服务器或DPF数据库分区。专用的LUN和每个LUN上专用的文件系统可保持存储布局的简单性，并且有助于问题诊断。对于DPF系统，建议遵循IBMBalancedConfigurationWarehouse实践。例如，当在一个表上选择了不恰当的分区键时，查询便不能获得应有的并行性，如果采用上述做法，这个问题就可轻易诊断出来。当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%的物理