[转]磁盘 I/O 性能 对数据库的影响

winston

      如果将 SQL Server 配置成仅包含几个千兆字节 (GB) 的数据，且不承担繁重的读或写活动，便没有太大的必要关注磁盘 I/O 主题，以及在硬盘之间平衡 SQL Server I/O 活动以获取最佳性能。但是要建立包含成百上千 GB 字节的数据且/或承担繁重的读和/或写活动的大型 SQL Server 数据库，就有必要在多个硬盘之间平衡负荷，以配置最佳的 SQL Server 磁盘 I/O 性能。  标称的磁盘传输率与 SQL Server 的关系
      优化数据库性能最重要的一个方面是调整 I/O 性能。SQL Server 当然也不例外。除非 SQL Server 运行在一台具有足够大的内存可容纳整个数据库的机器上，否则 I/O 性能将由磁盘 I/O 子系统处理 SQL Server 数据读写的速度来决定。
      请记住下面的经验法则：标准的 Wide Ultra SCSI-3 硬盘每秒钟可为 Windows 和 SQL Server 提供 75 个不连续（随机）的 I/O 操作和 150 个连续的 I/O 操作。这种硬盘的标称传输率在 40 MB/秒左右。请记住更有可能限制数据库服务器的传输率是每秒钟 75/150 I/O，而不是 40 MB/秒。具体演算如下：
  （每秒 75 次随机 I/O 操作）X（8 KB 传输）= 每秒 600 KB
     上面的计算表示如果在给定的硬盘上进行严格的随机读或写 SQL Server 操作（单页读和写），有可能该硬盘最高只能达到每秒 600 KB（即每秒 0.6 MB）的处理能力。这比驱动器标定的每秒 40 MB 的 I/O 处理能力要低得多。SQL Server 工作线程、Graphical ShowPlan 和 LazyWrtier 执行 8 KB 传输量的 I/O。
  （每秒 150 个连续 I/O 操作）X（8 KB 传输）= 每秒 1,200 KB
     上面的计算表示如果在给定的硬盘上进行严格的连续读或写 SQL Server 操作（单页读或写），有可能在该硬盘上达到最高每秒 1,200 KB（即每秒 1.2 MB）的处理能力。
  （每秒 75 个随机 I/O 操作）X（64 KB 传输）= 每秒 4,800 KB (4.8 MB)
  上面的计算表示预读的最次方案（假定进行的都是随机 I/O）。请注意即便在完全进行随机 I/O 的情况下，64 KB 传输量仍然可以提供比单页传输率（0.6 和 1.2 MB/s）要好得多的 I/O 磁盘传输率 (4.8 MB/s)：
  （每秒 150 个连续 I/O 操作）X（64 KB 传输）= 每秒 9,600 KB (9.6 MB)
      上面的计算表示如果在给定的硬盘上进行严格的连续读或写 SQL Server 操作，有可能在该硬盘上达到最高每秒 9.6 MB 的 I/O 处理能力。这比随机 I/O 的情况要好得多。SQL Server Read-Ahead Manager 以 64 KB 传输率执行磁盘 I/O，并试图安排读操作，以便连续地（通常也称为“按磁盘顺序”）进行预读扫描。因为 Read-Ahead Manager 的目的是连续地执行 I/O 操作，而进行页拆分可能导致扩展盘区的读取不连续，这就是要消除和防止页拆分的原因。
  Log Manager 最大可连续地将 32 KB 字节写入日志文件。
  连续和不连续的磁盘 I/O 操作
       连续和不连续这两个词在硬盘操作中用得非常多。有必要花一些时间来解释一下这两个词对于硬盘的意义。一个硬盘由一组驱动器盘片组成。每个驱动器盘片都通过一组带读/写磁头的取数臂为读/写操作提供服务，这些读/写磁头可以在盘片之间移动，读取驱动器盘片中的信息或者将数据写入盘片。就 SQL Server 而言，应记住硬盘的两个重要特性：
      读/写磁头和相关的磁盘取数臂需要移动才能在 SQL Server 和 Windows 所要求的硬盘盘片的位置上进行查找和操作。如果数据所在的硬盘盘片的位置不连续，硬盘驱动器要花多得多的时间才能将磁盘取数臂和读/写磁头移动到所有需要的硬盘盘片位置。如果所需要的数据全部位于硬盘盘片上的连续物理扇区，情况则相反，磁盘取数臂和读/写磁头只需进行很小的移动就能完成所需磁盘 I/O 操作。连续和不连续的情况下所花的时间有很大的差异，每个不连续的数据查找大约要花 50 毫秒，而连续的数据查找则只需大约 2-3 毫秒。请注意这些值是粗略估计出来的，具体值将取决于不连续的数据在磁盘上分布的疏密、硬盘盘片的旋转速度 (RPM) 以及硬盘的其它物理属性。主要要记住的一点是连续 I/O 有益于 SQL Server 性能。
     本文已提到标准的硬盘支持每秒 75 个不连续的 I/O 和每秒 150 个连续的 I/O。要记住的重要一点是读或写 8KB 的时间与读或写 64 KB的时间几乎相同。在 8 KB 到 64 KB 范围之内，单个磁盘 I/O 传输操作所花的时间主要是磁盘取数臂和读/写磁头运动的时间。因此，从数学上来讲，当需要传输 64 KB 以上的 SQL 数据时，尽可能地执行 64 KB 磁盘传输是有益的，因为 64 KB 传输基本上与 8 KB 传输一样快，而每次传输的 SQL Server 数据是 8 KB 传输的 8 倍。请记住 Read-Ahead Manager 以 64 KB 字节片（也称为 SQL Server 扩展盘区）执行磁盘操作。Log Manager 也以较大的 I/O 传输量来执行连续写操作。要记住的主要事项是充分利用 Read-Ahead Manager，并将 SQL Server 日志文件与其它非连续存取的文件分开，以有效提高 SQL Server 的性能。
        想详细了解物理硬盘的读者可以参考 Compaq 公司的白皮书“Disk Subsystem Performance and Scalability（磁盘子系统性能和可伸缩性）”，其位置将在本文结尾部分的“查找其它资料”中提到。
  磁盘 I/O 传输率/RAID 控制器传输率/PCI 总线带宽
      标准的硬盘提供的最大传输率是每秒 40 MB 或每秒 75 个不连续磁盘传输/150 个连续磁盘传输。 标准 RAID 控制器标称的传输率大约为每秒 40 MB 或（非常接近）每秒 2,000 个磁盘传输。外围元件互连 (PCI) 总线的标定传输率大约为每秒 133 MB 或更高。设备实际的传输率将与标称的传输率不同，但这个问题对于我们此处的讨论并不重要。重要的是了解如何用这些传输率来粗略估算与每个 RAID 控制器相联的硬盘的数量，以及一个 PCI 总线连接多少个驱动器和 RAID 控制器不至于出现 I/O 瓶颈问题。
      在前面的“标称的磁盘传输率和 SQL Server 的关系”部分，已计算出每秒钟最多可以从硬盘读出或写入硬盘的 SQL Server 数据量为 9.6 MB。假定 RAID 控制器每秒钟可处理 40 MB，粗略地计算可与一个 RAID 控制器相联的硬盘数目应为 40 除以 9.6，答案约等于 4。这表示当 SQL Server 只进行 64 KB 的连续 I/O 时，可与一个控制器相联的驱动器最多为 4 个。类似地，前面已计算出对于 64 KB 的全部不连续 I/O，从硬盘到控制器的最大数据传输率为 4.8 MB/秒。40 MB/秒除以 4.8 MB/秒约等于 8。也就是说，在不连续的 64 KB 方案中，与单个控制器相联的硬盘最多为 8 个。随机 8 KB 数据传输方案需要的驱动器最多。40 除以 0.6 约等于 66，这表示需要 66 个驱动器才能使进行 100% 随机 8 KB 读和写的 RAID 控制器饱和。这不是实际可行的方案，因为预读和日志记录所使用的传输量大于 8 KB，并且 SQL Server 不可能执行 100% 的随机 I/O。
      另一种计算可与 RAID 控制器相联的驱动器的数目的方法是从每秒的磁盘传输出发，而不是从每秒的字节数出发。如果某个硬盘每秒可进行 75 个不连续的（随机）I/O，理论上 26 个联在一起的驱动器每秒钟可产生 2,000 个不连续的 I/O，足以达到单个 RAID 控制器的最大 I/O 处理能力。另一方面，只需 13 个硬盘联在一起就能产生每秒 2,000 个连续 I/O，从而使 RAID 控制器以最大吞吐量运行，这是因为单个硬盘每秒可以承受 150 个连续 I/O。
      现在来讨论 PCI 总线。请注意 RAID 控制器和 PCI 总线瓶颈没有与硬盘有关的 I/O 瓶颈常见。但是为便于说明，我们假定与某个 RAID 控制器相联的一组硬盘足够忙，以至于每秒有 40 MB 的吞吐量通过控制器。下一个问题是“PCI 总线上联多少个 RAID 控制器比较安全，不会引发 PCI 总线 I/O 瓶颈问题？”要进行粗略估算，可以用 PCI 总线的 I/O 处理容量除以 RAID 控制器的 I/O 处理容量：133 MB/秒除以 40 MB/秒约等于 3，这表示一个 PCI 总线上可以联大约 3 个 RAID 控制器。请注意多数大型服务器带有多个 PCI 总线，这使得单个服务器上可以安装更多的 RAID 控制器。
       这些计算有助于说明组成磁盘 I/O 子系统的各个组件（硬盘、RAID 控制器和 PCI 总线）的传输率的关系，但不应按字面理解。这是因为这些计算假定全部进行连续数据存取或不连续数据存取，而这在生产数据库服务器环境中几乎是不可能的。实际上，通常既有连续 I/O，也有不连续 I/O，既有 8 KB I/O，也有 64 KB I/O。还有其它因素使得很难准确估算一次通过一组硬盘的 I/O 操作数。RAID 控制器可用的插件读/写高速缓存增加了驱动器组可有效产生的 I/O 数。既然很难准确估算出 SQL Server 环境所需要的 8 KB 和 64 KB I/O 的数，所以同样也很难估算出所增加的 I/O 数。
  但是我们希望能够通过这部分让您了解所标定的传输率对于 SQL Server 的实际意义。
  RAID
      当缩放超过几十亿字节数据的数据库时，对 RAID（廉价冗余磁盘阵列）技术和它与数据库性能的关系有一个基本了解是很重要的。
  RAID 的优点是：
      性能：硬件 RAID 控制器将 Windows 和应用程序（如 SQL Server）的所有数据读/写进行切片（通常为 16-128 KB），这些切片分布在所有参与 RAID 阵列的磁盘中。按类似的方法在物理驱动器之间拆分数据具有在所有参与 RAID 阵列的物理硬盘之间平均分配读/写 I/O 工作负荷的效果。这样可提高磁盘 I/O 的性能，因为作为整体参与 RAID 阵列的硬盘保持同等繁忙程度，而不会使某些磁盘由于 I/O 请求分配的不平均而成为瓶颈。
  容错： RAID 用两种方法保护硬盘不出现故障，并防止由于故障而出现数据丢失：镜像和奇偶信息。
     “镜像”通过将信息写入两组驱动器来实现。镜像的驱动器两侧各有一组信息。如果在使用镜像时一个驱动器出现故障，可以置换出现故障的驱动器，然后从镜像集的另一侧与出现故障的驱动器对应的驱动器中重建数据，从而将出现故障的驱动器中的数据恢复过来。大多数 RAID 控制器可以置换出现故障的驱动器，并在 Windows 和 SQL Server 联机时从镜像驱动器的另一侧重建数据（通常称为可“热插拔”的驱动器）。镜像的一个优点是当要求容错时，它是最佳的 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 对于每个 Windows NT/SQL Server 写操作都需要四个磁盘 I/O 操作，而镜像则只需要两个磁盘 I/O 操作。镜像和奇偶校验的读 I/O 操作的成本相同。而且，在脱机以及从备份媒体中恢复数据之前，RAID 5 阵列只能允许有一个驱动器失败。
      通用的经验法则：确保将尽可能多的磁盘条带化以便达到稳定的磁盘 I/O 性能。Performance Monitor 将显示某个 RAID 阵列上是否出现磁盘 I/O 瓶颈现象。作好必要的时候添加磁盘并在 RAID 阵列和/或小型计算机系统接口中重新分配数据的准备，以平衡磁盘 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 吞吐量。这并不是说 RAID 控制器可以无限地使硬盘每秒钟处理更多的 I/O，RAID 控制器高速缓存只是使用一些组织来排列输入的 I/O 请求，从而尽可能好地使用基础的硬盘定量 I/O 处理能力。
      这些 RAID 控制器通常使用某种形式的备份功能来保护它们的高速缓存机制。备份功能有助于将写在高速缓存中的数据保留一段时间（可能是数天），以防止停电。并且在生产环境中，通过为服务器提供充足的不间断电源 (UPS) 保护，使 RAID 控制器具有更多的保护和电源备用时间，以便当服务器出现断电的时候，可用它来将数据刷新到磁盘中，从而加强了数据库服务器的保护。
  RAID 级别
  RAID 1 和 RAID 0+1 提供最有效的数据保护和最好的 RAID 级别性能，但它需要更多的磁盘。当不限制硬盘的成本时，RAID 1 或 RAID 0+1 是性能和容错力均最佳的 RAID 选择。
  RAID 5 用最低的成本来实现容错，但是只有 RAID 1 和 0+1 一半的写性能，这是因为 RAID 5 必须读奇偶信息，并将奇偶信息写入磁盘，从而需要额外的 I/O。RAID 5 的容错能力不及 RAID 1 和 0+1。
  RAID 0 可实现最好的磁盘 I/O 性能（没有容错保护的磁盘条带化），但是因为 RAID 0 没有容错能力，所以这种 RAID 级别通常只能用于开发数据库服务器或其它测试环境。
     许多 RAID 阵列控制器在物理硬盘上提供 RAID 0+1 选项（也称为 RAID 1/0 和 RAID 10）。RAID 0+1 是混合 RAID 解决方案。在较低的层次，它像普通 RAID 1 一样镜像所有的数据；在较高的层次，控制器在所有驱动器中将数据条带化（像 RAID 0 一样）。因此，RAID 0+1 在提供最高性能（条带化）的同时提供最大程度的保护（镜像）。条带化和镜像操作对于 Windows 和 SQL Server 是透明的，因为它们由 RAID 控制器管理。RAID 1 和 RAID 0+1 之间的不同在于硬件控制器的级别。对于s相同的存储量，RAID 1 和 RAID 0+1 要求同样多的驱动器。有关如何在特定的 RAID 控制器上实施 RAID 0+1 的细节，请与生产控制器的硬件厂商联系。
  图 1 说明了 RAID 0、RAID 1、RAID 5 和 RAID 0+1 之间的不同。请注意要容纳四个磁盘量的数据，RAID 1（和 RAID 0+1）需要八个磁盘，而 RAID 5 则需要五个磁盘。确保找到正确的硬件厂商，以了解在运行数据库服务器的特定硬件上实施 RAID 的细节。
  联机 RAID 扩充
  这是一种十分方便的功能，它使得我们可以在 SQL Server 联机的时候，将磁盘动态地添加到有热插拔插槽的物理 RAID 阵列。许多硬件厂商都提供具有这种功能的硬件 RAID 控制器。它自动将所有驱动器（包括新添加的驱动器）中的数据重新平均地条带化，而没有必要关闭 SQL Server 或 Windows。一个好主意是空出磁盘阵列箱中的热插拔驱动器插槽以便使用此功能。因此，如果 SQL Server 通常由于过多的 I/O 请求导致 RAID 阵列负担过重（这可由与 RAID 阵列相关的 Windows 逻辑驱动器号的磁盘队列长度显示出来），可以在 SQL Server 运行期间在热插拔插槽中安装一个或多个新硬盘。RAID 控制器将一些已有的 SQL 数据重新分配到这些新硬盘，以便在 RAID 阵列的所有硬盘中平均分配 SQL 数据。于是，新硬盘的 I/O 处理容量（每个驱动器每秒 75 个非连续 I/O 或 150 个连续 I/O）就添加到 RAID 阵列的总的 I/O 处理容量中。
  Performance Monitor 和 RAID
  在 Performance Monitor 中，逻辑磁盘对象和物理磁盘对象有效地提供相同的信息。所不同的是 Performance Monitor 中的逻辑磁盘与 Windows 视为逻辑驱动器号的磁盘相关。Performance Monitor 中的物理磁盘与 Windows 视为单个物理硬盘的磁盘相关。
  要启用 Performance Monitor 计数器，在 Windows 命令提示窗口的命令行运行 diskperf.exe 命令。运行“diskperf -y”以便 Performance Monitor 报告逻辑和物理磁盘的数量。它可以在使用硬盘或硬盘组以及 RAID 控制器时有效，而无需使用 Windows NT 软件 RAID。
  当运用 Windows NT 软件 RAID 时，应使用“diskperf -ye”以便 Performance Monitor 正确报告 Windows NT 条带集中的物理计数器。当“diskperf -ye”与 Windows 条带集结合起来使用时，逻辑计数器无法报告正确的信息，需将其忽略。如果要求将逻辑磁盘计数信息与 Windows NT 条带集结合起来使用，应使用“diskperf -y”命令。将“diskperf -y”和 Windows NT 条带集结合起来使用，可以正确报告逻辑磁盘的数量，但是物理磁盘计数器将无法报告正确信息，需将其忽略。
  请注意只有在 Windows NT 重新启动之后，diskperf 命令才有效。
  还请注意硬件 RAID 控制器将组成单个 RAID 镜像集或条带集的多个物理硬盘作为一个物理磁盘呈现给 Windows。磁盘管理器用于使逻辑驱动器号与单个物理磁盘相关联，而无需考虑实际有多少个硬盘与 RAID 控制器呈现给它的单个物理硬盘相关联。
  但是从性能优化的角度来看，了解与 RAID 阵列相关联的物理硬盘的数量是十分重要的，因为在确定 Windows 和 SQL Server 发送给每个物理硬盘的磁盘 I/O 请求的数量时需要这一信息。将 Performance Monitor 所报告的与某个硬盘相关联的磁盘 I/O 请求的数量除以该 RAID 阵列中已知的实际物理硬盘的数量。
  要粗略估算 RAID 阵列中每个硬盘的 I/O 活动，还有很重要的一点是将 Performance Monitor 所报告的磁盘写 I/O 的数量乘以 2（RAID 1 和 0+1）或 4 (RAID 5)。这样将对发送到物理硬盘的实际 I/O 请求给出一个更准确的数量估计，因为硬盘所应用的 I/O 容量数（每个驱动器 75 个不连续 I/O 和 150 个连续 I/O）处于这个物理级别。但是如果硬件 RAID 控制器使用高速缓存，便不要指望用这种方法可以准确计算出硬盘中的 I/O 数，因为高速缓存可以大大改变硬盘中实际的 I/O 数，其原因已在前面讲述过。
  最好的办法是只关心磁盘队列，而不关心每个磁盘实际的 I/O，因为归根到底，如果 I/O 并没有引发问题，那么又何必担心它呢？Windows 无法了解 RAID 阵列中的物理驱动器数量，因此要准确估算每个物理磁盘的磁盘队列，重要的是用磁盘队列长度除以包含所考察的逻辑驱动器的硬件 RAID 磁盘阵列中的物理驱动器数。对于包含 SQL Server 文件的硬盘，这个数字不要超过 2。
  有关 SQL Server 和 RAID 的详细信息，请在 SQL Server Books Online 中搜索字符串“RAID Levels and SQL Server”、“Comparing Different Implementations of RAID Levels”、“Monitoring Disk Activity”、“Performance Monitoring Example:Identifying Bottlenecks”、“About Hardware-based Solutions”和“RAID”。
  Windows NT 软件 RAID
  Windows NT 通过 Windows NT 操作系统（而不是硬件 RAID 控制器）来提供镜像集和条带集（有或没有容错能力），从而为出现故障的硬盘提供容错能力。Windows NT 磁盘管理器用于定义镜像集 (RAID 1) 或带奇偶校验 (RAID 5) 的条带集。Windows NT 磁盘管理器还可以定义没有容错能力 (RAID 0) 的条带集。
  软件 RAID 将使用更多的 CPU 资源，因为 Windows NT 是管理 RAID 操作而不是硬件 RAID 控制器的组件。因此，如果系统处理器使用率接近 100%，那么在使用相同数量的硬盘的情况下，Windows NT 软件 RAID 的性能可能会比硬件 RAID 解决方案要低几个百分点。但是，如果用一组驱动器来维护 SQL Server I/O，Windows NT 软件 RAID 通常可以帮助它们实现比单独使用这些驱动器所获得的更好的总体性能，减小了出现 I/O 瓶颈的可能性，从而提高了 SQL Server 的 CPU 利用率，并增加了吞吐量。而且因为软件 RAID 可以为硬盘提供容错力，因而是一个成本更低的解决方案。
  有关配置 Windows NT 软件 RAID 的详细信息，请参见 Windows NT 服务器联机帮助中的第 4 章“设计可靠配置”。同时在 SQL Server Books Online 搜索字符串“About Windows NT-based Disk Mirroring and Duplexing”和“About Windows NT-based Disk Striping and Striping with Parity”。
  磁盘 I/O 并行
  当处理放置在几个磁盘驱动器上的小型 SQL Server 数据库时，磁盘 I/O 并行可能不起作用。但是当处理存储在许多磁盘驱动器上的大型 SQL Server 数据库时，使用磁盘 I/O 并行，以便最有效地使用磁盘子系统的 I/O 处理能力，从而达到改善性能的目的。
  创建磁盘 I/O 并行最简单的方法是创建一个“驱动器池”，存储除了事务日志文件之外的所有 SQL Server 数据库文件。该驱动器池可以是在 Windows NT 中作为单个物理驱动器的单个 RAID 阵列，也可以是一个用多个 RAID 阵列和 SQL Server 文件/文件组组成的大型池。SQL Server 文件可以与每个 RAID 阵列发生关联，且这些文件可以组成一个 SQL Server 文件组。然后可以在这个文件组上建立一个数据库，以便数据可以均匀地分布在所有驱动器和 RAID 控制器上。“驱动器池”方法依赖于 RAID 在所有的物理驱动器上分配数据，以确保在数据库服务器运行期间并行存取数据。
  这种池的方法简化了 SQL Server I/O 性能的优化，因为数据库管理员知道只能在一个物理位置上创建数据库对象。可以监视单个驱动器池的磁盘队列，如果有必要，也可以在池中添加更多的硬盘以防止出现磁盘队列。这一技术可以在通常不知道数据库的哪些部分使用率最高的情况下帮助优化性能。最好不要将 I/O 总的可用容量中的一部分隔离到其它磁盘分区上，因为 SQL Server 可能只有 5% 的时间在对它进行 I/O 操作。“单个驱动器池”的方法有助于使所有可用 I/O 容量总能为 SQL Server 操作使用。
  请注意 SQL Server 日志文件应始终在物理上分散到与其它所有的 SQL Server 数据库文件不同的硬盘。对于数据库十分忙碌的 SQL Server，事务日志文件应在物理上相互隔开。事务记录主要是连续的写 I/O。将事务记录活动与其它不连续的磁盘 I/O 活动分开对 I/O 性能有许多好处。这使得包含日志文件的硬盘可以专事连续 I/O。请注意事务日志有时需要作为 SQL Server 操作（如复制、回滚和延迟的更新）的一部分读出。因为需要进行这些读操作，所以尤其应注意参与复制的 SQL Server，确保所有事务日志文件有足够的磁盘 I/O 处理能力。
  通过 SQL Server 文件和文件组，在物理上将 SQL Server 对象与它们相关的数据库的其余部分分开的过程还涉及到其它管理工作。这对于调查非常活跃的表和索引十分有价值。通过将表或索引与其它数据库对象分开，可以准确估算对象的 I/O 需求。如果所有数据库对象都放置在一个大型的驱动器池中，则该工作不容易进行。比较好的办法是在数据库开发和基准测试期间进行这种物理 I/O 分割，这样就可以收集数据库的 I/O 信息并在制定生产数据库服务器环境的容量计划时使用这些信息。
  以下是可以分散在不同的硬盘、RAID 控制器、PCI 通道（或这三者的组合）的 SQL Server 活动：
  事务日志文件
  Tempdb
  数据库文件
  与许多查询或写活动相关的表
  与许多查询或写活动相关的非聚集索引
  可以用硬件 RAID 控制器、RAID 热插拔驱动器和联机 RAID 扩展很容易地实现 SQL Server I/O 活动的物理分割。这种方法提供最高的灵活性，因为它排列 RAID 控制器以便为以上所列出的每个单独的 SQL 活动提供单独的 RAID SCSI 通道。每个 RAID SCSI 通道都应连到单独的 RAID 热插拔柜，以便充分利用联机 RAID 扩展（如果可通过 RAID 控制器获得）。Windows 逻辑驱动器号与每个 RAID 阵列相关联，并且可以根据已知的 I/O 使用模式将 SQL Server 文件分散在各个 RAID 阵列中。
  通过这种配置，有可能使磁盘队列重新与不同的 RAID SCSI 通道以及它的驱动器发生关联，因为 Performance Monitor 可以在装载测试以及繁重的生产负荷期间报告队列行为。如果 RAID 控制器和驱动器阵列支持联机 RAID 扩展，并且在该阵列中有可用的热插拔硬盘插槽，那么解决该 RAID 阵列的磁盘队列的方法很简单，只需在该 RAID 阵列中添加更多的驱动器，直到 Performance Monitor 报告该 RAID 阵列的磁盘队列已达到可接受的级别（对于 SQL Server 文件可接受的级别小于 2）。这一过程可以在 SQL Server 联机时进行。
  Tempdb 是由 SQL Server 创建的数据库，可用作各种活动共享的工作区域，这些活动包括临时表、排序、子查询、用 GROUP BY 或 ORDER BY 的聚合以及使用 DISTINCT（必须创建临时工作表以删除重复行）的查询、游标和哈希联接。使 tempdb I/O 操作与相关事务的 I/O 操作并行发生是一个不错的主意。因为 tempdb 是一个草稿区域，更新频繁，所以对于它来说，选择 RAID 5 不如选择 RAID 1 或 0+1 更加适合。因为每次重新启动数据库服务器时都要重新创建 tempdb，所以 RAID 0 可用于生产型 SQL Server 机器中的 tempdb。RAID 0 使用的物理驱动器最少，且可为 tempdb 提供最好的 RAID 性能。在生产环境中将 RAID 用于 tempdb 的主要顾虑在于，如果 RAID 0 阵列中有任何物理驱动器出现故障，SQL Server 都需要停止，然后重新启动，如果 tempdb 置于 RAID 1 或 RAID 0+1 阵列中，则不一定这样。
  要移动 tempdb 数据库，使用 ALTER DATABASE 命令改变与 tempdb 相关的 SQL Server 日志文件名的物理文件位置。例如，要将 tempdb 及其相关的日志移动到新的文件位置 e:\mssql7 和 c:\temp，可使用以下命令：
  alter database tempdb modify file (name='tempdev',filename= 'e:\mssql7\tempnew_location.mDF')
  alter database tempdb modify file (name='templog',filename= 'c:\temp\tempnew_loglocation.mDF')
  相对于用户数据库，master、msdb 和 model 数据库在生产中用得不很多，因此通常在考虑 I/O 性能优化时没必要考虑它们。master 数据库通常只用来添加新的登录、数据库、设备和其它系统对象。
  非聚集索引在 B 树结构中，可以用 ALTER DATABASE 命令将它们与它们相关的数据库表分开。在下例中，第一个 ALTER DATABASE 创建一个文件组。第二个 ALTER DATABASE 创建一个与该文件组相关、但位于单独物理位置的文件。此时，可以在该文件组中创建出如以下代码所示的索引，并将该索引命名为 index1。SP_HELPFILE 报告给定数据库中的文件和文件组。SP_HELP [table]的输出中有一部分提供表的索引及其文件组关系的信息。有关详细信息，请在 SQL Server Books Online 中搜索字符串“ALTER DATABASE”和“sp_helpfile”。
  alter database testdb add filegroup testgroup1
  alter database testdb add file (name = 'testfile',
  filename = 'e:\mssql7\test1.ndf') to filegroup testgroup1
  create table test1(col1 char(8))
  create index index1 on test1(col1) on testgroup1
  sp_helpfile
  sp_help test1
  有关详细信息，请在 SQL Server Books Online 中搜索字符串“Files and Filegroups”、“Placing Indexes on Filegroups”、“Monitoring Disk Activity”、“Physical Database Files and Filegroups”和“Adding and Deleting Data and Transaction Log Files”。