次の方法で共有


SQL Server ファイルの OS エラー 665 と 1450 が報告される

この記事は、 DBCC CHECKDBの実行中、データベース スナップショットの作成中、またはファイルの拡張中にデータベース ファイルに対して OS エラー 1450 と 665 が報告される問題を解決するのに役立ちます。

元の製品バージョン: SQL Server
元の KB 番号: 2002606

現象

SQL Server を実行しているコンピューターで、次のいずれかのアクションを実行するとします。

  • 大規模なデータベースにデータベース スナップショットを作成します。 次に、ソース データベースで多数のデータ変更またはメンテナンス操作を実行します。
  • ミラー データベースにデータベース スナップショットを作成します。
  • DBCC CHECKDB 一連のコマンドを実行して、大規模なデータベースの整合性を確認し、そのデータベースで大量のデータ変更を実行します。

Note

SQL Server では、データベース スナップショットとDBCC CHECKDBの操作にsparse ファイルが使用されます。

  • データベースのバックアップまたは復元。
  • 並列 BCP 実行と同じボリュームへの書き込みを使用して、 BCP を介して複数のファイルへの一括コピーを実行します。

これらの操作の結果として、SQL Server が実行されている環境によっては、SQL Server エラー ログで 1 つ以上のエラーが報告される場合があります。

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 0x00002a3ef96000 in file 'Sam.mdf:MSSQL_DBCC18'
The operating system returned error 1450 (Insufficient system resources exist to complete the requested service.) to SQL Server during a write at offset 0x00002a3ef96000 in file with handle 0x0000000000000D5C. This is usually a temporary condition and the SQL Server will keep retrying the operation. If the condition persists, then immediate action must be taken to correct it.`

これらのエラーに加えて、次のラッチ タイムアウト エラーが発生する場合もあります。

Timeout occurred while waiting for latch: class *'DBCC_MULTIOBJECT_SCANNER'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  
Timeout occurred while waiting for latch: class *'ACCESS_METHODS_HOBT_COUNT'*, id 000000002C61DF40, type 4, Task 0x00000000038089B8 : 16, waittime 600, flags 0x1a, owning task 0x0000000006A09828. Continuing to wait.  

さらに、 sys.dm_exec_requestssys.dm_os_waiting_tasksなど、さまざまな動的管理ビュー (DMV) を表示するとブロックされる場合もあります。

まれに、SQL Server エラー ログに報告され、SQL Server によってメモリ ダンプが生成されるという、生成されないスケジューラの問題が発生することがあります。

原因

この問題は、NTFS で頻繁に断片化されたファイルを維持するために多数の ATTRIBUTE_LIST_ENTRY インスタンスが必要な場合に発生します。 ファイル システムによって既に追跡されているクラスターの横にスペースがある場合、属性は 1 つのエントリに圧縮されます。 ただし、スペースが断片化されている場合は、複数の属性で追跡する必要があります。 したがって、ファイルの断片化が重いと、属性が枯渇し、結果として 665 エラーが発生する可能性があります。 この動作については、次の KB 記事で説明します。 NTFS ボリューム内の大量に断片化されたファイルは、特定のサイズを超えて拡張されない可能性があります

SQL Server または他のアプリケーションによって作成された通常のファイルとスパース ファイルの両方が、これらのスナップショット ファイルの有効期間中に大量のデータ変更が行われると、これらのレベルに断片化する可能性があります。

同じボリューム上にあるすべてのファイルのストライプ セットに対してデータベース バックアップを実行する場合、または同じボリューム上の複数のファイルにデータを一括コピー (BCP-ing) する場合、書き込みが隣接する場所で、別のファイルに属している可能性があります。 たとえば、1 つのストリームが 201 から 400 の間のオフセットに書き込み、もう 1 つのストリームが 401 から 600 に書き込まれます。3 番目のストリームは 601 から 800 に書き込むことができます。 このプロセスは、他のストリームでも続行されます。 これにより、同じ物理メディアでファイルの断片化が発生します。 各バックアップ ファイルまたは BCP 出力ストリームは、隣接するストレージを取得しないため、属性ストレージを使い果たすことができます。

SQL Server エンジンが NTFS スパース ファイルと代替データ ストリームを使用する方法の完全な背景については、「 詳細情報を参照してください。

解決方法

この問題を解決するには、次のオプションの 1 つ以上を使用することを検討してください。

  1. データベース ファイルを Resilient File System (ReFS) ボリュームに配置します。このボリュームには、NTFSと同じATTRIBUTE_LIST_ENTRY制限はありません。 現在の NTFS ボリュームを使用する場合は、データベース ファイルを一時的に別の場所に移動した後、ReFS を使用して再フォーマットする必要があります。 ReFS の使用は、この問題に対処するための最適な長期的なソリューションです。

    Note

    SQL Server 2012 以前のバージョンでは、スパース ファイルの代わりに file streams CHECKDB スナップショットを作成するために使用されています。 ReFS はファイル ストリームをサポートしていません。 ReFS で SQL Server 2012 ファイルで DBCC CHECKDB を実行すると、エラーが発生する可能性があります。 詳細については、「 DBCC CHECKDB が SQL Server 2014 以降で内部スナップショット データベースを作成する方法の注意事項を参照してください。

  2. データベース ファイルが存在するボリュームのフラグメント化を解除します。 最適化ユーティリティがトランザクションであることを確認します。 SQL Server ファイルが存在するドライブの最適化の詳細については、「 SQL Server データベース ドライブと推奨事項を最適化するときのを参照してください。 ファイルに対してこの操作を実行するには、SQL Server をシャットダウンする必要があります。 安全策としてファイルを最適化する前に、データベースの完全バックアップを作成することをお勧めします。 最適化はソリッド ステート ドライブ (SSD) メディアでは動作が異なり、通常は問題に対処しません。 多くの場合、ファイルをコピーし、SSD ファームウェアが物理ストレージを再パッケージ化できるようにする方が優れたソリューションです。 詳細については、「オペレーティング システム エラー (665 - ファイル システムの制限) が DBCC に対してだけではなくなっている」を参照してください。

  3. ファイル コピー - ファイルのコピーを実行すると、プロセス内でバイトが密にパックされる可能性があるため、より適切な領域の取得が可能になる場合があります。 ファイルをコピー (または別のボリュームに移動) すると、属性の使用量が減り、OS エラー 665 が妨げになる可能性があります。 1 つ以上のデータベース ファイルを別のドライブにコピーします。 その後、ファイルを新しいボリュームに残すか、元のボリュームにコピーし直すことができます。

  4. 大きな FRS を取得するには、 /L オプションを使用して NTFS ボリュームをフォーマットします。 この選択により、 ATTRIBUTE_LIST_ENTRY が大きくなるため、この問題が軽減される可能性があります。 この選択は、データベース スナップショットのスパース ファイルが作成されるため、 DBCC CHECKDB を使用する場合には役立たない場合があります。

    Note

    Windows Server 2008 R2 および Vista を実行しているシステムでは、format コマンドで /L オプションを使用する前に、KB の記事967351の修正プログラムを適用する必要があります。

  5. 大きなデータベースを小さなファイルに分割します。 たとえば、1 つの 8 TB データ ファイルがある場合は、8 つの 1 TB のデータ ファイルに分割できます。 このオプションは、小さいファイルで行われる変更が少なくなるため、属性の枯渇を引き起こす可能性が低いために役立つ場合があります。 また、データを移動するプロセスでは、ファイルがコンパクトに整理され、断片化が軽減されます。 プロセスの概要を示す大まかな手順を次に示します。

    1. 7 つの新しい 1 TB ファイルを同じファイル グループに追加します。
    2. 既存のテーブルのクラスター化インデックスを再構築します。これによって、各テーブルのデータが 8 つのファイルに自動的に分散されます。 テーブルにクラスター化インデックスがない場合は、インデックスを作成し、削除して同じ結果を得る必要があります。
    3. 元の 8 TB ファイルを圧縮します。このファイルは約 12% でいっぱいになりました。
  6. データベースの自動拡張設定: 自動 拡張増分 データベース設定を調整して、運用環境のパフォーマンスと NTFS 属性のパッキングに役立つサイズを取得します。 自動拡張が発生する頻度が低くなり、増加増分サイズが大きいほど、ファイルの断片化の可能性が低くなります。

  7. パフォーマンスの向上を使用して DBCC CHECK コマンドの有効期間を短縮し、665 エラーを回避します。dbCC CHECKDB コマンドの improvements を使用すると、PHYSICAL_ONLY オプションを使用するとパフォーマンスが向上する可能性がありますPHYSICAL_ONLYスイッチを使用してDBCC CHECKDBを実行しても、このエラーを回避できる保証はありませんが、多くの場合、可能性が低下します。

  8. 多数のファイル (ストライプ セット) でデータベースバックアップを実行する場合は、ファイル、 MAXTRANSFERSIZEBLOCKSIZE の数を慎重に計画します ( BACKUPを参照してください)。 目標は、大きなバイト チャンクをまとめてファイルに書き込むことで一般的に実現されるファイル システム上のフラグメントを減らすことです。 パフォーマンスを向上させ、断片化を軽減するために、複数のボリューム間でファイルをストライピングすることを検討してください。

  9. BCP を使用して複数のファイルを同時に書き込む場合は、ユーティリティの書き込みサイズを調整します 。たとえば、BCP バッチ サイズを大きくします。 また、断片化を回避したり、並列書き込みの数を減らしたりするために、複数のストリームを異なるボリュームに書き込むこともできます。

  10. DBCC CHECKDBを実行するには、可用性グループまたはログ配布/スタンバイ サーバーの設定を検討してください。 または、2 つ目のサーバーを使用して、 DBCC CHECKDB コマンドを実行して作業をオフロードし、スパース ファイルの断片化が激しい場合に発生する問題が発生しないようにします。

  11. DBCC CHECKDBを実行するときに、データベース サーバーでアクティビティが少ないときにコマンドを実行すると、スパース ファイルが少し設定されます。 ファイルへの書き込みが少ないほど、NTFS で属性が使い果たされる可能性が低くなります。 可能であれば、2 番目の読み取り専用サーバーで DBCC CHECKDB を実行するもう 1 つの理由として、アクティビティが少なくなります。

  12. SQL Server 2014 を実行している場合は、最新の Service Pack にアップグレードします。 詳細については、「 FIX: SQL Server 2014 で列ストア インデックスを含むデータベースに対して DBCC CHECKDB コマンドを実行する場合の OS エラー 665を参照してください。

詳細