オペレーティングシステムがエラー665を返しました（ファイルシステムの制限のため、要求された操作を完了できませんでした）
Ola HallengrenのDB整合性スクリプトを毎週実行するWindows 2012 R2で実行されているSQL Server 2014インスタンスがあり、過去2週間でこのエラーが発生し始めました。
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 checkを実行する方がよいでしょうか？このDBは、前日のレポート用にSSAS多次元キューブを構築するためのソースであるため、データを完全に再構築するか、データが破損した場合にバックアップから回復するかを選択できます。
このエラーの原因を考え、状況に応じてDBCC checkdbを実行するための最良のオプションを検討してください。
DBCCは内部的にスナップショットを使用します。スナップショットは、Windowsではスパースファイルとして実装されます。
したがって、これは実際には、Windowsのスパースファイルの処理に関する問題であり、DBCCが使用するスナップショットが、大規模で非常にアクティブなデータベースでときどき壊れる原因になります。 http://support.Microsoft.com/kb/2002606 にいくつかの推奨される修正が含まれており、かなり適切に文書化されています。
ただし、開発サーバーでDBCCを実行できる場合は、代わりにそれをお勧めします。 （私が個人的にこの問題を見たのは、DBCCされた/スナップショットされている間にトラフィックを処理し続けていたデータベースだけです。アイドル状態のサーバーへのバックアップ/復元、DBCCがそこにある=> 665エラーはもうありません。）