软件测试中数据仓库的 RDBMS 性能优化指南

	简介
	性能优化的基本原则
	优化磁盘 I/O 性能
	使用分区来提高性能
	查找更多信息

本性能优化指南旨在帮助数据库管理员和开发人员配置 Microsoft® SQL Server™ 2000，以获得最佳的性能，并帮助找出造成关系数据库（包括用于数据仓库的数据库）性能低下的原因。本指南还就如何装载、索引和编写查询以访问 SQL Server 中存储的数据提供了指导原则和最佳做法。另外还介绍了多种可用于分析性能特征的 SQL Server 工具。

简介

Microsoft SQL Server 7.0 中引入了一项重大改进：一个在很大程度上可以自行配置、自行优化和自行管理的数据库引擎。在 SQL Server 7.0 面世之前，大多数数据库服务器都会耗费数据库管理员大量的时间和精力，他们必须手动优化服务器配置以获得最佳性能。实际上，很多竞争性数据库产品现在仍要求管理员手动配置和优化他们的数据库服务器。这是许多客户改用 SQL Server 的主要原因。SQL Server 2000 是在 SQL Server 7.0 奠定的坚实基础上更上层楼的产品。SQL Server 的目标是：通过实现数据库引擎自行优化并允许 DBA 自动完成管理任务，使 DBA 不必手动配置和不断优化数据库服务器。

尽管现在仍可以手动配置和调整一些 sp_configure 选项，但建议数据库管理员尽量不要这样做，而是让 SQL Server 自动配置和优化。对于这种调整能力，SQL Server 7.0 具有已被广泛认可且经过实践证明的成绩记录，SQL Server 2000 对此方案进行了显著的改进。环境中不断变化的条件可能会对数据库性能产生负面影响，所以，让 SQL Server 自行优化，就可以使数据库服务器进行动态调整以适应这些变化。

性能优化的基本原则

您可以采取许多措施来管理数据库的性能。SQL Server 2000 提供了几种工具来帮助您完成这些任务。

管理性能

• 让 SQL Server 完成大多数优化任务。
  SQL Server 2000 经过了重大改进，可以创建基本上能够进行自动配置和自行优化的数据库服务器。利用 SQL Server 自动优化设置这一优点，可帮助 SQL Server 即使在用户负荷和查询随时间不断变化的情况下也能以最高性能运行。
  
  
• 管理 RAM 缓存。
  RAM 是一种有限的资源。任何数据库服务器环境的一个主要部分就是管理随机存取存储器 (RAM) 缓冲区缓存。访问 RAM 缓存中的数据比访问磁盘中同样的信息要快得多。但是，RAM 资源是有限的。如果可以将数据库 I/O（针对物理磁盘子系统的输入/输出操作）减少到最低所需的数据集和索引页，这些页将在 RAM 中停留更长时间。如果流入缓冲区缓存的不必要的数据和索引信息过多，会将有价值的页很快排挤出去。性能优化的主要目标是减少 I/O，以使缓冲区缓存得到最充分的利用。
  
  
• 创建和维护合适的索引。
  对于所有的数据库查询，维护最小 I/O 的一个关键因素是确保创建和维护合适的索引。
  
  
• 对大数据集和索引进行分区。
  要减少总体 I/O 争用现象并改善并行操作，请考虑对表数据和索引进行分区。本章介绍了使用 SQL Server 2000 实现和管理分区的多种方法。
  
  
• 监视磁盘 I/O 子系统的性能。
  物理磁盘子系统必须为数据库服务器提供足够的 I/O 处理能力，以使数据库服务器在运行时不会出现磁盘排队现象。磁盘排队现象会导致性能不佳。本文介绍了如何检测磁盘 I/O 问题以及如何解决这些问题。
  
  
• 优化应用程序和查询。
  当数据库服务器通过给定的应用程序为来自成百上千个连接的请求提供服务时，这种优化变得尤为重要。由于应用程序通常会确定要在数据库服务器上执行的 SQL 查询，所以应用程序开发人员一定要了解 SQL Server 的结构基础知识以及如何充分利用 SQL Server 的索引来最小化 I/O。
  
  
• 优化活动数据。
  在许多商业智能数据库中，绝大多数数据库活动都会涉及最近一个月或一个季度的数据（多达 80% 的数据库活动都可能是因最近装载的数据而发生的）。要保持良好的数据库总体性能，在对这些数据进行装载、索引和分区时，所采取的方式一定要能够为这些数据提供最佳的数据访问性能。

利用 SQL Server 性能工具

• SQL 事件探查器和索引优化向导
  SQL 事件探查器可用于监视和记录 SQL Server 的工作负荷。然后，可以将记录下来的工作负荷可以提交到索引优化向导，这样，在必要的时候就可以更改索引来帮助提高性能。SQL 事件探查器和索引优化向导可帮助管理员实现优化的索引。定期使用这些工具可使 SQL Server 保持良好的性能，即使查询工作负荷随时间而变化也是如此。
  
  
• SQL 查询分析器和图形执行计划
  在 SQL Server 2000 中，SQL 查询分析器提供了“图形执行计划”，使用这种方法可以方便地分析有问题的 SQL 查询。“统计 I/O”是 SQL 查询分析器的另一个重要功能，本章后面将会进行介绍。
  
  
• 系统监视器对象
  SQL Server 提供了一组系统监视器对象和计数器，可以为监视和分析 SQL Server 的运行状况提供信息。本章介绍了要监视的关键计数器。

影响性能的配置选项

最大异步 IO

SQL Server 7.0 中的手动配置选项最大异步 I/O 在 SQL Server 2000 中已经实现了自动化。以前，最大异步 I/O 用于指定在一次检查点操作过程中，SQL Server 7.0 可以向 Microsoft Windows NT® 4.0 和 Windows® 2000 同时提交的磁盘 I/O 请求的数量。Windows 接下来又将这些请求提交到物理磁盘子系统。此配置设置实现自动化后，SQL Server 2000 就能够以动态方式自动维护最佳的 I/O 吞吐量。

注意 Windows 98 不支持异步 I/O，因此在该平台上不支持最大异步 I/O 选项。

数据库恢复模型

SQL Server 2000 引入了在数据库级别对事务记录方式进行配置的功能。选定的模型会对性能产生很大的影响，尤其是在数据装载过程中。恢复模型有三种：“完全”、“大容量日志记录的”和“简单”。新数据库的恢复模型是在新数据库创建时从模型数据库继承的。在创建数据库之后，可以更改它的模型。

• “完全恢复”可为将数据库恢复到以前的时间点提供最大的灵活性。
• “大容量日志记录的恢复”可为某些大规模操作（例如，创建索引或大容量复制）提供较高的性能并占用较少的日志空间。这种恢复的缺点是与时间点恢复相比不够灵活。
• “简单恢复”提供的性能最高，占用的日志空间最少，但在系统发生故障时丢失数据的风险很大。在使用“简单恢复”模型时，数据只能恢复到上次（最近一次）进行完全数据库或差异备份时的状态。在这一模型中，由于事务在日志中会从检查点处截断，因此不能使用事务日志备份来恢复事务。这会产生丢失数据的可能。在不再需要日志空间以从服务器故障（活动事务）进行恢复之后，日志空间就会被截断并重新使用。

经验丰富的管理员可以使用这个恢复模型功能来大大加快数据装载和大容量操作的速度。不过，根据所选模型不同，丢失数据的可能性也各不相同。

重要说明 在选择某种恢复模型之前，必须仔细考虑会遇到的风险。

每种恢复模型致力于满足不同的需要。请根据所选的模型权衡利弊。权衡的结果需对性能、空间利用率（磁盘或磁带）和防范数据丢失的保护措施等方面加以综合考虑。当您选择恢复模型时，需要结合以下几个方面的业务需求作出决定：

• 大规模操作（例如，创建索引或大容量装载）的性能
• 数据丢失的可能性（例如，丢失已提交的事务）
• 事务日志空间占用大小
• 备份和恢复过程的难易

根据所执行的操作不同，一种模型可能会比另一种模型更适合。在选择一种恢复模型之前，请考虑它将带来的影响。下表提供了一些帮助性信息。

有关多实例的注意事项

SQL Server 2000 中还引入了在一台计算机上运行 SQL Server 的多个实例的功能。默认情况下，SQL Server 的每个实例会动态地获取和释放内存，以针对实例的工作负荷的变化进行调整。当 SQL Server 2000 有多个实例，而每个实例都独立地自动调整内存使用量时，性能优化会变得很复杂。大多数高端的业务智能客户通常只在每台计算机上安装一个 SQL Server 实例，因此对于他们来说，通常不需要考虑这项功能。但是，随着计算机个体变得越来越大（Windows 2000 Datacenter Server 最多支持 64 GB RAM 和 32 个 CPU），在有些生产环境中，可能会出现对多个实例的需求。那些利用扩展内存支持的实例需要特别关注。

扩展内存支持

一般情况下，SQL Server 2000 会根据需要动态地获取和释放内存，所以管理员通常不需要指定应该为 SQL Server 分配多少内存。但是，SQL Server 2000 企业版和 SQL Server 2000 开发人员版引入了对使用 Microsoft Windows 2000 Address Windowing Extensions (AWE) 的支持。这样，SQL Server 2000 就可以对更多的内存进行寻址（对于 Windows 2000 Advanced Server 最多约 8 GB；对于 Windows 2000 Datacenter Server 最多约 64 GB）。在配置了扩展内存的情况下，必须将访问扩展内存的每个实例配置为静态分配它将使用的内存。

注意 只有当您运行 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 时，才可使用这项功能。

使用 Windows 2000 的注意事项

要利用 AWE 内存，必须使用已分配了 Windows 2000 的“内存中锁定页”特权的 Windows 2000 帐户运行 SQL Server 2000 数据库引擎。SQL Server 安装程序将自动授权 MSSQLServer 服务帐户使用内存中锁定页选项。如果您从命令提示符使用 Sqlservr.exe 来启动 SQL Server 2000 的实例，必须使用 Windows 2000 的“组策略”实用工具 (Gpedit.msc) 将这一权限手动分配给交互操作的用户帐户，否则的话，如果 SQL Server 不作为服务运行就将无法使用 AWE 内存。

启用“内存中锁定页”选项

1. 在开始菜单上，单击运行，然后在打开框中输入 gpedit.msc。
2. 在组策略树窗格中，展开计算机配置，然后展开 Windows 设置。
3. 展开安全性设置，然后展开本地策略。
4. 选择用户权限分配文件夹。
5. 策略将会显示在详细信息窗格中。
6. 在详细信息窗格中，双击内存中锁定页。
7. 在本地安全性策略设置对话框中，单击添加。
8. 在选择用户或组对话框中，添加一个有权运行 Sqlservr.exe 的帐户。

要使 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 能够支持 4 GB 以上的物理内存，必须将 /pae 参数添加到 Boot.ini 文件中。

对于内存不超过 16 GB 的计算机，您可以在 Boot.ini 文件中使用 /3gb 参数。这就使 Windows 2000 Advanced Server 和 Windows 2000 Datacenter Server 能够允许用户应用程序通过 3 GB 的虚拟内存来对扩展内存进行寻址，并且为操作系统本身保留 1 GB 虚拟内存。

如果计算机上的物理内存超过 16 GB，则 Windows 2000 操作系统本身会需要 2 GB 虚拟内存地址空间用于系统开销。因此，它只能支持将 2 GB 虚拟地址空间用于应用程序开销。对于物理内存超过 16 GB 的系统，一定要在 Boot.ini 文件中使用 /2gb 参数。

注意 如果您意外使用了 /3gb 参数，Windows 2000 将无法对 16 GB 以上的任何内存进行寻址。

使用 SQL Server 2000 的注意事项

要使 SQL Server 2000 的实例能够使用 AWE 内存，请使用 sp_configure 来设置启用 awe 选项。然后，重新启动 SQL Server 以激活 AWE。由于 AWE 支持会在 SQL Server 启动过程中启用，并在 SQL Server 关闭前一直保持启用状态，所以，在 AWE 处于使用状态时，SQL Server 会通过向 SQL Server 错误日志发送“已启用 Address Windowing Extension”消息来通知用户。

当您启用 AWE 内存时，SQL Server 2000 的实例不会动态管理地址空间的大小。因此，当您启用 AWE 内存并启动 SQL Server 2000 的实例时，根据最大服务器内存的设置方式不同，会出现下列情况之一。

• 如果已经设置了最大服务器内存并且计算机上至少有 3 GB 可用内存，则该实例获取在最大服务器内存中指定的内存量。如果计算机上可用的内存量小于最大服务器内存（但是大于 3 GB），则该实例获取几乎所有的可用内存，并且可能最多只留下 128 MB 可用内存。
• 如果尚未设置最大服务器内存并且计算机上至少有 3 GB 可用内存，则该实例几乎获取所有的可用内存，并且可能最多只留下 128 MB 可用内存。
• 如果计算机上的可用内存不足 3 GB 而且内存是动态分配的，则无论为启用 awe 设置了什么参数，SQL Server 都将以非 AWE 模式运行。

当在 32 GB 系统上分配 SQL Server AWE 内存时，Windows 2000 可能至少需要 1 GB 可用内存来管理 AWE。因此，如果在启动 SQL Server 的实例时已启用了 AWE，建议您不要使用默认的最大服务器内存设置，而应将它限制在 31 GB 或更小。

有关故障转移群集和多实例的注意事项

如果您在使用 AWE 内存的同时使用 SQL Server 2000 故障转移群集或者运行多个实例，则必须确保正在运行的所有 SQL Server 实例的最大服务器内存设置的值的总和小于可用的物理 RAM 量。对于故障转移，您必须考虑任何候选存活节点上物理 RAM 的最小量。如果故障转移节点上的物理内存比初始节点上的少，则 SQL Server 2000 的实例可能无法启动或者启动时用的内存比其在初始节点上的少。

sp_configure 选项

“并行度的成本阈值”选项

使用并行度的成本阈值选项可指定 SQL Server 创建和执行并行计划所用的阈值。只有当为同一个查询执行串行计划的预计成本高于在并行度的成本阈值中设置的值时，SQL Server 才为查询创建和执行并行计划。成本是指对特定的硬件配置执行串行计划时预计需要的时间（以秒为单位）。只针对对称多处理器 (SMP) 设置并行度的成本阈值。

通常，并行计划对较长的查询有利；性能上的优势可以补偿初始化、同步以及终止计划所需的额外时间。在混合执行短查询和长查询时，通常会使用并行度的成本阈值选项。短查询执行串行计划，而长查询使用并行计划。并行度的成本阈值的值决定哪些查询被视为短查询，从而只执行串行计划。

在有些情况下，即使查询的成本计划小于当前的并行度的成本阈值值，也可以选择并行计划。这是因为就并行度的成本阈值而言，使用并行计划还是串行计划要根据完全优化完成之前提供的预计成本来决定。

并行度的成本阈值选项可以设置为从 0 到 32767 的任何值。默认值是 5（以毫秒为单位）。如果计算机只有一个处理器，或者如果由于关系掩码配置选项的值而使得 SQL Server 只能使用一个 CPU，或者如果最大并行度选项设置为 1，那么，SQL Server 会忽略并行度的成本阈值。

“最大并行度”选项

最大并行度选项用于限制在执行并行计划时使用的处理器数（最多 32 个）。默认值是 0，此时使用可用的实际数量的 CPU。将最大并行度选项设置为 1 可强制取消生成并行计划。如果将该值设置为大于 1 的数字，则可以限制在执行单个查询时使用的最大处理器数。如果将该值指定为大于可用 CPU 数量的数字，则使用可用的实际数量的 CPU。

注意 如果未将关系掩码选项设成默认值，则在对称多处理器 (SMP) 系统上可供 SQL Server 使用的 CPU 数可能会受到限制。

对于在 SMP 计算机上运行的服务器，很少改变最大并行度。如果计算机只有一个处理器，则会忽略最大并行度值。

“优先级提升”选项

优先级提升选项用于指定 SQL Server 是否应当以高于同一台计算机上其他进程的调度优先级运行。如果将该选项设置为 1，SQL Server 将在 Windows 调度程序中按照 13 的优先级基数运行。默认值是 0，表示优先级基数 7。优先级提升选项只应当用在 SQL Server 专用且具有 SMP 配置的计算机上。

注意 如果将优先级提升得太高，则可能会使基本操作系统和网络功能的资源不足，从而造成关闭 SQL Server 或使用服务器上的其他 Windows 任务等问题。

在某些情况下，如果将优先级提升设置为默认值以外的任何值，可能会导致在 SQL Server 错误日志中记录以下通讯错误：

Error: 17824, Severity: 10, State: 0 Unable to write to ListenOn
connection '<servername>', loginname '<login ID>', hostname '<hostname>'
OS Error: 64, The specified.network name is no longer available.


错误 17824 指出在尝试写入客户端时 SQL Server 遇到连接问题。如果客户端已停止响应，或者客户端已经重新启动，则这些通讯问题可能是由网络问题引起的。但是，错误 17824 不一定表示网络问题，而可能只是设置优先级提升选项的结果。

“设置工作集大小”选项

设置工作集大小选项用于为 SQL Server 保留等于服务器内存设置的物理内存空间。服务器内存设置由 SQL Server 根据工作负荷和可用资源自动配置。它将在最小服务器内存和最大服务器内存之间显著变化。设置设置工作集大小的意思是：即使在 SQL Server 空闲时，另一个进程可以更容易地使用 SQL Server 页，操作系统也不尝试换出这些页。

如果您要允许 SQL Server 动态使用内存，请不要设置设置工作集大小。在将设置工作集大小设置为 1 之前，请将最小服务器内存和最大服务器内存设置为同一个值（希望 SQL Server 使用的内存量）。

轻量池和关系掩码选项将在本章后面的“要监视的关键性能计数器”一节讨论。

优化磁盘 I/O 性能

如果您配置的 SQL Server 将只包含几 GB 数据，而且不负担繁重的读写活动，可以不必考虑磁盘 I/O 以及通过平衡硬盘驱动器间的 SQL Server I/O 活动来实现最大性能等事项。但是，要创建大型 SQL Server 数据库来包含数百 GB 甚至 TB 的数据，并且/或者要能够负担繁重的读/写活动，则有必要进行相应的配置，以平衡多个硬盘驱动器间的负载，从而最大程度地提高 SQL Server 的磁盘 I/O 性能。

优化传输速度

对于数据库性能优化来说，最重要的方面之一就是优化 I/O 性能。当然，SQL Server 也不例外。除非运行 SQL Server 的计算机有足够的 RAM 来容纳整个数据库，否则 I/O 性能将由磁盘 I/O 子系统处理 SQL Server 读写数据的速度来确定。

因为传输速度、I/O 吞吐量和可能影响 I/O 性能的其他因素不断改善，所以我们将不针对应当从存储系统中期望看到哪种速度给出具体数字。为了更好地理解可期望获得的性能，建议您与首选的硬件供应商协作确定期望的最优性能。

我们必须要强调的是顺序 I/O 操作（通常又称为“序列”或“按磁盘顺序”）与非顺序 I/O 操作之间的差异。我们还希望大家注意预读可能对 I/O 操作产生的显著影响。

顺序和非顺序磁盘 I/O 操作

有必要解释以下这些术语相对于磁盘驱动器的含义。通常，一个硬盘驱动器由一组驱动器盘片组成。每个盘片都提供用于读取/写入操作的表面。一组带有读取/写入磁头的臂用于在这些盘片之间移动，并且从盘片的表面读取数据或者向其中写入数据。就 SQL Server 而言，有关硬盘驱动器的以下两点很重要，需要记住。

第一，读取/写入磁头和相关的磁盘臂需要移动，以定位到 SQL Server 请求的硬盘驱动器盘片上的位置并针对其进行操作。如果数据不按位置顺序分布到硬盘驱动器盘片上，则硬盘驱动器需要花更多的时间来移动磁盘臂（寻道时间）和旋转读/写头（旋转滞后时间）来找到数据。这与按位置顺序分布时的情形完全不同，在该情况下，所需的全部数据都位于硬盘驱动器盘片的一个连续物理扇区上，因此磁盘臂和读取/写入磁头在执行所需的磁盘 I/O 时移动量很少。

非顺序和顺序情形的时间相差很大：每次非顺序寻道大约花费 50 毫秒，而顺序寻道则大约需要两三毫秒。请注意，这些时间是大致估计值，并且将根据以下因素而有所变化：非顺序数据在磁盘上的分布距离、硬盘盘片可以旋转的速度 (RPM) 以及硬盘驱动器的其他物理属性。主要的一点是顺序 I/O 有助于提高性能，而非顺序 I/O 会降低性能。

第二，一定要记住，读写 8 KB 与读写 64 KB 所需的时间几乎一样多。在 8 KB 到大约 64 KB 的范围内，磁盘臂以及读/写头的移动（寻道时间和旋转滞后时间）仍然占一次磁盘 I/O 传输操作所需时间的大部分。因此，从数学角度讲，在需要传输 64 KB 以上的 SQL Server 数据时，因为 64 KB 与 8 KB 的传输速度基本上一样，但每次传输所处理的 SQL Server 数据却是后者的 8 倍，所以最好尝试尽可能多地执行 64 KB 磁盘传输操作。请记住，预读管理器在 64 KB 区块（称作 SQL Server 扩展盘区）中执行它的磁盘操作。日志管理器也以较大的 I/O 大小执行顺序写入。要记住的主要一点是，如果充分利用预读管理器并将 SQL Server 日志文件与不按顺序访问的其他文件分开，会改善 SQL Server 性能。

根据经验，大多数硬盘驱动器处理顺序 I/O 操作时所提供的性能是处理非顺序 I/O 操作时的 2 倍。即，需要非顺序 I/O 的操作所花费的时间是执行顺序 I/O 操作的两倍。因此，要尽可能避免可能导致数据库中出现随机 I/O 的情况。虽然应当尽量按顺序执行 I/O 操作，但是像页拆分或者数据无序这样的情形还是可能会导致出现非顺序 I/O。

为了促使执行顺序 I/O，一定要避免出现导致页拆分的情形。设计一个精心安排的数据装载策略也会有所帮助。您可以通过利用可分隔数据和索引的分区策略来促使在磁盘上按顺序分布数据。一定要设置作业以定期检查数据和索引中是否有碎片，并且在数据碎片太多时，使用 SQL Server 随付的实用工具来对数据重新排序。有关执行这些操作的更多信息将在本章的稍后部分介绍。

注意 因为事务日志数据总是以不超过 32 KB 的大小按顺序写入日志文件中，所以日志通常不是主要的考虑事项。

RAID

RAID（廉价磁盘冗余阵列）是一种存储技术，通常用于大于几 GB 的数据库。RAID 既具有性能优点又具有容错优点。多个 RAID 控制器和磁盘配置会在成本、性能和容错之间提供平衡。本主题简单介绍了将 RAID 技术用于 SQL Server 数据库的情况，并讨论了各种配置以及平衡方案。

• 性能。硬件 RAID 控制器将从 Windows NT 4.0 与 Windows 2000 和应用程序（例如 SQL Server）中读取/写入的所有数据划分为很多切片（通常是 16–128 KB），这些切片随后会分布到所有参与 RAID 阵列的磁盘上。按这种方式将数据拆散到各个物理驱动器上会有这样的效果：读取/写入 I/O 工作负荷会平均分布到所有参与 RAID 阵列的物理硬盘驱动器上。这样就会提高磁盘 I/O 性能，因为参与 RAID 阵列的硬盘在总体上保持相同程度的闲忙，而不会因 I/O 请求分布不均而导致某些磁盘成为瓶颈。
• 容错。 RAID 还通过使用镜像和奇偶校验这两种方法来防止硬盘出现故障并因此造成数据丢失。

镜像通过将信息写入另一组（镜像）驱动器上来实现。如果在有镜像时丢失了驱动器，则可以通过更换有故障的驱动器并重建镜像集来重建丢失驱动器上的数据。大多数 RAID 控制器都会提供在 Windows NT 4.0 和 Windows 2000 以及 SQL Server 联机的情况下更换故障驱动器并重新镜像的功能。这样的 RAID 系统通常被称作能够“热插拔”的驱动器。

镜像有一个优点：如果需要容错，它所实现的性能是 RAID 选项中最佳的。请切记，SQL Server 每次写入镜像集时，都会执行两个磁盘 I/O 操作，对于镜像集的每一面各执行一个这样的操作。另一个优点是：进行镜像比实现奇偶校验 RAID 提供的容错更多。镜像能够使系统在至少一个驱动器发生故障后继续运行，而且，在镜像集中多达半数的驱动器都有故障的情况下，也许还能够支持系统，而不是强制系统管理员关闭服务器并从文件备份中恢复。

镜像的缺点是成本高。镜像的磁盘成本是：每个需要用来存放数据的驱动器都额外需要一个驱动器。这实际上就会使存储成本增加一倍，对于数据仓库来说，存储器通常是所需的最昂贵的组件之一。RAID 1 及其混合 RAID 0+1（有时称作 RAID 10 或 0/1）都是通过镜像实现的。

奇偶校验是这样实现的：计算有关写入磁盘的数据的恢复信息，然后将该奇偶校验信息写入构成 RAID 阵列的其他驱动器。如果某个驱动器发生故障，一个新驱动器就会插入 RAID 阵列，并通过提取写入其他驱动器上的恢复信息（奇偶校验），使用这些信息重新生成故障驱动器上的数据，从而恢复故障驱动器上的数据。RAID 5 及其混合通过奇偶校验实现。

奇偶校验的优点是成本低。要用 RAID 5 保护任意数量的驱动器，只需要另外增加一个驱动器。奇偶校验信息会均匀分布在参与 RAID 5 阵列的所有驱动器上。奇偶校验的缺点是性能和容错能力。由于在计算和写入奇偶校验时会额外带来成本，因此 RAID 5 对于每次写入都需要四个磁盘 I/O 操作，而镜像只需两个磁盘 I/O 操作。镜像和奇偶校验的读取 I/O 操作成本是相同的。但是，读取操作通常会发生在有故障的驱动器上，此后，必须将阵列脱机，而且必须从备份介质中执行恢复，以恢复数据。

一般经验：一定要在所需的任意多个磁盘上进行条带化，以实现可靠的磁盘 I/O 性能。系统监视器将会指出在特定的 RAID 阵列上是否存在磁盘 I/O 瓶颈。请准备根据需要添加磁盘，并将数据重新分布到 RAID 阵列和/或小型计算机系统接口 (SCSI) 通道中，以平衡磁盘 I/O 并最大限度地提高性能。

硬件 RAID 控制器板载缓存的效果

许多硬件 RAID 控制器都有某种形式的读取和/或写入缓存。对 SQL Server 来说，这种可用的缓存功能可以显著增强磁盘子系统高效处理 I/O 的能力。这些基于控制器的缓存机制的原理是：收集来自主机服务器 (SQL Server) 的较小的并且有可能是非顺序的 I/O 请求，然后尝试在几毫秒内将它们与其他 I/O 请求合成一批，这样，成批的 I/O 就可以形成较大 (32–128 KB) 并且有可能是顺序 I/O 请求，以便发送到硬盘驱动器。

按顺序的和较大的 I/O 请求有利于提高性能，请遵循这一原则，因为在硬盘驱动器能够向 RAID 控制器提供固定数量 I/O 的情况下，这样有助于产生更大的磁盘 I/O 吞吐量。硬盘每秒能够处理更多的 I/O，并不是 RAID 控制器的缓存功能有多么神奇，而是因为 RAID 控制器缓存使用了某种组织方式来排列传入的 I/O 请求，从而能够尽可能充分地利用好基础硬盘固定的 I/O 处理能力。

这些 RAID 控制器通常用某种形式的后备电源来保护它们的缓存机制。这种后备电源可以帮助在断电时，将写入缓存中的数据保留一段时间（可能是几天）。如果数据库服务器也由不间断电源 (UPS) 支持，在断电时，RAID 控制器会有更多的时间和机会将数据刷新到磁盘中。虽然服务器的 UPS 不直接影响性能，但它的确可以为 RAID 控制器缓存所提供的性能改进提供保护。

RAID 级别

如上所述，在 RAID 的各个级别中，RAID 1 和 RAID 0+1 提供最佳的数据保护和最佳性能，但是就所需的磁盘而言会需要更多的成本。当硬盘成本不是限制因素时，就兼顾性能和容错而言，RAID 1 或 RAID 0+1 是最佳选择。

RAID 5 的成本比 RAID 1 或 RAID 0+1 低，但是它提供的容错和写入性能较差。RAID 5 的写入性能大约只是 RAID 1 或 RAID 0+1 的一半，这是因为 RAID 5 读取和写入奇偶校验信息需要额外的 I/O。

使用 RAID 0 可实现最佳磁盘 I/O 性能（磁盘条带化没有容错保护）。因为 RAID 0 不提供容错保护，所以决不应当将它用在生产环境中，也不建议将它用在开发环境中。RAID 0 通常只用于基准检验或测试。

许多 RAID 阵列控制器都通过物理硬盘驱动器提供 RAID 0+1（又称作 RAID 1/0 和 RAID 10）选项。RAID 0+1 是一种混合 RAID 解决方案。在较低级别，该控制器像普通的 RAID 1 那样镜像所有的数据。在较高级别，它（像 RAID 0 一样）将数据条带化到所有的驱动器上。因此，RAID 0+1 提供最大的保护（镜像）和高性能（条带化）。因为这些条带化和镜像操作由 RAID 控制器进行管理，所以它们对于 Windows 和 SQL Server 是透明的。RAID 1 和 RAID 0+1 之间的区别在硬件控制器级别上。对于给定的存储量，RAID 1 和 RAID 0+1 需要相同数量的驱动器。有关以 RAID 0+1 方式实现特定 RAID 控制器的更多信息，请与生产该控制器的硬件供应商联系。

下面的插图显示了 RAID 0、RAID 1、RAID 5 和 RAID 0+1 之间的区别。

如果您的浏览器不支持嵌入式框架，请单击此处在单独的页中查看。

注意 在上面的插图中，为了容纳相当于四个磁盘的数据，RAID 1（和 RAID 0+1）需要八个磁盘，而 Raid 5 只需要五个磁盘。一定要咨询您的存储器供应商，以了解有关他们特定的 RAID 实现的更多信息。

0 级

因为该级别使用名为条带集的磁盘文件系统，所以又将它称作磁盘条带。数据被划分成多个块并按固定顺序分布到阵列中的所有磁盘上。RAID 0 将多个操作分布到多个磁盘上，以便可以同时独立地执行这些操作，从而改善了读取/写入性能。RAID 0 类似于 RAID 5，但是 RAID 5 还提供容错功能。

下面的插图显示的是 RAID 0。

1 级

因为该级别使用名为镜像集的磁盘文件系统，所以又将它称作磁盘镜像。磁盘镜像可提供一个与所选磁盘完全相同的冗余副本。写入主磁盘的所有数据都会写入镜像磁盘。RAID 1 提供了容错功能，而且通常可以改进读取性能（但是可能会降低写入性能）。下面的插图显示的是 RAID 1。

2 级

该级别通过使用将奇偶校验分布到所有磁盘上的纠错方法来添加冗余。它还利用磁盘条带策略将一个文件分成多个字节并将该文件分布到多个磁盘上。与镜像 (RAID 1) 相比，该策略在磁盘利用率和读取/写入性能方面只带来了很小的改进。RAID 2 不如其他 RAID 级别效率高，通常不使用它。

3 级

该级别使用与 RAID 2 相同的条带化方法，但是纠错方法只需一个磁盘用于奇偶校验数据。磁盘空间的使用情况因数据磁盘的数量而异。RAID 3 在读取/写入性能方面提供一些改进。RAID 3 也极少使用。

4 级

该级别使用的条带数据块或段比 RAID 2 或 RAID 3 大得多。与 RAID 3 一样，纠错方法只需一个磁盘用于奇偶校验数据。它将用户数据与纠错数据分开。RAID 4 不如其他 RAID 级别效率高，通常不使用。

5 级

该级别又称作具有奇偶校验的条带化，它是新设计中最常用的策略。与 RAID 4 相似，它将数据以大块形式条带化到阵列中的磁盘上。不同之处在于它在所有磁盘之间写入奇偶校验的方式。数据冗余通过奇偶校验信息提供。数据和奇偶校验信息会在磁盘阵列上排列，所以这两种信息总是位于不同的磁盘上。与磁盘镜像 (RAID 1) 相比，具有奇偶校验的条带化可提供更好的性能。但是，当条带成员丢失时（例如，当磁盘发生故障时），读取性能会下降。RAID 5 是最常用的 RAID 配置之一。下面的插图显示的是 RAID 5。

Level 10 (1+0)

该级别又称作具有条带化的镜像。该级别使用条带化的磁盘阵列，而该阵列又镜像到另一组相同的条带化磁盘。例如，可使用四个磁盘创建一个条带化的阵列。然后，条带化的磁盘阵列使用另一组（四个）条带化的磁盘进行镜像。RAID 10 提供磁盘条带化带来的性能益处以及镜像带来的磁盘冗余。在所有的 RAID 级别中，RAID 10 提供的读取/写入性能最高，代价是使用的磁盘数量是其他级别的两倍。下面的插图显示的是 RAID 10。

如果您的浏览器不支持嵌入式框架，请单击此处在单独的页中查看。

联机 RAID 扩展

使用该功能可以在 SQL Server 保持联机的情况下动态地给物理 RAID 阵列添加磁盘。增加的磁盘驱动器会自动集成到 RAID 存储器中。添加磁盘驱动器的方法是：将它们安装到被称为热插拔驱动器插槽或热插拔插槽的物理位置。许多硬件供应商都提供了能够实现该功能的硬件 RAID 控制器。数据会均匀地在所有驱动器（包括新添加的驱动器）之间均匀地重新进行条带化，而且不需要关闭 SQL Server 或 Windows。

您可以通过在磁盘阵列盒中的热插拔插槽中保留空位来利用该功能。如果 SQL Server 经常因 I/O 请求而使 RAID 阵列负担过重（这可以由与该 RAID 阵列相关联的 Windows 逻辑驱动器盘符的磁盘队列长度来指示），则可能需要在 SQL Server 仍在运行时，将一个或多个新的硬盘驱动器安装到热插拔插槽中。RAID 控制器会将一些现有的 SQL Server 数据移到这些新驱动器上，以便数据均匀地分布到 RAID 阵列中的所有驱动器上。然后，新驱动器的 I/O 处理能力（每个驱动器每秒 75 个非顺序/150 个顺序 I/O）会添加到 RAID 阵列的总体 I/O 处理能力中。

系统监视器和 RAID

在系统监视器（在 Microsoft Windows NT® 4.0 中为性能监视器）中，可以获取逻辑磁盘驱动器和物理磁盘驱动器的信息。逻辑磁盘和物理磁盘的区别在于，在系统监视器中，逻辑磁盘与 Windows 读作逻辑驱动器盘符的内容相关联，物理磁盘与 Windows 读作一个物理硬盘的内容相关联。

在 Windows NT 4.0 中，默认情况下，性能监视器的所有磁盘计数器都是处于关闭状态的，因为它们可能会对性能略有影响。在 Windows 2000 中，默认情况下，物理磁盘计数器处于打开状态，逻辑磁盘计数器处于关闭状态。Diskperf.exe 是一个 Windows 命令，它控制可在系统监视器中查看的计数器的类型。

在 Windows 2000 中，要获取逻辑驱动器或存储卷的性能计数器数据，您必须在命令提示符下键入 diskperf -yv，然后按 Enter 键。这会导致用于收集磁盘性能数据的磁盘性能统计驱动程序报告逻辑驱动器或存储卷的数据。在默认情况下，操作系统使用 diskperf -yd 命令来获取物理驱动器的数据。

在 Windows 2000 中，Diskperf.exe 的语法如下所示：

diskperf [-y[d|v] | -n[d|v]] [\\computername]

参数

(none)

报告磁盘性能计数器是否处于启用状态并标识启用的计数器。

-y

将系统设置为在计算机重新启动时启动所有的磁盘性能计数器。

-yd

在计算机重新启动时启用物理驱动器的磁盘性能计数器。

-yv

在计算机重新启动时启用逻辑驱动器或存储卷的磁盘性能计数器。

-n

将系统设置为在计算机重新启动时禁用所有的磁盘性能计数器。

-nd

禁用物理驱动器的磁盘性能计数器。

-nv

禁用逻辑驱动器的磁盘性能计数器。

\\computername

指定要查看或设置要使用的磁盘性能计数器的计算机。

在 Windows NT 4.0 和更低版本中，diskperf –y 用于监视不使用 Windows NT 软件 RAID 的硬盘驱动器或者硬盘驱动器与 RAID 控制器的集和。在使用 Windows 软件 RAID 时，请使用 diskperf –ye，以便系统监视器将在 Windows NT 条带集之间正确地报告物理计数器。当结合使用 diskperf –ye 和 Windows NT 条带集时，逻辑计数器所报告的信息将不正确并且应当被忽略。如果必须将逻辑磁盘计数器信息与 Windows NT 条带集结合使用，请使用 diskperf –y。

在使用 diskperf –y 时，逻辑磁盘计数器会被正确地报告给 Windows NT 条带集，但是物理磁盘计数器所报告的信息将不正确并且应当被忽略。

注意 diskperf 命令要在重新启动了 Windows 之后才会起作用（Windows 2000 和 Windows NT 4.0 及更低版本均是如此）。

有关监视硬件 RAID 的注意事项

因为 RAID 控制器将多个物理硬盘驱动器作为一个 RAID 镜像集或条带集提供给 Windows，所以 Windows 就会像读取一个物理磁盘那样读取该分组。实际底层硬盘驱动器活动的最终抽象视图会导致性能计数器报告可能会起误导作用的信息。

从优化性能的角度看，知道一个 RAID 阵列关联了多少物理硬盘驱动器是很重要的。在确定 Windows 和 SQL Server 发送给每个物理硬盘驱动器的磁盘 I/O 请求数时，将需要此信息。将系统监视器报告为与某个硬盘驱动器相关联的磁盘 I/O 请求数除以该 RAID 阵列中已知的实际物理硬盘驱动器数。

要粗略估计 RAID 阵列中每个硬盘驱动器的 I/O 活动，一定还要将系统监视器报告的磁盘写入 I/O 数乘以 2（RAID 1 和 0+1）或 4 (RAID 5)。这将更精确地给出发送到物理硬盘驱动器的实际 I/O 请求数，因为正是在这个物理级别应用硬盘驱动器的 I/O 能力。但是，当硬盘 RAID 控制器使用缓存功能时，此方法无法精确计算硬盘驱动器 I/O，因为缓存功能会极大地影响对硬盘驱动器进行的直接 I/O。

在监视磁盘活动时，最好将重点关注磁盘队列，而不是每个磁盘的实际 I/O。磁盘 I/O 的速度取决于驱动器的传输速率，而这种速率是无法调整的。除了购买更快或更多的驱动器外，您没有什么其他措施，所以，关心实际发生的 I/O 量没有什么意义。但是，您又希望避免出现过多的磁盘队列。大量的磁盘队列表明您的 I/O 有问题。因为 Windows 不能读取 RAID 阵列中物理驱动器的数量，所以很难精确估计每个物理磁盘的磁盘队列。通过将磁盘队列长度除以参与所观察的逻辑驱动器的硬件 RAID 磁盘阵列的物理驱动器数，可以确定大致的近似值。对于 SQL Server 文件所在的硬盘驱动器，努力使磁盘队列数少于两个，是最理想的。

软件 RAID

Windows 2000 支持软件 RAID，在不使用硬件 RAID 控制器时，软件 RAID 通过操作系统来提供镜像集和条带集（具有或不具有容错功能），从而提供容错功能。您可以使用操作系统过程来设置 RAID 0、RAID 1 或 RAID 5 功能。多数大型数据仓库都使用硬件 RAID，但是，如果您的安装规模相对较小，或者您选择不实现硬件 RAID，那么，软件 RAID 可以带来一些数据访问和容错方面的优点。

软件 RAID 确实会占用一些 CPU 资源，因为 Windows 必须管理通常由硬件 RAID 控制器为您管理的 RAID 操作。因此，在磁盘驱动器数相同的情况下，Windows 软件 RAID 提供的性能会比硬件 RAID 低几个百分点，尤其是当系统处理器的使用率因其他目的而接近 100% 时。通过降低 I/O 瓶颈的可能性，与没有软件 RAID 时相比，Windows 软件 RAID 通常将帮助一组驱动器为 SQL Server I/O 提供更好的服务。如果使用软件 RAID，SQL Server 应该能够更好地利用 CPU，因为服务器通常等待 I/O 请求完成的时间会减少。