DB2最佳实践DB2数据库存储机制概要.docVIP

DB2 最佳实践: DB2 数据库存储机制 执行摘要 随着存储的网络化和高度虚拟化，对于 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 ，以及时间充裕的存储管理员，往往会从物理磁盘中为特别重要的表或索引开辟一片存储。这种方法存在的问题是，这样做也许在设计时能取得最佳性能，但是为了维护最初的设计目标，最后往往会得到一个更难以管理的系统。问题诊断几乎总是很困难——最初认为足够用于特别重要的表或索引的存储带宽，随着时间的推移和应用程序的增长变得不够起来。 良好数据库存储设计的要点在于，在动态的系统上，所有目标在最初的系统设计时能够得到满足，且在数据库投入使用时仍然如此。本文描述的简单的最佳实践可以实现这些目标，且几