最近、本番データベースのバッチからテーブルデータを削除し、SSMSの[ファイルの縮小]機能を使用してデータベースファイルを縮小しています。一部のデータベースは50GB以上縮小します。このプロセスの完了には非常に長い時間がかかり、このプロセスの実行中はキャンセルボタンがないことに気付きました。RDPを介してすべてのデータベースサーバーにリモートで接続していますが、トリムプロセス中にそれらのサーバーの電源が入れ直されないことを保証できません。
縮小プロセスが実行されていて、サーバーの電源が入れ直されている場合、データベースが破損しますか？
停電時にどのページが動いていたかに完全に依存すると思います。あなたは大丈夫かもしれませんが、それが私のデータであれば、ここでサイコロを振りたくありません.
1 回の圧縮操作を実行するだけでなく (特に UI を使用する代わりに)、DBCC SHRINKFILEコマンドを使用してファイルを一度に少量ずつ圧縮できます。このオプションではターゲット サイズを設定できるため、短いバーストでコマンドを繰り返し実行できます。
これにより、破損のリスクが軽減されますが、断片化の増加など、他の害を引き起こす可能性があります。最初にインデックスを再構築してから、truncateonly を使用してシュリンクファイルを実行すると、マイレージが向上する場合があります。これにより、再構築によっておそらくすべてのデータがファイルの先頭に向かって一緒に移動された後、ファイルの「末尾」が消去されます。
さらに良い解決策は、独自のファイル グループに 2 番目のデータ ファイルを追加し、すべてのインデックスを新しいファイル グループに再構築してから、プライマリ ファイルを縮小して、そこに存在するシステム/メタデータ オブジェクトのサイズだけに縮小することです。