《DB2 最佳实践 DB2 数据库存储机制》由会员分享，可在线阅读，更多相关《DB2 最佳实践 DB2 数据库存储机制（10页珍藏版）》请在金锄头文库上搜索。
1、DB2最佳实践：DB2数据库存储机制执行摘要随着存储的网络化和高度虚拟化，对于DBA或系统架构师来说，数据库存储 设计似乎是一项极其复杂的任务。糟糕的数据库存储设计对数据库服务器有极大的负面影响。由于CPU比物理磁 盘快得多，所以常常可以发现性能糟糕的数据库服务器，它们面临非常密集的 I/O，表现出来的性能离它们的真正潜能差好多倍。好消息是，保证数据库存储的设计不犯错误，比获得完美的数据库存储设计更重 要。在如今虚拟化存储的环境中，试图理解数据存储栈的内部结构，并手动调优 数据库表和索引在物理磁盘上的存储位置，这些事情通常既不容易完成，也不易 于维护(对于一般的DBA而言)。简单性是良好数据库
2、存储设计的关键。首先，要确保有足够的物理磁盘，以避免 系统成为I/O密集型系统。本文介绍通过一些易于学习的数据库存储最佳实践获得健全数据库服务器的秘 诀，包括以下方面的一些指南和建议： 物理磁盘和逻辑单元数(LUN )条带(Stripe )和条带化(striping )事务日志和数据文件系统与原始设备 独立磁盘冗余阵列(Redundant Array of Independent Disks， RAID )设备 注册表变量和配置参数设置自动化存储注意：本文所述最佳实践用于在常规OLTP环境中部署DB2 for Linux, UNIX and Windows。文中讨论的建议不一定适用于数据仓库环
3、境也不一定适用于将 DB2数据库用作第三方软件底层数据库的环境。数据库存储简介存储区域网(Storage Area Networks , SAN )和网络连接存储(Network Attached Storage，NAS )从根本上改变了数据库存储世界。大约十年前，磁盘一词指 的是具有磁头和碟片的物理磁盘。在如今的存储世界，磁盘是一个完全虚拟的 实体，它位于存储网络上，可以是单独的物理磁盘、物理磁盘的一部分、RAID阵 列或者RAID阵列的某种组合。最近在文件系统方面取得的进步，例如直接和并发I/O，让原始设备较之于文 件系统的所有性能优势几乎消失殆尽。虽然摩尔定律对CPU处理能力有效，但是并
4、不适用于存储子系统的速度。尽管 SAN和NAS使存储通信发生了变化，但是决定如何存储比特的底层结构基本 不变一机械主轴转动多个磁性材料的碟片，这些碟片上面是对信息编码后得到 的比特。虽然主轴速度有所提高，使用DRAM 和NVRAM 的存储控制器上的数据缓存 亦有所帮助，但是这些进步都无法赶上过去十年来处理能力的急剧提升。因此， 相对于CPU的处理速度，磁盘要慢得多。这种速度上的差异使得每个CPU核 必须配备越来越多的物理磁盘，以确保系统不成为I/O密集型系统。虽然决定 每个物理磁盘实际容量的碟片容量有了很大的提高，但是仍然难以达到适当的物 理磁盘数与CPU核的比例。随着存储、文件系统和CPU处
5、理速度的变化，数据库存储自动配置和管理的最 佳实践也在演变。在过去，可能会建议DBA将表和索引放到确切的物理磁盘 上，甚至是每个物理磁盘的哪一部分上。但是在如今的虚拟化存储世界，对于一 般DBA而言，过去的最佳实践显得不切实际。本文提供的最佳实践则是围绕如今现实的存储环境而开发的。请参阅-DB2最佳实践：物理数据库设计最佳实践白皮书，获得关于数据库性能 和数据库操作速度的相关信息。该白皮书和其他相关资料可从DB2最佳实践专 题获得。良好数据库存储设计的目标良好的数据库存储设计必须有以下重要特征:可预测的I/O和系统性能对I/O带宽和容量的均衡使用一避免热点（hot-spot）|方便的持续管理一
6、例如增加新存储方便的问题诊断通过冗余获得的高可用性简单的数据库存储设计“使一切尽量简单，但是不过于简单Albert Einstein 在设计数据库存储时，需要做出很多的选择，简单化是系统架构师和DBA的 秘密武器。本文提供的最佳实践提出了一些简单的经验法则，它们将有助于实现 良好数据库存储设计的所有目标。这种简单化有时候要付出代价，即不能为特定的表或表空间选择最优的I/O特 征。具有丰富存储技能的有经验的DBA，以及时间充裕的存储管理员，往往 会从物理磁盘中为特别重要的表或索引开辟一片存储。这种方法存在的问题是， 这样做也许在设计时能取得最佳性能，但是为了维护最初的设计目标，最后往往 会得到一
7、个更难以管理的系统。问题诊断几乎总是很困难最初认为足够用于 特别重要的表或索引的存储带宽，随着时间的推移和应用程序的增长变得不够起 来。良好数据库存储设计的要点在于，在动态的系统上，所有目标在最初的系统设计 时能够得到满足，且在数据库投入使用时仍然如此。本文描述的简单的最佳实践 可以实现这些目标，且几乎不会牺牲任何性能。数据库存储成功秘诀考虑实际的物理磁盘，而不仅仅是存储空间物理磁盘与存储控制器相连，DB2数据库服务器等主机系统不能直接访问它们, DBA也不能直接看到它们。存储管理员以逻辑单元数1 (logical unit numbers LUN )的形式提供存储单兀，而主机系统看到的则是真
8、正的SCSI磁盘。但是, LUN是由存储管理员提供的完全虚拟的实体，可映射物理磁盘的任何组合。一 个LUN可以是单一 RAID阵列、RAID阵列的一部分、一个物理磁盘、磁盘 的一部分或者多个RAID阵列的元设备(meta ) ”。虽然存储世界变得更加虚拟化，但事实上数据仍然存储在机械磁盘驱动器上。无 论使用哪家供应商的存储子系统，最终数据仍存储在机械磁盘驱动器上，也就是 旋转的物理磁盘碟片上。LUN可提供的存储带宽与组成它的实际物理磁盘的数 量成正比。虽然存储控制器缓存可帮助提高存储带宽，但DB2数据库系统已经将相关数据 缓存到它们的缓冲池中。这限制了存储控制器充分减少实际物理磁盘需求，以支
9、持DB2数据库服务器等I/O密集型系统的能力。在通常为I/O密集型的企业 数据库系统中，最终结果是完全找不到实际物理磁盘的替代品。除了传统的SAN存储控制器外，附加的存储虚拟化层也正在被添加到企业中， 它们进一步为DBA抽象物理磁盘。这种虚拟化的例子有San Volume Controller (SVC)和AIX VIOS。这些形式的虚拟化可提供称心的功能增强，例如透明 地从一组LUN向另一组LUN迁移的能力，或者多个主机LPAR共享一条光 纤通道Host Bus Adapter (HBA)的能力。但是，这样做需要付出一定的代价， 通常包括I/O路径中出现更多的子系统。此外，对于I/O密集型系
10、统，它们并 不能减少对实际物理磁盘的需求。处理高度虚拟化的存储如本文简介部分所述，磁盘存储越来越多地被当做一种普通用品，可用存储空间 常常被从其所在物理设备中抽象出来。如果您的企业的I/O基础结构要求使用这样的存储系统，那么DBA需要继续 确保所提供的虚拟LUN真正由专用的物理磁盘组成。原因是：如果实际磁盘太 少，跟不上CPU的速度，那么企业系统很快会变成I/O密集型系统。不幸的 是，虽然我们这些关心数据库性能的人是以实际磁盘数量来衡量存储需求的，但 存储管理员却不同，他们只按空间的概念来考虑存储需求。虽然过去十来年碟片 大小有了长足的进步，但若要增加每个CPU核的物理磁盘数而不仅仅是空间，
11、只会变得越来越难。更糟糕的是，数据库管理员知道需要多少物理磁盘来确保良好性能，却不得不为 拥有太多空间而辩护。例如，假设有一个CPU核和20个物理磁盘。这样的磁 盘-CPU比例应该可以产生足够的I/O并行性来提供很好的性能。如果每个磁 盘设备可以存储150 GB，那么每个CPU核有大约3 TB的空间。如果有多 个CPU核，每个核按1:20的比例配备物理磁盘，那么存储的总量将以惊人的 速度增长。虽然有这么多空闲的空间，但重要的是这样的存储并不会过量。例如，您可能 想将一些未使用的存储分配给其他应用程序或进程。但是要记住，相互竞争的应 用程序或进程发出太多的每秒I/O操作(I/O-operatio
12、ns-per-second ，IOPS )可 能导致所有应用程序的性能下降。这意味着存储管理员应该抵制诱惑，不要将未 使用的空间作为单独的LUN分配给DBA无权控制的其他应用程序。现在，可以在将数据库备份到长期存储之前，将未使用的空间用作数据库在线备 份或归档日志的staging区域。这是非常合理的用法，因为当执行备份时，一切 都在您的控制之下。换句话说，当使用这些设备时，完全由您(而不是其他未知 的用户或应用程序)控制。您可以在不需要峰值I/O吞吐量的时候执行在线备 份。如果使用这样的策略来最大化空间使用率，那么要记住，为数据和备份使用相同 的磁盘将不可避免地带来一定的风险。应该适时地将备份
13、归档到外部备份目标， 例如 Tivoli Storage Manager (TSM)。由于CPU速度有望继续增长(增长方式是通过增加CPU核提高处理并行性， 而不是增加时钟频率)，预期的趋势是，为确保数据库服务器不成为I/O密集 型系统，每个系统将需要越来越多的物理磁盘。因此，DBA应通过良好的模式 设计，并利用DB2数据库系统中的高级功能，例如MDC、MQT和压缩，尽 可能消除I/O操作，这一点比以往更重要。相对于碟片速度，CPU处理速度有了更快的增长，因此好的经验法则是确保每 个CPU核有15到20个专用物理磁盘。通过使用多维集群(Multidimensional Clustering，M
14、DC )等I/O技术，以及良好的模式管理和设计，这个数字有可 能减少。值得注意的是，在撰写本文之际，此处所说的物理磁盘数量只针对企业中的普通 处理器和磁盘技术。这包括IBM POWER5 tm、Intel Xeon和 AMD Opteron 处理器。普通的主轴速度是15000 rpm。当下一代处理器普及时，对于I/O 密集型数据库服务器，每个处理器将需要大量的物理磁盘。为每个非DPF DB2数据库服务器/每个DPF分区使用专用LUN和文件系统最好不要在DB2服务器/分区之间共享LUN和物理磁盘。最佳实践是为每 个非DPF DB2数据库服务器和每个DPF数据库分区使用专用LUN。将LUN专用于D
15、B2服务器或分区确实会阻碍将组成该LUN的物理磁盘用 于创建单独的LUN，虽然创建的LUN的使用不大可能干扰那些磁盘的主要 用途。但是，如上一节所述，您应该确保这些LUN在您的控制之下，并谨慎地 加以使用。之前讨论的将剩余空间用于备份和归档日志的staging区域就属于这 样的用途。单个的文件系统应该在每个这样的LUN上创建，并且应该专用于单个DB2服 务器或DPF数据库分区。专用的LUN和每个LUN上专用的文件系统可保持存储布局的简单性，并且 有助于问题诊断。对于 DPF 系统，建议遵循 IBM Balanced Configuration Warehouse 实践。例如，当在一个表上选择了
16、不恰当的分区键时，查询便不能获得应有的并行性， 如果采用上述做法，这个问题就可轻易诊断出来。当LUN和文件系统专用于数 据库分区时，如果看到一组LUN的繁忙时间远多于其他LUN，那么这个问 题就变得很明显了，因为一个分区上存放了所有需要处理的数据，而其他分区上 的数据则相对较少。最多两次条带化 存储控制器直接在控制器固件中提供了杰出的RAID条带化。应该将企业系统 设计为使用存储控制器提供的条带功能。这么做的一个更方便的途径是让存储控 制器暴露一个单独的RAID阵列，例如，让RAID-5或RAID-10作为一个单 独的LUN。然后，可以将一个或多个这样的LUN提供给DB2分区。当把不止一个LUN提供给DB2数据库服务器或DPF数据库分区时，则使用 DB2数据库系统容器更细的条带。由于两次条带化对所有的系统都算足
