我们的生产 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。
第一次更新
我们的基础架构团队昨晚进行了以下更改
我们还没有收到错误，我会在一周左右再次更新。
第二次更新
先前更新中所做的更改并未解决该问题。昨晚我们将 tempdb 从 SAN 移动到物理服务器上的本地驱动器，并禁用了 iSCSI 优化连接跟踪。我们还没有收到错误消息，我们还看到对数据和日志驱动器（仍在 san 上）的磁盘读/写速度更快，当然 tempdb 是本地的。此外，我们在错误发生期间以及全天收到 Windows 事件日志中的许多 iSCSI 错误。由于昨晚的这些变化，那些 iCSI 错误大部分都消失了，仍然有一些出现，但几乎没有那么多。
谢谢，凯文
话虽如此，除了向存储团队报告并检查数据库损坏之外，sql server dba 应该如何处理此错误？
从数据库方面，您真的无能为力。SQL Server 是底层硬件和虚拟化（如果有）问题的受害者。需要修复底层问题（驱动程序、硬件、配置等）。请注意，如果您处于虚拟化环境中，则可能是中间的软件层或主机/来宾配置等问题，而不是物理硬件或存储问题。
实际上，删除所有过滤器驱动程序和相关软件，通过删除它们并将其放在物理（如果虚拟）和/或更改存储解决方案（例如，使用本地而不是远程/SAN）来停止和中间层可以帮助在解决问题时。更新驱动程序（例如多路径、设备、固件等）也可能有帮助，但不是我会向 DBA 收取费用的事情，而是数据中心或系统管理员。
我想知道我是否可以从 sql server 端收集更多信息，这可能有助于他们的调查？
并不真地。下面我们通过 Windows 调用读写 API。通过 Windows 调用 API 的返回代码是我们冒泡的这个 Windows 错误代码，以便 SQL Server 的管理员知道 SQL Server 出现问题的原因。
如果有的话，因为它是一个单一的卷，他们应该能够在后端隔离它并启用基础设施跟踪。如果这是一台物理机，则这将来自 HBA/scsi 控制器和以下硬件。如果是虚拟的，则从主机通过相同的层。
可悲的是，这说起来容易做起来难，而且大多数地方都没有能力实际调查这些类型的问题——尤其是当环境虚拟化时。
最后的想法
系统事件日志说什么？是否有进一步的 NTFS 或其他损坏问题出现？是否正在重置设备？系统事件日志应该用极其精细的梳子进行剖析，看看是否有一系列事件或项目似乎导致了这一点，或者它是否是自发的。此外，我发现这些事件通常集中在某些项目周围，例如特定控制器上的高使用时间或不堪重负的 SAN。
| 归档时间： |
|
| 查看次数： |
2667 次 |
| 最近记录： |