MSDBの縮小を止めても安全ですか？
運用サーバー（Microsoft SQL Server 2014）では、ファイルMSDBData.mdf 450 GB以上に膨れ上がり、サーバー内のほぼすべてのスペースを消費しました（残り38 GBのみ）。
まず、ネットワーク共有上にMSDBのバックアップを作成しました（SSMS->アクティビティ->バックアップ経由）。次に、ファイルのサイズを縮小しようとしましたが（SSMS->アクティビティ->縮小->ファイルを使用）、縮小が停止し、ディスク領域が解放されていません。縮小するダイアログウィンドウは数時間からフリーズします。
SSMSのアクティビティ監視では、縮小を監視しているプロセスではSUSPENDEDステータスになっているように見えます。
イベントビューアにはいくつかのイベントがあります
つまり.
(source MSSQLSERVER, eventid 847) beginning with
1. Time-out occurred while waiting for latch: class 'FGCB_ADD_REMOVE'
2. Time-out occurred while waiting for latch: class 'FCB'
質問：さらに調査を行うために、SSMSのダイアログウィンドウを閉じてMSDBの縮小を停止しても安全ですか？
はい、その操作をキャンセルしても安全です（ただし、辛抱強くロールバックを終了する必要があります。パニックに陥ってSQL Serverサービスを停止したり、サーバーを再起動したりしないでください。ロールバックを最初からやり直すだけです）。
待っている間に、根本的な問題に対処しましょう。
より多くのデータを準備するために手動でサイズを増やす（または他の誰かがデータを取得する前にスペースを少しずつ取得する）シナリオ以外では、データを追加したためにデータファイルのサイズが大きくなりますファイルに追加しましたが、そのデータを保存するのに十分な大きさではありませんでした。より多くのデータを収容するために拡大する必要があったファイルを縮小するようにSQLServerに指示すると、最初に拡大の原因となったデータの一部を削除しない限り、何も達成されない可能性があります。
これは、毎秒実行され、バックアップ履歴テーブルを埋めている不正なバックアップジョブ（おそらくサードパーティ）からのものである可能性があります。または、ジョブ履歴を生成し、そのテーブルをエラーで埋めているジョブ実行アモック。または、データベースのメールテーブルをジャンクで埋める無限ループ。または、特に独自のプロセスのユーザーテーブルをmsdbに配置した場合は、他にも何十もあります。
スペースを占有しているものを見つけるには、 このようなクエリ および このような別のクエリ （他にも多数存在します）を使用できます。断片化、大量のLOBデータ、または本当に悪い fill factor 、またはサイズが大きすぎるが過少な固定幅の列、または行数が多いために、テーブルが巨大である可能性があります。しかし、縮小する前に、これを見つけてクリアする必要があります。
不要になったデータを削除します（そして、実行したプロセスが再び実行されないようにするために必要な手順を実行します）。適切なフィルファクターでインデックスを再構築し、インデックスを管理するための何らかのメンテナンスルーチン（ Olaのスクリプト など）を設定し、msdbデータベース（またはすべて）のファイル増加イベントが多すぎる場合のアラートデータベース）なので、この問題を早期に発見できます。たとえば、 デフォルトのトレース を使用して、最近発生したすべてのファイル増加イベントを確認できます。
次に、_DBCC SHRINKFILE_を使用します（SSMSのUIの不自然さ、または_DBCC SHRINKDATABASE_はログを縮小しようとし、すべてを一度に縮小しようとします）、ファイルサイズを元に戻すために、一度に少しずつ。ファイルが現在450GBで、300 GBを解放した場合（上記の結果を確認するには_sp_spaceused_を使用できます）、たとえば（将来の拡張の余地を残して）200GBのファイルになります。 、最初に425 GB、次に400 GB、次に375 GBなどに縮小することにより、...の機能に応じて、一度に2GBまたは5GBから開始するなど、より小さなチャンクでそれを行う必要がある場合があります。基盤となるディスクサブシステム。