回答:
（私はもともと通常の質問として尋ねましたが、正しい方法を見つけました-BrentOに感謝します）
いいえ、決して。
ServerFaultでこれに何度か出会ったことがありますが、良いアドバイスをして幅広い聴衆にリーチしたいと思っています。このやり方で人々が眉をひそめている場合は、投票してください。喜んで削除します。
自動縮小は、有効になっている非常に一般的なデータベース設定です。良いアイデアのようです-データベースから余分なスペースを削除してください。自動縮小が積極的に悪であることを知らない「TFS、SharePoint、BizTalk、または通常の古いSQL Serverを考えてみてください」という「不本意なDBA」がたくさんいます。
MicrosoftでSQL Server Storage Engineを所有していて、自動縮小機能を削除しようとしていましたが、下位互換性のために維持する必要がありました。
なぜ自動収縮がそんなに悪いのですか？
データベースは再び成長する可能性が高いので、なぜ縮小するのでしょうか？
しばらく前に、それが引き起こす問題を示し、もう少し詳細に説明するサンプルSQLスクリプトがあるブログ投稿をしました。自動縮小を参照してください-オフにしてください！（私のブログではそのような広告やジャンクはありません）。これをログファイルの縮小と混同しないでください。これは、便利で時折必要になります。
それでは、データベース設定を見て、自動縮小をオフにしてください。また、まったく同じ理由で、メンテナンスプランを縮小しないでください。同僚にその言葉を広めます。
編集：2番目の答えを思い出して、これを追加する必要があります-シュリンク操作を中断すると破損する可能性があるという一般的な誤解があります。いいえ、できません。以前はSQL Serverでシュリンクコードを所有していました-中断された場合に実行している現在のページ移動をロールバックします。
お役に立てれば！
もちろん、ポールは正しいです。
すべてのDBとその自動圧縮設定を参照してください。データベースがたくさんある場合は、忍び込むでしょう。
sp_msforeachdb @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'
これはdmvのどこかにありますか。
それは「危険」ではありません-それは何にも損害を与えません。
しかし、大量のリクエストが来てそれらのリクエストの処理に時間がかかる直前にデータベースが停止し、高価な再配置演習を開始することを決定する可能性がある本番環境にはお勧めできません。バックアップなどの他のメンテナンス操作と一緒にスケジュール縮小操作を使用する方がはるかに優れています（実際には、バックアップ後-トランザクションログからより多くなります）。または、成長の問題がない限り、まったく縮小しない-モニターを設定して、未使用の割り当てられたスペースが特定の比率または固定サイズを超えたときにいつでも通知できます。
IIRCは、Expressを除くすべてのMSSQLエディションのすべてのデータベースでデフォルトでオフになっています。
SQLのメンテナンスについて詳しく説明しているホワイトペーパーがTechNetで入手できます。
データベースを縮小することを余儀なくされたのは、ディスク容量が少ない（運用データベースを保持するには不十分）テストサーバーでコピーを更新することだけでした。
本番データベースのファイルには十分な空き領域がありましたが、残念ながら、バックアップしたファイルと同じサイズのデータベースを復元する必要があります。したがって、バックアップする前に生産を縮小する以外に選択肢はありませんでした。（縮小には時間がかかり、多くのリソースが消費され、その後のトランザクションログの増加には問題がありました。）
このビデオチュートリアルもご覧ください。
Paul Randalが、シュリンクと自動シュリンクがデータベースの深刻なフラグメンテーションの問題をどのように引き起こすかを ご覧くださいhttp://wtv.watchtechvideos.com/topic194.html