问SQLServerLogMgr::LogWriter:操作系统错误1117

EN

话虽如此，除了向存储团队报告此错误并检查数据库损坏外，sql服务器dba还应如何处理此错误？

从数据库方面来说，真的没有什么可以做的。Server是底层硬件和有问题的虚拟化(如果有的话)的受害者。底层问题(驱动程序、硬件、配置等)需要修理。请注意，如果您处于虚拟环境中，它可能是介于主机/客户配置之间的软件层，或者是主机/客户配置等问题，而不是物理硬件或存储问题。

实际上，删除所有筛选器驱动程序和相关软件，通过删除这些层并将其放置在物理(如果是虚拟的)和/或更改存储解决方案(例如，使用本地而不是远程/SAN)中，可以帮助解决问题。更新驱动程序(例如多路径、设备、固件等)也可能是有帮助的，但不是我会要求DBA去做的事情，而是一个数据中心或系统管理。

我想知道是否还有更多的信息可以从server端收集到，这可能有助于他们的调查？

不怎么有意思。在下面，我们通过Windows调用读写API。API调用通过Windows返回的代码是这个Windows错误代码，我们正在鼓起它，以便Server管理员知道为什么Server会出现问题。

如果有的话，因为它是一个卷，所以它们应该能够在后端隔离它，并启用基础结构跟踪。如果这是一台物理机器，这将是从HBA/scsi控制器和下面通过硬件。如果它是虚拟的，那么从主机通过相同的层。

可悲的是，这比说起来容易得多，而且大多数地方都没有真正调查这些问题的能力--特别是在环境被病毒笼罩的时候。

最后的思想

系统事件日志显示了什么？是否还会出现NTFS或其他腐败问题？设备正在重置吗？系统事件日志应该用一个极细的齿梳进行剖析，看看是否有一系列事件或项目似乎会导致这种情况，或者是否是自发的。此外，我还发现这些事件通常集中在某些项目上，例如在特定控制器上使用频繁的时间或过度使用的SAN。