最近、MicrosoftはSQLServer2012用のServicePack1をプッシュし、すぐにServicePack1用のCumulativeUpdate1をフォローアップしました。これは、開発と回帰テストのサイクルが長いため、サービスパックに何も含まれていなかったためです。 RTM Cumulative Updates 3および4からの修正の一部です。多くの人が、現時点ではほとんど推測的なバイアスに基づいて、ServicePack1がリリースされるまでSQLServer2012のテストを開始するのを待っていたので、いくつかをカバーすることが役立つかもしれないと思いました。あなたが遭遇するかもしれないシナリオの。これは厳密にはパフォーマンス関連の投稿ではありませんが、一部の情報にはサービスの中断が含まれており、ビジネスやSLAなどに影響する場合と影響しない場合があります。
更新 – SQL Server 2012 Service Pack 1 Cumulative Update 2（11.0.3339）が2013年1月24日にリリースされました。
SQLServer2012がまだインストールされていない場合…
SQL Serverの新しいインスタンスをインストールするときは、できるだけ少ない手順を実行する必要があります。 SQL Server 2012のセットアップは、SQL Server 2008/2008 R2（Peter Saddowがこことここで説明）よりも、サービスパックと累積的な更新の両方のスリップストリーミングに関してはるかに優れています。このメソッドは非推奨ですが、SQL Server 2012でも引き続きサポートされています。したがって、必要に応じて古いメソッドを引き続き使用できます。
D:\setup.exe /Action=Install /PCUSource=C:\SP1ExtractedFolder /CUSource=C:\CU1ExtractedFolder
使用する必要のある新しい方法ははるかに単純であり、/xを使用してパッケージを手動で抽出する必要はありません。 最初の議論：
D:\setup.exe /Action=Install /UpdateSource=C:\AllUpdatesFolder
関連するすべての更新を同じフォルダに入れる必要があります。ファイル名[...]_zip.exeで取得する更新に注意してください 、コア実行可能ファイルを取得するには、抽出する必要があります。たとえば、ServicePack1とCumulativeUpdate1を最初にダウンロードすると、ダウンロードフォルダは次のようになります。
455715_intl_x64_zip.exeを抽出する必要があります それをダブルクリックして出力パスを選択します（/xを使用） コマンドラインで有効ですが、無視されます）。完了すると、フォルダは次のようになります。 （この時点で、455715...を削除できます。 ファイル–それがどれほど「圧縮」されているかを考えると、そもそもなぜ彼らがこのパッケージを自己解凍型アーカイブに配置し続けるのか疑問に思う必要があります。）
上記のコマンドラインを実行すると、セットアップで[製品の更新]画面が表示され、SP1とCU1の両方が含まれていることがわかります。
Bob Wardは、このシナリオをここでさらに詳しく説明するのに非常に優れています。
CSSブログ：SQLServer2012のセットアップがさらにスマートになりました…
/UpdateSourceを使用する場合は、すべてのサービスパックと累積的な更新を同じフォルダーに保存できることに注意してください。 議論として、SQL Serverセットアップは、そのフォルダーに他に何が存在するかに関係なく、最新のSPとその最新のCUを選択するのに十分賢いでしょう。
SQLServer2012が既にインストールされている場合…
繰り返しになりますが、SQL Serverの新しいインスタンスをインストールする場合は、そのすべての情報が適用されます。一方、パッチを適用したいSQL Server 2012 RTMインスタンスがたくさんあります。累積的な更新プログラム3および4の修正を失いたくなかったので、両方のServicePack1を適用したいと思いました。および累積的な更新プログラム1.同じスリップストリームスマートがServicePack1セットアップ実行可能ファイルに組み込まれ、CU1の更新プログラムを単純に含めることができるようになることを望んでいました。論理を試しました：
C:\AllUpdatesFolder\SQLServer2012-SP1-KB2674319-x64-ENU.exe /UpdateSource=C:\AllUpdatesFolder
しかし、これは最終的に次のエラーを引き起こしました：
検索エンジンの良さについて：
The setting 'UpdateSource' is not allowed when the value of setting 'ACTION' is 'Patch'. Error code 0x84B40005.
（はい、抽出したCU1更新フォルダーを別の場所に配置してみました。）
SP1にはコアsetup.exeのコードとロジックの一部が含まれていることは明らかですが、累積的な更新プログラムを組み込むことができるように構築されていないことをMicrosoftに確認しました。つまり、サービスパックをインストールするときにスリップストリームを実行することはできません。コア製品をインストールするときだけです。
これは、2つのステップでインストールを実行する必要があることも意味します 。スリップストリームは、初期インストール時よりもサービス中の方が間違いなく*価値が高い*ので、新しいConnectの提案を開きました：
接続＃774109：ServicePackインストーラーの/UpdateSourceを許可する
それで、私はこれを2つのステップで実行しました。 Service Pack 1をインストールしましたが、再起動が必要になる可能性のあるファイルが使用されていないことに気付きました。
そして、SP1が完成したら、SP1CU1インストーラーを起動しました。しかし、私はこのエラーに遭遇しました：
したがって、これらのパッチを適用するために2つの手順を実行する必要があっただけでなく、その間に再起動する必要もありました。インストールごとにログファイルを調べました（Detail.txt ）そして、SP1を実行したときに、Windowsが再起動を期待していたという兆候がなかったことがわかります：
(07) 2012-12-12 06:46:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=True
しかし、CU1を実行してエラーが発生したとき、SP1が完了してからわずか数分後に、新しいDetail.txtが表示されました。 これで、Windowsは再起動を*期待*していました：
(07) 2012-12-12 06:53:38 Slp: Windows Update requires a reboot (07) 2012-12-12 06:53:38 Slp: Rule 'RebootRequiredCheck' results: IsRebootNotRequired=False>
ステップ間でWindows Updateを実行しなかったので、何が起こったのかわかりません。
更新：MicrosoftのShau Phangのおかげで、%SystemRoot%\WindowsUpdate.logで発見しました。 自動WindowsUpdateは、SP1の開始後に開始され、CUの更新を開始する前に終了しました。これは、コンピューターを起動して、すぐにサービスパックのインストールを開始したためだと思います。 「再起動する必要があります」チェックは、その間にトリガーされている必要があります。 Windows Updateをオンにしてデフォルトを受け入れたばかりの場合は、これについて全責任を負います。でもやらなかった。これが私の設定です：
ですから、気をつけてください。
結論
話の教訓は、SQL Server 2012をまだインストールしていない場合、スリップストリームを使用して、最新の更新プログラムにいつアクセスできるか、その時点で利用可能な更新プログラムに関係なく、1つのアクションで最新の更新プログラムにアクセスできるようにすることです。シンプルで痛みがないこと。
すでにインスタンスがインストールされている場合、その場合、サービスの中断とダウンタイムは、ほとんどの場合、新規インストール時よりも重大な問題になります。パッチ適用方法に注意深くアプローチし、メンテナンスウィンドウで許可されることを確認する必要があります。サーバーの再起動が必要な場合。これは、次のことも意味します。WindowsUpdateの設定と、最後の再起動以降に更新プログラムがインストールされているかどうかに注意してください。
これが重要な問題であると思われる場合は、これらのConnectアイテムに投票し、さらに重要なことに、現在のシナリオがビジネスにどのように影響するかについてコメントしてください。