性能优化的基本原则 | |
优化磁盘 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 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 时,才可使用这项功能。
要利用 AWE 内存,必须使用已分配了 Windows 2000 的“内存中锁定页”特权的 Windows 2000 帐户运行 SQL Server 2000 数据库引擎。SQL Server 安装程序将自动授权 MSSQLServer 服务帐户使用内存中锁定页选项。如果您从命令提示符使用 Sqlservr.exe 来启动 SQL Server 2000 的实例,必须使用 Windows 2000 的“组策略”实用工具 (Gpedit.msc) 将这一权限手动分配给交互操作的用户帐户,否则的话,如果 SQL Server 不作为服务运行就将无法使用 AWE 内存。
启用“内存中锁定页”选项
要使 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 的实例能够使用 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 的实例时,根据最大服务器内存的设置方式不同,会出现下列情况之一。
当在 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 的实例可能无法启动或者启动时用的内存比其在初始节点上的少。
“并行度的成本阈值”选项
使用并行度的成本阈值选项可指定 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(廉价磁盘冗余阵列)是一种存储技术,通常用于大于几 GB 的数据库。RAID 既具有性能优点又具有容错优点。多个 RAID 控制器和磁盘配置会在成本、性能和容错之间提供平衡。本主题简单介绍了将 RAID 技术用于 SQL Server 数据库的情况,并讨论了各种配置以及平衡方案。
镜像通过将信息写入另一组(镜像)驱动器上来实现。如果在有镜像时丢失了驱动器,则可以通过更换有故障的驱动器并重建镜像集来重建丢失驱动器上的数据。大多数 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 请求完成的时间会减少。