我们的生产 sql 服务器（物理）存在一个持续问题，我们在日志中随机收到此错误，使数据库进入恢复状态
SQLServerLogMgr::LogWriter: Operating system error 1117(The request could not be performed because of an I/O device error.) encountered.
该问题总是发生在我们存储事务日志的驱动器上。数据库通常会自行恢复，但很少有实例不会，我们需要重新启动实例才能恢复。dbcc checkdb 没有从任何数据库返回错误。
我们的存储团队已经与我们的供应商一起调查了数周，但没有成功。调查正在进行中。
话虽如此，除了向存储团队报告并检查数据库损坏之外，sql server dba 应该如何处理此错误？我想知道我是否可以从 sql server 端收集更多信息，这可能有助于他们的调查？
运行 SQL Server 2012 SP3，存储是 SAN。
第一次更新
我们的基础架构团队昨晚进行了以下更改
- 更新了数据库服务器上所有 NIC 上的固件
- 更新了网络交换机上的固件
- 为 ICSCI 启用巨型帧
我们还没有收到错误，我会在一周左右再次更新。
第二次更新
先前更新中所做的更改并未解决该问题。昨晚我们将 tempdb 从 SAN 移动到物理服务器上的本地驱动器，并禁用了 iSCSI 优化连接跟踪。我们还没有收到错误，而且我们还看到对我们的数据和日志驱动器（仍在 san 上）的磁盘读/写速度更快，当然 tempdb 是本地的。此外，我们在错误期间以及全天都在 Windows 事件日志中收到了许多 iSCSI 错误。由于昨晚的这些变化，那些 iCSI 错误大部分都消失了，仍然有一些出现，但几乎没有那么多。
谢谢，凯文
从数据库方面您确实无能为力。SQL Server 是底层硬件和虚拟化（如果有）问题的受害者。需要修复底层问题（驱动程序、硬件、配置等）。请注意，如果您在虚拟化环境中，它可能是介于两者之间的软件层或主机/来宾配置等问题，而不是物理硬件或存储问题。
实际上，删除所有过滤器驱动程序和相关软件，通过删除它们并将其放在物理（如果虚拟）和/或更改存储解决方案（例如，使用本地而不是远程/SAN）来停止和中间层可以帮助帮助在解决问题时。更新驱动程序（例如多路径、设备、固件等）也可能会有所帮助，但我不会向 DBA 收取费用，而是向数据中心或系统管理员收取费用。
并不真地。下面我们通过 Windows 调用读写 API。通过 Windows 调用 API 的返回代码是我们正在冒泡的这个 Windows 错误代码，以便 SQL Server 的管理员知道 SQL Server 出现问题的原因。
如果有的话，因为它是一个单一的卷，他们应该能够在后端隔离它并启用基础设施跟踪。如果这是一台物理机器，这将来自 HBA/scsi 控制器，然后通过硬件。如果它是虚拟的，那么从主机通过相同的层。
可悲的是，这说起来容易做起来难，而且大多数地方都没有能力实际调查这些类型的问题——尤其是当环境被虚拟化时。
系统事件日志说什么？是否会出现进一步的 NTFS 或其他损坏问题？设备是否正在重置？系统事件日志应该用非常细的齿梳来剖析，看看是否有一系列事件或项目似乎导致了这一点，或者它是否是自发的。此外，我发现这些事件通常集中在某些项目周围，例如特定控制器上的高使用时间或过度使用的 SAN。