SQL Serverコミュニティでは、SQL Serverのサービスパック（SP）と累積的な更新プログラム（CU）をインストールする方法についていくつかの論争が続いています。以下に示すように、組織がこの主題に関して通常取る傾向があるいくつかの異なる基本的な立場があります：
- 組織は定期的にサービスパックと累積的な更新をインストールします
- 組織はサービスパックをインストールしますが、累積的な更新はインストールしません
- 組織はサービスパックまたは累積的な更新をインストールしません
最初のケースは、徹底的なテストと実装手順を使用して、SQLServerサービスパックとSQLServer累積更新プログラムの両方を合理的に最新の状態に保とうとする組織です。これは私の意見では最良の方針です。私の立場では、サービスパックと累積的な更新の両方を最新の状態に保つことで、組織のサービスが大幅に向上します（テストと実装の手順、およびそのポリシーをサポートするために必要なインフラストラクチャが整っている場合）。
>2番目のケースは、SQL Server Service Packを（おそらく少し遅れて）インストールする組織ですが、何らかの理由でSQLServer累積更新プログラムをインストールしません。これは最初のケースほど良くはありませんが、3番目のケースよりもはるかに優れています。
3番目のケースでは、組織によっては、理由の如何を問わず、SQLServerサービスパックまたはSQLServer累積的な更新プログラムをインストールしない場合があります。場合によっては、インスタンスの存続期間中、実行しているSQL Serverのメジャーバージョンの元のリリースから製造（RTM）ビルドに実際にとどまります。これは、いくつかの理由から、最も望ましくないポリシーです。
Microsoftには、SQL Serverの特定のバージョンが2つのブランチである場合、コードのブランチ（RTMブランチまたは後続のService Packブランチのいずれか）を廃止するポリシーがあります。たとえば、SQL Server 2008 R2 Service Pack 2がリリースされたとき、元のRTMブランチ（CUレベルに関係なく）は廃止され、「サポートされていないサービスパック」になりました。つまり、そのブランチの修正プログラムや累積的な更新プログラムはなくなり、サポートされているサービスパックをインスタンスにインストールするまで、サポートケース中にMicrosoftCSSから限定的なトラブルシューティングサポートを受けることができます。
SQLServerのメンテナンスが延期される理由
場合によっては、組織は、SQL Serverがサービスパック、累積的な更新プログラム、および修正プログラムの組み合わせで通常どのようにサービスされるかを認識していない可能性があります。多くの組織では、SQL Serverなどの製品の保守とサービスの方法について厳格なトップダウンポリシーを採用しているため、データベース管理者によるSPやCUの定期的なインストールは不可能です。また、特定のベンダー指定のバージョンおよびServicePackレベルのSQLServerでのみベンダーがサポートするサードパーティのデータベースを使用しているため、SQLServerインスタンスのサービスが制限される場合があります。
多くの組織は、SQLServerインスタンスまたはそのインスタンスに依存するアプリケーションのいずれかを「破壊」することを理解できる恐れもあります。また、テスト環境のインスタンスに更新されたSQL Serverビルドをインストールした後、適切なレベルのアプリケーションとシステムのテストを実行するための時間とリソースが不足している可能性があります。場合によっては、専用のテスト環境がないこともあります（これは別の大きな問題です）。
一部の組織では、運用環境に高可用性ソリューション（従来のフェールオーバークラスタリング、データベースミラーリング、可用性グループなど）が導入されていない可能性があるため、原因となる可能性のあるあらゆる種類のサービスを実行することをはるかに躊躇します。データベースサーバーが再起動し、比較的長い停止が発生します。実際には高可用性ソリューションが導入されている可能性がありますが、本番フェイルオーバーでテストすることはめったになく、その機能と信頼性に対する自信が低い可能性があります。
SQLServerを定期的に保守する理由
組織がSQLServerに定期的にサービスを提供しないことを選択する可能性がある一般的な理由のいくつかをリストした後、これらの議論のいくつかに取り組む時が来ました。まず、SQL ServerがMicrosoftによって通常どのようにサービスされているかについての無知は、もはや実際には有効な言い訳ではありません。 MicrosoftにはSQLリリースサービスブログがあり、SQLServerのサービスパックと累積的な更新の両方を発表しています。 Matthias Berntは、彼の投稿でSQL Serverの一般的なサービス戦略について説明しました。サービスパックへの変更されたアプローチと、このMicosoftナレッジベースの記事で利用可能なSQLServerインクリメンタルサービスモデルアプローチの詳細を示します。
サービスモデルの要約バージョンでは、個々のSQLServerの問題が修正プログラムで修正されています。個々の修正プログラムにアクセスするには、Microsoft CSSに連絡してサポートケースを開く必要があります（Microsoft Updateによってプッシュされるセキュリティ関連の修正プログラムでない限り）。 Microsoftでの有料サポートのレベルによっては、これは比較的面倒で時間のかかるプロセスになる可能性があります。また、ほとんどのSQL Serverのお客様は、SQLServer累積更新プログラムの一部としてリリースされていない既存の修正プログラムに気付く可能性が非常に低いという問題もあります。これは、ほとんどのお客様が定期的に個別の修正プログラムを入手して展開する可能性が低いことを意味します。
累積的な更新プログラムは、8週間ごとにリリースされる多数の修正プログラム（通常は約10〜50の修正プログラム）のロールアップです。これらの累積的な更新プログラムは実際には累積的であるため（名前が示すように）、累積的な更新プログラムをインストールすると、コードのバージョンとブランチ（RTM、SP1、SP2など）に対して以前にリリースされたすべての修正プログラムを入手できます。これは、組織が「累積的な更新を適用して、発生している特定の問題を修正するだけである」という一般的な声明は、実際には特に有効ではないことを意味します。
たとえば、SQL Server 2012 Service Pack 1（11.0.3000）のRTMビルドを実行していて、特定の1つの修正プログラムが含まれているためにSQL Server 2012 Service Pack 1 Cumulative Update 3（11.0.3349）をインストールすることにした場合実際に発生した問題では、SP1 CU1、SP1 CU2、およびSP1 CU3のすべての修正プログラムを実際に入手することになり、100をはるかに超える修正プログラムになります。
Microsoftが累積的な更新について述べているように、「ビルドは累積的であるため、新しい修正リリースには、以前のSQL Server 2012SP1修正リリースに含まれていたすべての修正プログラムとすべてのセキュリティ修正が含まれています。この修正プログラムを含む最新の修正リリースの適用を検討することをお勧めします。」基本的に、これは、以前のCUで修正された特定の関連する問題を見つけた場合は、先に進んで最新の関連するCUをシステムに展開する必要があることを意味します（これにはその修正プログラムも含まれます）。
組織が累積的な更新を展開しない理由についてよく耳にする議論の1つは、「サービスパックのように完全に回帰テストされていないため、展開しない」というものです。この観点にはある程度の妥当性がありますが、累積更新は単に単体テストであり、回帰テストはまったく行われないという一般的な誤解もあります。そうではありません。
累積的な更新に関するMicrosoftのドキュメントによると、「開発サイクル全体で増分回帰テストを適用し、その後8週間のリリース期間内に2週間の集中テストを適用するため、CUに関連する品質保証プロセスは個々の修正プログラムの品質保証プロセスを上回ります」。これは、段階的に回帰テストされ、単体テストのみが行われた単一の修正プログラムを展開する場合よりも2週間の集中テストが行われたCUを展開することで、実際にリスクを軽減できることを意味します。
過去6〜7年間、私はSQLServer2005からSQLServer2012を実行している多数のシステムに、多数の累積的な更新プログラムとサービスパックを個人的に展開してきましたが、大きな問題はまだ発生していません。また、この種の作業を行う際の広範な問題がブログやTwitterなどで報告されていることも聞いたことがありません。私（および私が知っているすべての人）が幸運だったか、累積的な更新とサービスパックが完全ではない可能性があります。一部の人々が信じているのと同じくらい危険です（適切にテストして展開する限り）。
テストと実装計画の重要性
システムの存続期間中、サーバーのメンテナンスやアプリケーションの更新を行う予定がない場合を除いて（これはありそうもない提案のようです）、実際には、ある種のテストと実装の手順を開発し、その一部として従う計画を立てる必要があります。サーバーになんらかの変更を加えることです。
この計画は最初は比較的単純かもしれませんが、SQL Serverインスタンスの定期的なサービスの経験を積み、各展開で学んだ教訓を適用するにつれて、より複雑で完全になります。理想的には、システムに変更を加えるときはいつでもこの計画に従うことですが、すべての場合にそれが可能であるとは限りません。
この種の計画に含める必要のあるいくつかの初期手順とテストを次に示します。
- テスト仮想マシンにCUをインストールします
- CUは問題やエラーなしでインストールされますか？
- CUのインストールにはシステムの再起動が必要ですか？
- インストール後に、関連するすべてのSQL Serverサービスが再起動しますか？
- インストール後、SQL Serverは正しく機能しているように見えますか？
- いくつかの開発システムにCUをインストールします
- CUは問題やエラーなしでインストールされますか？
- SQL Serverは、通常の日常の使用中に正しく機能しているように見えますか？
- 単体テスト中にアプリケーションは正しく機能しているように見えますか？
- 共有QAまたは統合環境にCUをインストールします
- インストールの特定の実装計画とチェックリストに従いましたか？
- SQL Serverを使用するすべてのアプリケーションはスモークテストに合格していますか？
- すべてのアプリケーションは、利用可能な自動テストに合格していますか？
- すべてのアプリケーションは、より詳細な手動機能テストに合格していますか？
- 本番環境にCUをインストールします
- 可能な場合はローリングアップグレード戦略を使用します
- 展開中に詳細なステップバイステップのチェックリストを使用します
- 見逃した項目と学んだ教訓でチェックリストを更新する
結論
ここで達成したいと思っているのは、より多くのデータベースプロフェッショナルに、SQL Serverインスタンスを躊躇したり恐れたりするのではなく、実際に定期的にSQLServerインスタンスを維持したいという考え方に移行してもらうことです。これには、組織内の他の人々に計画に参加するよう説得する必要がある場合があるため、最初はかなりの量の余分な作業が必要になる可能性があります。より良いテスト計画を作成するために組織の他の部分をプッシュする必要がある場合があり、実装チェックリストを作成する必要があります。また、メンテナンスウィンドウ（ローリングアップグレードでは比較的短いはずです）の承認をビジネスから取得する必要があります。これにより、実際に定期的に本番システムに更新を展開できます。
この余分な作業の見返りとして、将来問題が発生する可能性が低い、より適切に保守されたシステムが得られます。マイクロソフトが完全にサポートする構成になり、実際に定期的に実行するため、高可用性テクノロジに自信が持てるようになります。また、これらすべての計画と実装を行うことで貴重な経験を積むことができ、将来のトラブルシューティングスキルが向上します。