MS SQLサーバーを正しく再起動する方法、それを行うためのベストプラクティスは何ですか？
私はDB管理に非常に慣れていません。
SQLサーバーを再起動すると問題が発生し、データベースの1つがRecoveryモードになり、30分で自動的にDBを修復します。これがなぜ起こるか私は知りません。
これが私がしたことですが、それは十分ではないようです：
SQL Server Microsoft SQL Server 2014（SP2-GDR）を持っています。
- windowsアップデートをインストールする
- SQL：すべてのDBとログファイルを圧縮する
- SQL：すべてのランタイムブロックを強制終了 `oв
- SQL：SQLエージェントを停止しました
- SQL：SQLサーバーを停止しました
- Windows Serverを再起動します。
更新しました ：
1）データベースの大きさは？
4.5 GB + 400MBログ
2）なぜインスタンスを再起動するのですか？ Windowsの更新プログラムをインストールすると、そのSQLサーバーに接続するアプリも時間の経過とともに徐々に遅くなります。通常、月1回サーバーを再起動します。開始には15分かかりますが、今回は45分かかりました（DBの回復中）。
3）これはサーバーですか、それとも疑似サーバー（サーバーOSを実行しているデスクトップ）ですか？
その仮想マシン。サーバーハードウェア上で実行。
4）サーバーはアプリケーションまたはバックグラウンドプロセス用に構成されていますか？
サーバーはSQLおよび追加のバックグラウンドアプリ/ Webサービスを実行します
5）どのくらいRAMサーバーにありますか？プロセッサの数は？
16 GB RAM 4 CPU
6）SANストレージまたはローカルディスク？....詳細を提供するほど、適切な回答を提供できます。
ホスティングをサービスとして購入していますが、正確なハードウェアアーキテクチャを特定することはできません。しかし、SSDディスク（SQL DBが格納されている場所）があります。
7）30分は、SQL Serverが実行できる最善の方法です。それは多くの要因に依存します。
通常15分ほどかかります。正しい方法ですべてのDBを閉じるために必要ないくつかの手順が欠けていると思います。
問題のデータベースの問題のあるログファイルに、非常に多くの仮想ログファイル（VLF）が存在することはほぼ確実です。 SQL Serverをシャットダウンして再起動すると、インスタンス上のすべてのデータベースでリカバリプロセスが実行されます。 VLFの数が非常に多いデータベースの場合、このプロセスは非常に遅くなる可能性があります。
次のDBCCコマンドを使用してVLFを表示できます。
DBCC LOGINFO;
各行は1つのVLFを表します。いくつ持っていますか？ VLF（行）の数が非常に多いと思います。
ログファイルを再構築して、余分なVLFを削除できます。単にログファイルを圧縮してから、適切な増分で以前のサイズに拡張します。
その方法を示すブログ投稿を書きました here 。
リカバリを実行せずにSQL Serverインスタンスをシャットダウンする必要がある場合は、SQL Serverをシャットダウンする前に次のコマンドを発行できます。
shutdown;
ただし、既存の接続がある場合、コマンドはすべての接続が閉じるまで待機します。詳細は Microsoft docs を参照してください。 SHUTDOWN WITH NOWAIT;は、既存の接続が閉じるのを待たずにSQL Serverを即座にシャットダウンしますが、これは次の起動時に回復をトリガーします。これは、コントロールパネルまたはサーバー自体のシャットダウンによってインスタンスをシャットダウンしたときに発生します。 。
シャットダウンする前に、データベースの使用を必ず停止してください。
これにより、データベースが不適切な方法でシャットダウンされた場合、起動時にロールバック/転送するトランザクションの量が大幅に削減されます。
通常、これは、データベース自体をシャットダウンする前に、データベースを使用するアプリケーションをシャットダウンすることによって行われます。
これが完了したら、最初にshutdown;を使用してインスタンスをシャットダウンしてください。それが機能していない場合は、おそらくインスタンスでいくつかのセッションがハングしています。それらを強制終了するか、shutdown with nowait;を使用すると、起動時にインスタンスが回復します。
ロールバック/転送するトランザクションの量が多くなく、起動時に大きな回復時間がまだ発生する場合。
大量の仮想ログファイルが原因である可能性があります。
トランザクションログファイルを縮小して適切なサイズに設定し直すことで、これらを減らすことができます。その後、小さな部分ではなく、毎回十分なサイズだけ大きくなるようにパラメータ化します。
SQL Server 2019：
SQL Server 2019を使用している場合は、SQLデータベースエンジンの回復プロセスを再設計して、ADR（加速データベース回復）を使用するように設計することもできます（前のソリューションがどれも機能しなかった場合 -）。
参照：
[ADR]