MS SQL Serverの累積的な更新-ベストプラクティス

SQL Serverの累積的な更新の推奨されるベストプラクティスを理解しようとしています。

現在、「CUによって修正された問題が発生した問題でない限り、何もしない」という考えに基づいています。これは「壊れていない場合は修正しない」というアプローチで機能しますが、多くのCUにはパフォーマンスが強化されているので、それが本当に良いアイデアかどうか疑問に思っています。CUがリリースされてから1〜2か月後の定期メンテナンスサイクル中に適用されるパッチに、CUを追加することを検討しています。

他の人は何をしますか、そしてなぜですか？

以下の回答に影響する質問に対する更新として、2016年3月24日、MicrosoftのSQL Serverチームは、サービスモデルを更新すると発表しました。マイクロソフトは、すべてのユーザーが2016年1月以降にリリースされたすべてのCUをインストールすることを推奨しています。

CUの1月のリリース以降、これらの警告メッセージが更新されました。CUが利用可能になったときに、CUを継続的かつ事前にインストールすることをお勧めします。CUのインストールは、SP（サービスパック）がリリースされるときにインストールするのと同じレベルの信頼度で行う必要があります。これは、CUがSPのレベルで認定およびテストされているためです。また、Microsoft CSSデータは、顧客の問題のかなりの部分が、リリースされたCUで以前に対処されていることが多いが、積極的に適用されていないことを示しています。さらに、CUにはホットフィックス以上の付加価値が含まれています。これらには、サポート性、ロギング、信頼性の更新も含まれ、全体的なエクスペリエンスが向上します。

メッセージングとガイダンスの更新に加えて、CU取得モデルも更新しました。

取得の変更：

• もちろん、CUは従来から「Hotfix」サーバーで利用可能になっています（「QFE」または「Hotfix」に関連付けられた「警告言語」を伴う）。ここでの不整合は、CUが本当に単純なクイックホットフィックスではなくなったことです。含まれている更新プログラムは、今日の個人および完全なシステム統合レベルで十分にテストされています。
• したがって、現在サービスパックで行われているのと同様に、メインストリームでサポートされているベースラインごとに最新のCU（2012 SP2 / SP3および2014 RTM / SP1今日）をmicrosoft.com/downloadsに配置しています。
• さらに、取得と配布を容易にするために、すべてのCUをすぐにWindows Updateカタログにリリースして保守します。
• 暫定CUの「オンデマンド」修正のみがホットフィックスサーバーに配置されます。
• 摩擦を減らすために、microsoft.com / downloadsからCUをダウンロードする際に、電子メールとURLを提供/受信する必要はありません
• 現在のサービスパックと同様に、最新のCUをMicrosoft Updateのオプションの更新として提供することも評価しています

私は、最新の累積的な更新を最新の状態に保つことを強く擁護していますが、テスト/ QAサイクルがそれに対する完全かつ適切な回帰テストを確実に行える場合に限ります。SQLskillsの Glenn Berry もこのアプローチの支持者です。

マイクロソフト独自の推奨事項は、影響を与える問題を修正するCUのみを適用することですが、CUは最近そのスタンスを緩めています。問題は、これらの問題の1つ以上に影響を受けてそれを知らない可能性があることです。あるいは、まだ影響を受けていなくても明日影響を受ける可能性があります。ブランチを通過して、ブランチのすべてのCUのすべての修正の背後にある問題を再現しようとしていますか？引き続き影響を受けないようにするために、これを継続的に実行しますか？

私は非常に正直になります。インスタンスにCUを適用するときに問題が発生したことはありません。実際、CUのリリースプロセスは、サービスパックのリリースサイクルよりもはるかに信頼性が高く、多くの場合（最近のSQL Server 2012 Service Pack 2を含む）、最初のサービスパックまでサービスパックを適用したくないとにかく、そのブランチのCUがリリースされました。この場合、サービスパックコードを作成するために時間内に修正されなかった問題を解決するための暫定的な修正プログラムがありますが、常にそうであるとは限りません。

私たちはCUに追いついていました。リリースから約1か月後に、修正された問題が発生しているかどうかに関係なく適用されます。

しかし、大きな問題に遭遇した後、私たちはこの慣行をやめました。今回のケースでは、インストールしたサービスパックによって、発生していたフルテキストインデックス処理の問題が修正されました。数か月後、CUの1つがその特定の修正をロールバックしました。これは私たちにあらゆる種類の問題を引き起こし、何が起こっているのかを理解するためにかなりの調査を必要としました。結局、新しいCUが何か他のものを壊したときに、後で失敗する作業をコーディングしてしまいました...最終結果：サーバーを最初から特定のSP / CUレベルまで再インストールし、フリーズしました。

アプリケーションのパフォーマンスは、今後発生する可能性のある新しいSQLパフォーマンスの向上に関係がないため、問題ではありません。また、レポートやその他のクエリは常に有効な結果を引き出しているため、新しい調整は不要です。これは、現時点でCUの適用を検討する前に、セキュリティの問題でなければならないことを意味します。

私はアーロンに完全に同意します。これは、テスト/ QAサイクルで適切にテストできる場合にのみ行ってください。 そうでない場合は、実際に直面している問題を修正しない限り、明確に対処します。そして、それでも、実際のデータでそのすべての小さな側面をテストして、依存している可能性のあるものを破壊していないことを確認します。