SQL Service Packのインストールを検証するとき、どこまで行くのですか？
Service Packを運用SQLサーバーに適用するとき、通常、計画的なダウンタイムウィンドウは約30分です。
以前に噛まれて、パッチのような必要な前提条件が整っていないことを発見した場合、ダウンタイムウィンドウに数分を追加する可能性があり（、ウィンドウを覆ったり、スケジュールを変更したりする可能性があります）。
ここで、更新が計画段階にあるときに、Service Packをサーバーに移動し、「使用中のファイルを確認する」または「更新する準備ができている」ことでテストします。 」その時点で更新をキャンセルし、更新中は、予定されたダウンタイムウィンドウを超えて実行しないことを確信しています。
どちらの画面からでもキャンセルできますが、[更新の準備完了]の[更新]ボタンは[使用中のファイルを確認]の[次へ>]ボタンと同じ場所にあるため、誤ってダブルクリックすると、誤って更新が開始される可能性があります。検証中。
私の質問：
「使用中のファイルを確認」または「更新準備完了」で検証を停止する必要がありますか？ 「使用中のファイルをチェック」の終わりまでに、できることはすべて検証しましたか？ 「更新の準備完了」に進むことで、検証に価値が追加されますか？
「使用中のファイルをチェック」または「更新準備完了」で検証を停止する必要がありますか？ 「使用中のファイルをチェック」の終わりまでに、できることはすべて検証しましたか？
NEXTをクリックしてService Packを適用するだけで、このプロセスを安全に無視できます。チェックfiles in use processは、エンドユーザーがサービスパックの適用後に再起動したくないシナリオを処理するためのものです。その場合、そのようなプロセスをすべて停止する必要がありますが、適用するWindowsマシン/ノードを開始することを強くお勧めします。サービスパック。
起こり得る唯一のことは、アップグレードが成功した後、Windowsマシンを起動する必要があることです。このため、SPが失敗することはありません。
「更新の準備完了」を行うことは、検証に価値をもたらしますか？
更新の準備ができていると、基本的に、更新するすべての機能が表示され、それ以外は何も表示されません。ここでupdateをクリックする必要があります。値は追加されませんが、選択した構成が表示されます。
理想的な状況は、OSやその他のソフトウェアに関して、最初に更新を実行できる実稼働環境と完全に一致するサーバーを用意することです。そうすれば、あなたは知っている必要なすべてのものを知っています。
これは、VMスナップショットできる可能性が高いので、問題が発生して修正した場合は、スナップショットに戻って、更新した手順からやり直すことができます。アップグレード手順が機能するまでこれを繰り返します。再起動の要件などがわかっている場合は、本番環境でプロセスを繰り返すことを計画します。
開発/テスト用のVMの1つは、それらがある場合（つまり、開発/テスト/リリースプロセスが「コードをまとめて、本番環境に直接投入する」だけではない場合）に理想的です。このように、サービスパックは基本的に独自のバグ修正または機能リリースの1つと同じように扱われます。つまり、サービスパックがテスト環境に適用された後、アプリケーションで完全回帰テストを実行できます（MSがアプリケーションが依存する未定義の動作にバグや変更を導入していない-または、コードが依存しているバグを修正していない！）。
明らかに、この「理想」は他のオプションよりも時間がかかる可能性があります...
質問に答えるには、使用中の検証でファイルをスキップできます。続行を妨げることはなく、AFTERWARDSを再起動する必要があるかどうかを通知するだけです。
まだ再起動する必要があり、通知されない状況（通常は.NET Framework関連）が他にもたくさんあるので、何があっても常に再起動します。さらに、今すぐ再起動しないと、次のパックがリリースされたときに、来月それを実行する必要があります。これは、ISパッチブロッカーであるためです。
ただし、1つまたは2つのサーバーにのみパッチを適用している場合でも、部屋の象に対処するには、30分以上の時間を割り当てる必要があります。特にAG/FCI /ミラーリング/レプリケーションおよびエンタープライズ機能がある場合は、60〜120分が適切です。数十台のサーバーがある場合、その段階で部分的に自動化することになるため、それを約4時間に圧縮できます。また、完全に異なる問題ですべてが失敗することはほとんどありません。
さらに時間が必要な理由は、ESXホストで何が起こっているのか、一時的にSANが遅い、またはアップデートのインストールが遅いために最近修正されたとされている2012年のバグがわからないためです。または、どういうわけか最初にAGからSSISDBを削除するのを忘れていましたが、今ではそれがホースであり、修正する必要があります。または、MSがfilestreamでインスタンスを台無しにすることで繰り返し発生する障害により、[プログラムの追加と削除]に移動して、更新を再適用する前に修復を行う必要があります。または、パッチを適用して（ビジー状態のサーバーでは簡単に30分間）、フェイルオーバーしてレプリカを作成した後、AGが同期して戻るのを待つ必要があります。
自動化された基本的なヘルスチェックは何ですか？すべてのAGポリシーチェックを実行するには、サーバーごとに数分かかります。手作業で行う場合はそれ以上です。 DQS MDS SSRS SSASの検証はすべて正常に戻り、愚かなエラーをスローしません。
最初はQAでテストすることは有用ですが、パッチがPRODで失敗したのは何度かあるため、どこかで誰かが何か違うことをしたためだと確信できます。
とにかくリストは無限ではありませんが、それは間違いなく30分以上です。短い時間制限で見積もりを下回っているからといって、災害を修正しようとしている間、時計を見たくないでしょう。私はマネージャーがそれを聞きたがっているのを理解しています-そして私たちはノーと言う必要があるのでDBAが多額の報酬を支払われるのはそのためです。