DBCC CHECKDBがスペースの問題を返すエラー
本番環境のデータベースには、さまざまなドライブに28ndfファイルがあり、Tドライブではtest_audit20.ndfからtest_audit23.ndfファイルのみです。ファイルtest_audit20およびtest_audit21.ndf autogrowthはありません。
test_audit dbでcheckdbコマンドを実行しているときにエラーが発生します：
メッセージ1823、レベル16、状態6、行1
開始に失敗したため、データベーススナップショットを作成できません。
メッセージ1823、レベル16、状態7、行1
開始に失敗したため、データベーススナップショットを作成できません。
メッセージ1823、レベル16、状態8、行1
開始に失敗したため、データベーススナップショットを作成できません。
メッセージ7928、レベル16、状態1、行1
オンラインチェック用のデータベーススナップショットを作成できませんでした。
理由は前のエラーに示されているか、基になるボリュームの1つがスパースファイルまたは代替ストリームをサポートしていません。
チェックをオフラインで実行するための排他的アクセスを取得しようとしています。
メッセージ8921、レベル16、状態3、行1
チェックが終了しました。ファクトの収集中に障害が検出されました。 tempdbの容量不足か、システムテーブルに一貫性がない可能性があります。以前のエラーを確認してください。
メッセージ3313、レベル21、状態1、行1
データベース「test_audit」でログに記録された操作の再実行中に、ログレコードID（19372：991854：10）でエラーが発生しました。
通常、特定の失敗は以前にWindowsイベントログサービスのエラーとして記録されていました。完全バックアップからデータベースを復元するか、データベースを修復します。
メッセージ9001、レベル21、状態7、行1
データベース「test_audit」のログは使用できません。イベントログで関連するエラーメッセージを確認してください。エラーを解決し、データベースを再起動します。
メッセージ5128、レベル17、状態2、行1
スパースファイル 't：\ test_audit23.ndf_MSSQL_DBCC6'への書き込みは、ディスク容量不足のため失敗しました。
メッセージ0、レベル20、状態0、行0
現在のコマンドで重大なエラーが発生しました。結果がある場合は、破棄する必要があります。
このディスクに書き込む必要がある理由がわかりません。
このディスク上のファイルの1つで自動拡張がオンになっている可能性があります。これをオフにすると、動作する可能性があります。
現在、私は「アクティブな」データドライブであるXおよびYドライブを持っています。これらもほぼフル（それぞれ3 TB）であり、私はいくつかの新しいディスクドライブを立ち上げて、それらにデータファイルを統合する必要があります。このリージョンでプロビジョニングされたテラバイトのAWSの制限に達しました。
さらに、これらのデータファイルを毎週手動で拡張しています。以前に述べたように、SQLの自動拡張はすべてのファイルがいっぱいになるまで待機するため、これに依存することはできません。これにより、データの書き込みが1つのディスク/ファイルに集中化され、これが発生するとパフォーマンスに劇的な悪影響を及ぼします。カスタマーサポートへのチケットが急増し、SLAに影響します。
私の質問は、Tドライブ上のデータファイルの自動拡張をオフにして、もう一度試すことはできますか？問題が発生するか、他の方法がありますか？.
メッセージは失敗の理由を伝えています。失敗の根本的な原因は次のとおりです。
スパースファイル 't：\ test_audit23.ndf_MSSQL_DBCC6'への書き込みは、ディスク領域が不足しているため失敗しました。
Tボリュームのスペースが不足しているようです。
このディスクに書き込む必要がある理由がわかりません。
非表示のスナップショットが作成され、データベースでクラッシュリカバリが実行されて整合性のある状態になり、データベースの非表示のスナップショットコピーに対してcheckdbを実行できるようになります。これは、checkdbがオンラインで実行された場合の動作です。オンラインの方法では行われない場所でロックがかかるため、「オフライン」と呼ばれるタブロックオプションがあります。
あなたはほとんど正しいです。単一のデータファイルへのすべての書き込みを強制するわけではありませんが、比例した塗りつぶし値を再計算するため、いくつかのファイルでホットスポットが発生します。これはわかっており（誰も気にしないようですが）、ファイルグループ全体を一緒に拡張するためにトレースフラグを設定したのはそのためです（TF 1118）。これは変更され、2016年にデータベースオプションになりました。
毎週手動でデータファイルを拡張することは過剰に思われます。別のサイズで増加することがわかっている場合TB毎週、なぜそれを低くするのですか？パフォーマンスボリュームメンテナンスタスクがサービスアカウントまたはサービスSIDに与えられている場合、データファイルはかなり大きく、影響はほとんどありません。
私の質問は、Tドライブのデータファイルで自動拡張をオフにしてからもう一度試すことはできますか？問題が発生するか、それとも他の方法がありますか？.
自動拡張の設定は問題ではありません。まばらな書き込みとボリュームのスペース不足です。
更新：
これらのタイプの問題に対処するための最良の方法は何でしょうか？スペースを追加しますか？
多分。依存します。
データファイルがすでにモノリシックボリューム上にある場合は、同じボリュームからの移行に取り組みます。マウントポイント、ストレージスペースなどを使用できますが、必要なのは使用可能なスペースがあることです。繰り返しますが、これは自動拡張の設定とは関係がなく、使用可能な空き領域の量と、スナップショットの整合性を保つために必要な領域の量とは関係ありません。
他に何ができますか？
まあ、一度にCheckDB（）を実行する必要はありません。 checkalloc、checkcatalog、checktableなどを使用して、一口サイズのより小さなチェックのチャンクに分割できます。 こちらのリンクを参照してください。ホイールを作り直す必要はありません。ポールはすでに素晴らしい記事を持っているので。
この場合、より多くのndfファイルが存在し、23番目のndfファイルに書き込む理由は、Xドライブの28.ndfに書き込む必要があります。
この問題の根本的な原因は、CheckDBの動作に慣れていないことであり、それは大丈夫です。ある程度の理解が必要になっていることを知っているので、私が与えたリンクをチェックして、Paulの投稿を読んでください。
スナップショットファイルはeachデータファイルに対して作成されます。これはスナップショットであり、実際にはデータベース自体に書き込まれません。あなたがポールのシリーズを読んだとき、私はあなたが何をそしてなぜを理解するであろうと信じます-この答えとともに。