次の方法で共有

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

  • [アーティクル]

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

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

現象

SQL Serverを実行しているコンピューターで、次のいずれかの操作を実行することを想定しています。

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

注:

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

  • データベースのバックアップまたは復元。
  • 並列 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. データベース ファイルを回復性のあるファイル システム (ReFS) ボリュームに配置します。NTFS と同じATTRIBUTE_LIST_ENTRY制限はありません。 現在の NTFS ボリュームを使用する場合は、データベース ファイルを一時的に他の場所に移動した後、ReFS を使用して再フォーマットする必要があります。 ReFS の使用は、この問題に対処するための最適な長期的なソリューションです。

    注:

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

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

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

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

    注:

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

  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 コマンドの機能強化により、PHYSICAL_ONLY オプションを使用するとパフォーマンスが向上する可能性があります。 スイッチを使用してPHYSICAL_ONLY実行DBCC CHECKDBしても、このエラーを回避できる保証は提供されませんが、多くの場合は可能性が低下します。

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

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

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

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

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

詳細