二次ファイルを削除するのは悪い考えですか？
16個のdbファイルを持つSQLDBを継承しました。 16 3の同じファイルグループ内のすべてが拡張するように設定されており、他は静的にそれぞれ1GBを消費します。余分なファイルを削除すると、パフォーマンスに影響がありますか？その後、インデックスの再作成などを行う必要がありますか？
これは保留になっているので、答えた3人の紳士が私の質問に適切に答えたと思いますが、私はもっと明確にしようとします。彼らに感謝します、3つの応答すべてが役に立ちました。
明快さの問題に関して、一番下の質問はこれです。プライマリファイルグループに16個のファイルで構成されるDBがあります。それらは同じドライブの同じフォルダーにあります。 13個のファイルがDBサイズの1％未満を占めています。適切な手順に従って削除すると、パフォーマンスに大きな影響（断片化など）が発生する可能性があります。
回答ありがとうございました。
ファイルグループ内のファイルの適切な数を決定する際には、多くの考慮事項があります。このファイルグループ内のファイルの適切な数とレイアウトを決定することは別の質問ですが、無視してはなりません。データベースのファイルレイアウトは重要である可能性があり、ファイルグループからファイルを追加/削除するというトピックは、多くの接線の議論のポイントを提起します。
そうは言っても、あなたはすでにそれらのことを見ていて、いくつかのファイルを削除しなければならないという結論に達したと仮定します。
ファイルグループからデータファイルを削除することを選択した場合、最初のステップはDBCC SHRINKFILE(logicalname,EMPTYFILE)を実行することです。 （これを手動で行わない場合は、GUIが自動的に行います。GUIを介してこの種のことを行うことはお勧めしません。）これにより、このファイルからデータページが退避され、ファイルグループ内の別のファイルに移動されます。余裕があります。これはページごとに行われ、オンライン操作です。ただし、他のファイル縮小と同じように、あらゆる種類の厄介な断片化が発生します。
ファイルを削除した後、インデックスのメンテナンスを実行することをお勧めします。
始める前に、最後に残したいファイルも検討する必要があります。 FileBを縮小しようとしているときに、FileAを自動拡張しようとしないように、これらのファイルを事前に拡張します。または、新しいファイルをいくつか作成して、既存の16個のファイルを削除することもできます。
提案されているようにパフォーマンス上の利点がないことが絶対に確実な場合は、セカンダリデータファイルを安全に削除できます。これを行うには、すでにご存知かもしれませんが、ファイルを空にしてから削除する必要があります。ファイルが削除されたら、インデックスのメンテナンスジョブ（再構築または再編成）を実行してから統計を更新し、断片化が存在しないことと、オプティマイザーがデータに関する最新のデータを持っていることを確認します。
あなたが持っていない限り私は気にしません
- 非常にビジーなデータベース（おそらくピーク時）と複数のディスク/ SSDアレイ
- または非常に大規模なデータベースと複数のディスク/ SSDアレイ
複数のファイルグループはある程度の負荷を分散できますが、多くの場合、部分的な復元、読み取り専用ファイルグループなどによる回復可能性に関するものです
「ログ先行書き込み」のため、トランザクションスループットはほとんどの場合ログファイルによって決定されます。複数のセカンダリファイルは、多くの場合、価値を付加しません。それらを削除します