我在Web应用程序上遇到一些磁盘访问问题。
主要负载是在大型表上的许多并发插入/更新/select。
它目前是一个2ru机架上运行的SQL Server 2000和IIS，运行raid5，数据库为4x15k SAS; 和6GB的内存/ 8个物理内核。 CPU和内存使用看起来很好。
我正在考虑的事情….
任何我应该看/考虑？
谢谢，克里斯
几件事。 首先，群集服务器不会给你任何性能好处，只会增加可用性。
解决磁盘I / O问题最简单的办法就是增加服务器的内存。 随着更多的数据页面存储在RAM中，查询运行所需的物理I / O就越less。
根据您的工作负载，如果您可以负担迁移到SAN，那么您可能需要考虑将TempDB，日志和数据文件拆分到单独的物理磁盘上（您可能需要查看有关存储顶部的MS文章SQL Server的10个最佳实践： http ： //technet.microsoft.com/en-us/library/cc966534.aspx ）。 正如Hutch所说的，脱离RAID 5，特别是对于日志和TempDB，这些写入的数据量很大（RAID 5对于奇偶校验的写入惩罚）。
正如Chopper3所说，FusionIO驱动器是当前最快的驱动器之一。 如果你有他们的预算，这绝对是一个探索的领域（尤其是你的TempDBs）。
HTH，丹
移动你的数据和日志到一个FusionIO驱动器，非常昂贵，但据我所知，你现在无法获得更快的持久性存储。
哦，你也应该移动到2008R2 64位，当然，加载内存。
想到的就是考虑将RAID5转换成RAID10或RAID1对。
这是一个巨大的话题，但我可能会提供一些技巧来帮助您开始。 一般来说，我认为你可以说在你决定如何最好地解决你的问题之前，你需要收集更精确的信息是安全的。 最后可能会涉及内存问题或磁盘问题。
（我将忽略查看运行缓慢的查询的可能性，并试图找出是否有办法改进它们。这是一个巨大的话题 ，但使用查询分析器可以帮助您确定是否缺less索引或查询应完全重写）。
我将首先使用性能pipe理工具来看看几个关键指标。 SQL Server性能计数器是一个很好的地方。 磁盘队列统计也可以非常明显。 应用程序（即SQL Server）是否在磁盘I / O上等待执行操作？ 如果是这样，那么你知道你将需要升级磁盘（或可能修复查询）。 @Hutch是正确的，RAID 10将为数据库服务器提供比RAID 5更好的性能，但实际上，只有在等待写入时才会发挥作用。 RAID 5中的4个15K RPM驱动器应该能够处理相当合理的RAID卡（当然，合理和/或体面的是相对的）。
我也会检查内存 。 服务器正在运行SQL Server 2000，所以我将假定它是一个32位的服务器操作系统。 SQL服务器实际上能够使用所有的内存？ 在32位系统上，您需要使用PAE来使用全部6 GB，即使如此，我相信SQL服务器进程本身也只能增长到4 GB。 您可以使用像sysinternals进程资源pipe理器这样的程序来查看实际使用的内存量。 你甚至可以查看多less内存SQL Server“想要” – 检查出SQL Server：内存pipe理器计数器（如果它们在2000年可用，记不起我的头顶）。
您还提到该服务器正在运行IIS。 如果您在运行其他重负载服务的服务器上运行MS SQL Server，则可能需要考虑手动configuration应该使用多less内存。 默认情况下，SQL Server假定它在专用服务器上，并尝试dynamic分配尽可能多的内存。 根据您的IIS进程的需要，这可能不是一件好事。 在运行多个应用程序的服务器上，我通常喜欢通过将最小值和最大值设置为相同的值（例如4GB，10GB，等等）来configurationSQL Server以准确使用一定量的RAM。
最后，你可以考虑升级SQL Server。 SQL Server 2005在某些领域引入了一些大的速度增强，可能会使您受益，具体取决于您的设置。 更何况，你可以获得一个64位版本的SQL Server 2005/2008，并在64位操作系统上运行这个版本，以便为它提供更多的内存，而内存则是SQL中最重要的东西之一服务器。
这个话题需要一个巨大的“It Depends”来解答。 虽然迄今为止发布的答案对于给定的条件是好的和正确的，但还有更多。
是的，从RAID-5移动到RAID-10是“现在就做”这个专栏中的一个巨大的复选标记，但是我们还没有被告知那些东西呢？
考虑到这一点，我想出了以下几点：磁盘布局：
什么文件在什么驱动器上？ TempDb在哪里，TempDb有多less个文件是关联的？DB和T-Logs在不同的驱动器上？
查询pipe理和优化：
最重的查询是否被识别和优化？ 怎么样？ 更新是否导致行重定位或者是否能够“就地更新”？ 更新期间的行重定位会导致各种性能问题。 索引pipe理：需要的索引是否到位，它们是否被正确定义以便被需要的查询所利用？ 索引重build：索引随着时间的推移变得碎片化，需要重新组织或重build。 不这样做会影响性能。
环境：驱动器碎片可能导致文件碎片。 即使驱动器保持清洁，任何数据库或T-Log文件的大量范围都会产生负面影响。 从SQL 2000升级到SQL 2005或（更好）2008或2008 R2是一个很好的build议。 在Windows Server 2008 x64或Windows Server 2008 R2 x64上运行本地补充了6GB的内存。 SQL Server 2008和2008 R2有内置工具来帮助识别问题查询。 在强调DBA的环境中，这是值得升级的。 驱动器控制器高速caching：是否足够？ caching是否在多个逻辑驱动器之间共享？
资源竞争（压力）：
除了IIS之外，SQL Server系统还有哪些进程正在竞争系统的资源？
添加SAN并不是一个坏主意，但是您需要了解环境。 了解性能增长的原因是由于表扫描，不正确的外键pipe理，更新过程中的行重定位，还有其他问题，或者“上述所有”，非常重要。 不知道其根本原因意味着添加SAN将只是暂时的好处。 而且，了解您的环境对于适当调整SAN的大小是必须的 – 这不仅关乎可用空间。
我不了解你的环境，不能就你应该做什么给出合理的答案。 我的上面的清单也是许多深思熟虑的书的题目。