我一直在监视OLTP数据库的性能（大约150GB）;平均磁盘秒/读取和平均磁盘秒/写入值在24小时内超过20毫秒。什么影响平均。磁盘秒/硬件读取？
我需要清楚地解释为什么业务应用程序对这些计数器上“不如恒星”的性能没有影响。我还需要施加一些压力，让存储人重新检查它们的配置，因为它适用于在其SAN上放置mdf，ldf和tempdb文件。目前，我的观点很不稳定，但我对那些不了解IOP和磁盘延迟差别的人提出了自己的观点。
除了物理硬件的限制和物理磁盘上数据文件的放置之外，还有什么会影响这些计数器值？例如：每秒的事务数量，查询的大小，写得不好的查询或缺少索引？我的读物说'不'，但在这场辩论中我需要一个权威的声音。
有很多因素会影响整体延迟。要真正将其统一为SAN，您需要查看您提到的“平均磁盘秒数/读取计数器”和“平均数据库秒数/写入计数器”。只要确保你正在查看“物理磁盘”对象，而不是“逻辑磁盘”对象。逻辑磁盘计数器包含文件系统开销，并且可能会有所不同，具体取决于不同的因素。
拥有物理磁盘的计数器后，您需要将它们与服务器连接的存储单元的延迟计数器进行比较。你提到“存储人”所以我会假设这是一个不同的团队，希望他们会很好，并提供给你的信息。
如果是存储单元问题，那么这两个计数器应该相当不错。这表明存储单元真正运行缓慢。如果存储单元计数器显示更好，那么它介于两者之间。根据您使用的存储网络类型，这将是将服务器和存储连接在一起的HBA/NIC /交换机。或者如果它是一台虚拟机，那么主机的统计信息也会证明是有用的。
除了显而易见的原因，例如“缓冲池内存不足”，延迟主要取决于您的存储实际实施方式。
如果你的服务器有外部SAN，通常它的问题是它可能会给你提供很好的吞吐量，但永远不会（再次，通常）给你很大的延迟。事情就是这样。当然，它可能会成为一个真正令人头痛的重负载OLTP系统。
因此，如果您即将从存储中挤出最后一个微秒，那么很可能您需要本地驱动器。那么，你的RAID 10应该有足够的主轴来应付负载。
以上所有内容都没有足够的信息 - 例如，如果您没有足够的内存，将会有很多IO。如果查询一次加载大量数据，您将获得大量转移。 SQL Server的活动监视器说什么？服务器的DMV说什么？激活数据收集（在SSMS管理下）获取有用的指标 –
感谢您的回复Panagiotis。嗨罗杰。感谢您的答复。尽管“avg disk sec/read”是衡量磁盘延迟而不是磁盘IO的一种衡量标准。我已经理解读延迟（例如）是控制器找到合适的数据块并将磁头置于这些块上（包括旋转磁盘盘片所需的时间）所需的时间。也就是说，开始转移过程。 – ianv
据我所知，有限的RAM导致更多的磁盘操作，但我不明白这将如何影响“avg disk sec/read”和“avg disk sec/write”。这些计数器似乎测量磁盘子系统的物理能力。 – ianv