我有一个SQL Server 2005实例正在经历一些缓慢的时间。 这个链接显示了perfmon的细节。 由于我不会每天分析这种types的数据，所以我想知道I / O系统是否存在一些实际问题。
服务器正在使用SAN，DB文件和Tempdb文件位于同一个驱动器上（E :)。 不是最好的架构，但我不能控制服务器。 服务器用于使用Cognos运行报告，因此它主要是只读数据库。
谢谢
这是一些有趣的代码，需要更正。
select "tempSalesRpt_SubRgnDist"."Region" AS "Region", min("tempSalesRpt_SubRgnDist"."RegionName") AS "Region_Text" from "SalesReporting"."dbo"."tempSalesRpt_SubRgnDist" "tempSalesRpt_SubRgnDist", (select "SecurityMaster"."Userid" AS "Userid", "SecurityMaster"."SoldTo" AS "SoldTo" from "SalesReporting"."dbo"."SecurityMaster" "SecurityMaster" where "SecurityMaster"."Userid" = lower ('USTGACA')) "SecurityMaster4" where NOT "SecurityMaster4"."Userid" is null and "tempSalesRpt_SubRgnDist"."SoldTo" ="SecurityMaster4"."SoldTo" group by "tempSalesRpt_SubRgnDist"."Region" order by 1 asc , 2 asc 每个查询都会访问securitymaster表，并且这是最近增加的表。
我会假设这段代码有非可优化的代码，但执行计划显示索引查找被使用和密钥查找。
我确实看到一些新的指标可以帮助，但需要进一步挖掘。
根据所提供的数据，你有一些事情正在进行。 您的磁盘队列是每个读取秒，每个写入计数器秒数高得多，那么你想要他们。 现在这里的问题是，这并不意味着它是一个磁盘问题，只是磁盘遭到抨击。 您可能会遇到索引问题或统计问题，这会导致SQL Server比需要更难的磁盘。
首先查看数据库中的索引，并查看是否需要创build任何新的索引。 这将增加数据库的大小，但是您将看到磁盘stream量的减less以及查询运行时间的减less。
您可以先看看长时间运行的查询的执行计划，它会告诉您需要添加索引的位置。
除了Denny的答案，你的盒子上有大约5GB的可用内存 – 你有正确configurationSQL的内存吗？
如果你有一个32位的系统，你可以通过启用AWE来解决更多的内存问题：
http://technet.microsoft.com/en-us/library/ms190673(SQL.90).aspx
SQL将使用这个额外的内存来caching更多的数据库表/索引（假设你的数据库比你的空闲内存大）。