web-dev-qa-db-ja.com

「DBCC SHRINKDATABASE」へ、または「DBCC SHRINKDATABASE」へ:それが問題です

SQL Server 2008 R2データベースの多くの領域を解放しています-Loooot!気にするのに十分です(私たちはたくさんの不要なデータを削除しています)。ただし、データベースファイルはファイルサイズを保持します。それを取り戻したいです。

DBCC SHRINKDATABASEを使用すると、DBのパフォーマンスが低下すると何度も聞いたことがあります。データベース内のインデックスの数、および一般にある程度まで断片化を増加させます " [MSDN]

DBCC SHRINKDATABASEを使用してから、インデックスを再構築する予定です。

ディスクスペースを取り戻すためにDBCC SHRINKDATABASEを使用しない別のパフォーマンス上の理由がありますか?

5
SDReyes

Tibor Karasziのブログ から:

それで問題は何ですか?定期的にデータベースファイルを縮小すべきではないのはなぜですか?以下のリストを見て、データベースファイルを定期的に圧縮するかどうかを自分で判断できます。

  • 移動された各ページはトランザクションログに記録されます。たとえば、50GBの使用済みスペース(データおよびインデックスページ)を持つデータベースがあり、縮小によりファイルの先頭に向かって40 GBがシャッフルされます。この縮小操作では、ログファイルに40GBが必要です。おそらく、そのサイズに自動拡張されます(ログファイルに40GBの空き領域がない場合)。次のログバックアップは、サイズが40GBに「通常の」ログレコードを加えたものになります。データベースがシンプルリカバリモードの場合、これは発生しないようです。CHECKPOINTは、圧縮中にログを定期的にプルーニングするためです。 (データファイルの圧縮に適用されます。)

  • 縮小後、ユーザーがデータベースに行などを追加すると、ファイルは再び拡大する必要があります。データベースファイルの拡張はコストのかかる操作であり、時間がかかり、パフォーマンスも低下します(多くのリソース使用量)。また、一部の変更は、拡張操作が完了するまでブロックされます。 (データファイルとログファイルの両方の圧縮に適用されます。)

  • SQL Server 2005以降:SQL Server 2005以降、「ファイルの即時初期化」が可能になりました。つまり、Windowsはデータベースファイルのデータを「ゼロ化」しないため、データベースファイルを作成でき、非常に高速に拡張できます。即時ファイル初期化は、ログファイルではなく、データファイルでのみ使用できます。また、インスタンスファイルの初期化では、SQL ServerサービスのサービスアカウントにSE_MANAGE_VOLUME_NAMEウィンドウ権限が必要です。これは、ボリュームメンテナンスタスクの実行セキュリティポリシーを使用して割り当てることができます。これは、デフォルトでは管理者にのみ付与されます。

  • 自動拡張がスペース使用量の要件に「追い付かない」状況があります。これにより、変更が実行されたときにSQL Serverからエラーメッセージがクライアントアプリケーションに返されます。データがいっぱいの場合はエラー1105、ログがいっぱいの場合は9002です。 (データファイルとログファイルの両方の圧縮に適用されます。)

  • データページを移動すると、データベースが断片化します。インデックスを再構築すると(データベースに空き領域が必要になります)、データベースを圧縮するとします。圧縮により、本質的にインデックスの再構築が取り消され、フラグメント化されたインデックスが残ります。信じられない?これは自分でテストするのは簡単です。

  • 逆にそれを行い、最初に縮小してから再構築するとどうなりますか?まあ、rebuldは、再構築する最大のインデックスのためにデータベース内に空き領域を必要とし、クラスター化インデックスを持つ大きなテーブルがある可能性があります。私の友人は4GBの使用済みスペースdbを持っていて、ほとんどすべてのスペースが1つの4GBテーブルでした。彼は縮小してから再構築しましたが、再構築するとすぐにデータベースサイズが8 GBに「増加」しました。 (データファイルの圧縮に適用されます。)

  • データベースファイルが大幅に縮小および拡大すると、ファイルシステムが断片化し、パフォーマンスがさらに低下します。 (データファイルとログファイルの両方の圧縮に適用されます。)

  • トランザクションログファイルの縮小とその後の拡大が繰り返されると、通常、多くの仮想ログファイルが生成され、データベースの起動時間が長くなる可能性があります。これは、データベースの長い起動時間、長い復元時間、トランザクションレプリケーションの遅延などとして現れます。詳細については、このブログ投稿を確認してください。

8
SDReyes