几个月以来我一直在努力解决这个问题，我说这不是数据库问题，并将此案例分配给存储和操作系统团队，然后他们将其分配给我。这个问题反复发生，没有任何明确的发生模式。
我检查了这里提出的相同问题，我可以说这不是数据库损坏的问题，因为我正在使用 Ola Hallengren 的脚本进行维护工作，并且每周对用户和系统数据库进行数据库完整性检查（checkdb），并且没有报告任何问题在那里面。
也为类似的问题访问了第二个链接，并且可以确认 tempdb 处于简单恢复状态。
我为数据和日志添加了一个额外的文件，这样如果一个文件不可用，另一个文件仍然可以访问，但是后来我知道 tempdb 的访问是顺序的，所以只有在第一个文件满时才会转到第二个文件：
每次发生此问题时，我都会在 Windows 应用程序日志中看到另一个错误，如下所示：
SQLServerLogMgr::LogWriter: Operating system error 170(The requested resource is in use.) encountered.
存储团队已将这些文件排除在防病毒扫描之外。
这里要注意的一件事 - 我检查了其他系统数据库及其文件位置，可以看到对于 master 和 model，数据和日志文件在同一个驱动器（E 驱动器）中，而对于 tempdb 和 msdb，数据在 E 驱动器和日志中文件在 G 盘，不知道这是否相关。
当作业触发或任何事件被触发时，是否有任何检查系统数据库的顺序？如果它是那个驱动器的问题，那么 msdb 也在同一个驱动器上。
这是一个集群服务器，数据库驱动器在两台服务器中共享，服务器用于共享点应用程序。
Server Version: Windows Server 2012 Standard
SQL Server: Microsoft SQL Server 2012 (SP4-GDR) (KB4057116) - 11.0.7462.6 (X64)
Jan 5 2018 22:11:56
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
我们剩下的唯一选择是重新启动服务或故障转移 - 这样做听起来不太好。
感谢您在这方面的任何帮助。
是的，这是从日志写入器遇到的操作系统错误中冒出来的。在这种情况下，操作系统错误 170 是资源正在使用中。问题出在 SQL Server 之外（除非将任何错误的第 3 方 DLL 加载到地址空间中），这真是太糟糕了。
通常，当我看到它是防病毒、主机保护、碎片整理软件、备份软件等时，当驱动器在后端未正确设置时，最终会在文件或集群环境中保持长时间锁定。
不想粗鲁，但我不买它。告诉他们你想要证据。此外，仅仅因为文件被“排除”并不意味着防病毒软件不会查看它，它仍然会查看它——只是在大多数情况下不会进行所有深入检查。
怎么办？
我会首先检查流氓应用程序是否正在尝试做某事。问题是这可能在任何时候发生，并且有问题的（如果有的话）应用程序可能会持有锁很短的时间或很长一段时间——我们不知道。
快速执行此操作的方法之一是在有问题的文件上使用sysinternals 处理应用程序。由于此错误在 SQL Server 中有一个错误代码，因此您应该能够创建一个代理警报来执行一个作业，该作业调用一个小批处理文件或 PowerShell 或您创建的任何东西来对文件运行句柄。这应该有助于尝试快速获取信息（但可能不够快）。
另一种解决方法，特别是如果您可以相当频繁或轻松地重现它，是运行进程监视器(procmon)，它是另一种 sysinternals 工具，用于捕获除 SQL Server 之外的文件的内容。