追加のスペースを使用せずにSQL Server 2008でデータベースのmdfファイルを圧縮する方法はありますか?
ハードディスクの合計容量は136 GB、.MDFファイルのサイズは124 GB、ログファイルのサイズは2 GBです。 12 GBの空き容量しかないため、.MDFファイルでshrinkコマンドを実行すると、ログが大きくなり、空き容量が消費されます。ディスク容量が少ないと、縮小により無応答状態になります。
追加のディスク領域を使用せずにこのファイルを圧縮する別の方法はありますか?
ここで答えをまとめるとおよび自分のアドバイスを挿入します。
1:データファイルを盲目的に縮小することは最適なルートではありません。あなたのデータはあなたのデータであり、このサイズによって特徴付けられます。大きなデータのチャンクを削除することを計画しているのでない限り、圧縮してもほとんど何も起こりません。 @ billinkc が指摘しているように、単にファイルを圧縮しても、目に見えるほどの利益は得られません。
2:これを実行すると、ログファイルが大きくなります。どうやらあなたはあなたのデータと同じドライブにログオンしています。スペースやIO競合など)の多くの理由から、これはお勧めしません。
3:新しいデータファイルを作成して、別のボリュームに配置することができます。古いデータを「アーカイブ」して現在の.mdfのスペースを解放するか、現在のデータファイルをそのままにしておくと、一種のアーカイブになります。
4:このボリュームには他にも何かがあると思います。スペースを空けるために、できる限り迅速にそれらの物を移動しました。
これがエンタープライズデータである場合、より多くのディスクを要求します。これにより、データファイルとログファイルを分離できます。さらに、データを削除するだけでなく、とにかくブランドンの提案を実装するには、さらにディスクが必要になります。
できれば縮小は避けます。これにより、使用しているインデックスの断片化の問題が発生し、パフォーマンスの問題が発生します。また、ファイルシステムの断片化を引き起こす可能性があります。
がっかりしている場合は、同じファイルグループ内の2番目のデータファイルを別のボリュームに追加します。 SQL Serverは、新しいデータをその新しいファイルに書き込み始めます。これは、ファイルのサイズが同じになるまで行われ、基本的にラウンドロビン方式で処理されます。
これにより、より大きなディスクを取得できるまで、ドライブ全体を回避することに集中できます。
DBCC SHRINKDBは、多くのログ、ディスクIO、およびブロッキングの問題を引き起こします。絶対に縮小する必要がある場合は、小さなチャンクで縮小してみましたか?たぶん、一度に1 GBまたは500 MB縮小するだけかもしれません。また、ログファイルをデータと同じドライブに配置しても問題ありませんか?ドライブアレイが破損している場合、ログバックアップのテールは実行できず、パフォーマンスに大きな影響を与える可能性があります。
それを行うGUIの方法を探している場合は、DBをSIMPLE RECOVERYに設定します(SSMSでDBを右クリックし、[プロパティ]、[オプション]、[復旧モデル]-> [シンプル]に移動します)。
次に、ファイルの圧縮を行います。最初にログファイル、次にデータファイルです。これを行うには、SSMS、タスク、縮小、ファイルでDBを右クリックします。 FileTypeをログに設定し、「ページの再編成...」を選択して、できるだけ低く設定します。繰り返しますが、FileTypeをDataに設定します。
上記のSIMPLE RECOVERYに変更する前にDBがFULL RECOVERYにあった場合は、DBをFULL RECOVERYに戻します。 SIMPLE RECOVERYがすでに設定されている場合は、そのままにしておきます。
この種の縮小は、多くのインデックスの断片化を引き起こし、おそらく日常的なことではないはずですが、ジャムから抜け出すことができます:)