データベースに対して有効にできるSQL Serverオプションは多数あり、最も誤解されているものの1つは自動圧縮です。安全ですか?そうでない場合、なぜそうではないのですか?
(元々は通常の質問として尋ねましたが、正しい方法を見つけました-BrentOに感謝します)
いいえ、ありません。
ServerFaultでこれに何度か遭遇したので、Niceの幅広い聴衆にいくつかの良いアドバイスを提供したいと考えています。人々がこのやり方で眉をひそめたら、反対投票して私は喜んでこれを削除します。
自動圧縮は、有効にする非常に一般的なデータベース設定です。データベースから余分なスペースを削除してください。自動圧縮が明らかに悪であることを知らない可能性のある多くの「非自発的DBA」(TFS、SharePoint、BizTalk、または通常の古いSQL Serverなど)が存在します。
Microsoftにいる間、私はSQL Serverストレージエンジンを所有していて自動圧縮機能を削除しようとしましたが、下位互換性のためにそれを維持する必要がありました。
自動縮小がなぜそれほど悪いのですか?
データベースは再び大きくなる可能性が高いので、なぜそれを縮小するのですか?
しばらく前にブログの投稿で、SQLスクリプトの例を示し、それが引き起こす問題を示し、もう少し詳しく説明しました。 自動縮小–オフにする! を参照してください(私のブログには、このような広告やジャンクはありません)。これをログファイルの圧縮と混同しないでください。
データベース設定を確認し、自動圧縮をオフにしてください。また、まったく同じ理由で、保守計画を縮小すべきではありません。御言葉を同僚に広めましょう。
編集:私はこれを追加する必要があります。2番目の答えを思い出してください。縮小操作を中断すると破損が発生する可能性があるという一般的な誤解があります。いいえ、ありません。以前はSQL Serverで縮小コードを所有していました-中断された場合に実行している現在のページ移動をロールバックします。
お役に立てれば!
もちろん、ポールは正しいです。
すべてのDBとその自動圧縮設定を表示します。データベースがたくさんある場合は、こっそり入ります。
sp_msforeachdb @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'
これはdmvのどこかにありますか。
「危険」ではありません-何も損傷しません。
しかし、要求の山が来る直前にデータベースが停止して高額な再配置を開始する可能性がある本番環境では、これらの要求の処理に時間がかかるようになるため、お勧めしません。縮小操作のスケジュール設定を、バックアップなどの他のメンテナンス操作(実際には、バックアップ後-トランザクションログからより多く行われる)と共に使用する方がはるかに便利です。または、拡大の問題がない限り、まったく縮小しない-いつでもモニターを設定して、未使用の割り当てられたスペースが特定の比率または固定サイズを超えたときに通知することができます。
IIRCオプションは、Expressを除くすべてのMSSQLエディションのすべてのデータベースに対してデフォルトでオフになっています。
TechNetには、SQLのメンテナンスについて詳しく説明したホワイトペーパーがあります。
AutogrowとAutoshrinkの両方が有効になっているSQLサーバーを見ました。この(比較的強力な)サーバーは、データベースファイルを縮小して拡張することだけが1日中行われていたため、非常に低速でした。自動圧縮は便利ですが、次の2つをお勧めします。
データベースを圧縮せざるを得なかったのは、テストサーバーでコピーを更新するときだけで、ディスク容量は少なくなります(運用データベースを保持するには不十分)。
本番データベースのファイルには十分な空き容量がありましたが、残念ながら、バックアップしたときと同じファイルサイズでデータベースを復元する必要があります。したがって、バックアップする前に生産を縮小する以外に選択肢はありませんでした。 (縮小には時間がかかり、多くのリソースが消費され、その後のトランザクションログの増加に問題がありました。)
このビデオチュートリアルもご覧ください。
Paul Randalが、縮小と自動縮小がデータベースに深刻な断片化の問題を引き起こす可能性があることを示すデモをご覧ください http://wtv.watchtechvideos.com/topic194.html