Jef*_*f A 11 sql-server dbcc-checkdb sql-server-2014
有一个在 Windows 2012 R2 上运行的 SQL Server 2014 实例，每周运行 Ola Hallengren 的数据库完整性脚本，最近两周开始出现此错误：
DESCRIPTION: The operating system returned error 665(The requested operation could
not be completed due to a file system limitation) to SQL Server during a write at
offset 0x000036ec240000 in file 'E:\DBFiles\XXXXX.mdf_MSSQL_DBCC42'. Additional
messages in the SQL Server error log and system event log may provide more detail. This
is a severe system-level error condition that threatens database integrity and must be
corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This
error can be caused by many factors; for more information, see SQL Server Books Online.
我检查了事件日志和 SQL Server 错误日志，但没有得到很多有用的附加信息。我正在DBCC像上周一样重新运行这个数据库的检查，它清除了 MSSQL_DBCC42 文件并且没有发现任何损坏。
除了事件日志和 SQL Server 错误日志之外，还有其他地方我可以找到更多信息吗？我是否应该询问我们的存储组，看看 SAN 的报告中是否显示了某些内容，还是由于某些争用，这纯粹是 SQL 相关的？
这个数据库非常活跃，因为它在 iSeries 上复制了来自我们 JDE 财务和制造环境的交易，目前大约 300GB。每天晚上，数据库都会备份并恢复到开发服务器。对我DBCC的数据库副本进行检查会更好吗？该数据库是为前一天报告构建 SSAS 多维多维数据集的来源，因此我可以选择完全重建数据或尝试从备份中恢复（如果数据损坏等）。
感谢您对可能导致此错误的原因或DBCC checkdb根据情况运行的最佳选择的任何想法。
Sim*_*rts 11
DBCC 在内部使用快照。然后在 Windows 中将快照实现为稀疏文件。
所以这实际上是 Windows 处理稀疏文件的一个问题，这导致 DBCC 使用的快照偶尔会在大型和非常活跃的数据库上中断。它在http://support.microsoft.com/kb/2002606 中有一些推荐的修复程序的合理记录
但是，如果您可以在开发服务器上使用 DBCC，我建议您改用它。（我个人只在 DBCC 'd/snapshotted 时仍在服务流量的数据库中看到了这个问题。备份/恢复到空闲服务器，DBCC => 没有更多的 665 错误。）