SQL Server サポートチーム
佐藤 美菜
SSIS パッケージの管理を行う SSISDB カタログデータベースは、他のユーザーデータベースと同様に AlwaysOn 可用性グループに設定することができます。 しかし、SQL Server のサービスパックや累積的更新プログラム適用時には注意が必要です。
事象
SQL Server 2012 もしくは SQL Server 2014 AlwaysOn 可用性グループを構成している環境で、 SSISDB カタログデータベースも可用性グループに入っている場合にサービスパックや累積的更新プログラムを適用すると、エラーで失敗する���とがあります。
インストール結果が記録される Summary.txt や、ERRORLOG では、次のようなエラーが記録されます。
Summary.txt
(SQL Server 2012 の場合、既定で C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log 配下)
Overall summary: Final result: 修正プログラムのインストール中に次のインスタンスの更新に失敗しました: MSSQLSERVER。失敗の原因を確認するには、ログ ファイルを参照してください。 Exit code (Decimal): -2061893606 Start time: 2015-07-16 03:25:23 End time: 2015-07-16 04:08:05 Requested action: Patch |
ERRORLOG
(SQL Server 2012 の場合、既定で C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Log 配下)
2015-07-16 04:05:30.37 spid5s Error: 912, Severity: 21, State: 2. 2015-07-16 04:05:30.37 spid5s Script level upgrade for database 'master' failed because upgrade step 'SSIS_hotfix_install.sql' encountered error 945, state 2, severity 25. This is a serious error condition which might interfere with regular operation and the database will be taken offline. If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting. Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion. 2015-07-16 04:05:30.40 spid5s Error: 3417, Severity: 21, State: 3. 2015-07-16 04:05:30.40 spid5s Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information about how to rebuild the master database, see SQL Server Books Online. |
原因
SSISDB が AlwaysOn 可用性グループに含まれていることが原因です。
SQL Server のサービスパックや累積的更新プログラムを適用後、SQL Server 起動時にスクリプト アップグレードが行われます。スクリプト アップグレード実行時は、シングルユーザーモードで SQL Server が起動されますが、AlwaysOn 可用性グループはシングルユーザーモードでは動作しません。 AlwaysOn 可用性グループに含まれるデータベースはAlwaysOn 可用性グループによりオンラインにされるため、シングルユーザーモードでは、AlwaysOn 可用性グループに含まれるデータベースはオンラインにならず、アクセスできません。 その結果、SSISDB カタログデータベースが可用性グループに入っている SQL Server インスタンスに対して、SSISDB カタログデータベースの更新が含まれている修正プログラムを適用すると、スクリプトを実行することができず、インストールが失敗します。
※ AlwaysOn 可用性グループのプライマリレプリカ、セカンダリレプリカ、いずれのレプリカをホストしている SQL Server インスタンスでのインストールも失敗します。
※ SQL Server 2012 SP1、SQL Server 2012 SP2 には、SSISDBへの更新が含まれているため、インストールに失敗します。累積的更新プログラム(CU) でも SSISDBへの更新が含まれているバージョンではインストールに失敗しますが、SSISDBへの更新が含まれていないバージョンの場合にはインストールに成功します。
※ スクリプト アップグレードでは、サービスパック等により行われた master データベース内のシステム ストアドプロシージャやシステム テーブルの一部が更新されます。上記の SQL Server 2012 SP2 の適用例では、SSISDB への修正が含まれており、SSISDB への更新も行われます。
対処
修正プログラム適用で一度エラーになった環境で再度修正プログラムを適用する際の対処と、初めて修正プログラムを適用する場合に事前に問題を発生させないための対処で、手順が異なります。
修正プログラム適用で一度エラーになった環境で再度修正プログラムを適用する際の対処
1. 修正プログラム適用でエラーになったサーバーで、[SQL Server 構成マネージャー] を起動し、対象の SQL Server インスタンスの [プロパティ] を表示します。[起動時のパラメーター] タブから、パラメーター 「-T902」を追加します。
-T902(トレースフラグ902)は、SQL Server 起動時にスクリプトを実行しないためのパラメーターです。これにより、エラーとなった SQL Server でも起動させることができます。
2. SQL Server インスタンスを開始します。
3. AlwaysOn 可用性グループのプライマリレプリカで、SSISDB をAlwaysOn 可用性グループから削除します。
4. 旧セカンダリでは SSISDBが復旧中の状態になるため、SSISDBを削除します。
5. 再度、[SQL Server 構成マネージャー] から、「1.」で追加した起動時のパラメーター 「-T902」を削除します。
-T902を削除して、[適用] をクリックすると、次のような警告が表示されます。この後の手順のサービスパックや累積的更新プログラム適用時に自動的にサービスが停止、再開されますので、ここではサービス再起動は不要です。
6. AlwaysOn 可用性グループの各サーバーで、サービスパックや累積的更新プログラムを適用します。
※ 他のAlwaysOn 可用性グループが動作している場合には、ダウンタイムを最小限に抑えるために下記も考慮します。
ダウンタイムとデータ損失を最小限に抑えた可用性グループ サーバーのアップグレードおよび更新
7. すべてのサーバーで適用完了後、旧プライマリで SSISDB が存在しているサーバーから、再度SSISDBをAlwaysOn 可用性グループに追加します。
[可用性グループへのデータベースの追加] では、SSISDBを選択します。
AlwaysOn 可用性グループに、SSISDBが追加されます。
初めて修正プログラムを適用する場合に事前に問題を発生させないための対処
1. AlwaysOn 可用性グループのプライマリレプリカで、SSISDB をAlwaysOn 可用性グループから削除します。
2. 旧セカンダリでは、SSISDBが復旧中の状態になるため、SSISDBを削除します。
3. AlwaysOn 可用性グループの各サーバーで、サービスパックや累積的更新プログラムを適用します。
※ 他のAlwaysOn 可用性グループが動作している場合には、ダウンタイムを最小限に抑えるために下記も考慮します。
ダウンタイムとデータ損失を最小限に抑えた可用性グループ サーバーのアップグレードおよび更新
4. すべてのサーバーで適用完了後、旧プ���イマリで SSISDB が存在しているサーバーから、再度SSISDBをAlwaysOn 可用性グループに追加します。
[可用性グループへのデータベースの追加] では、SSISDBを選択します。
AlwaysOn 可用性グループに、SSISDBが追加されます。
補足
SQL Server 2012、SQL Server 2014で、この事象は発生します。次期バージョンの SQL Server 2016 ではこの事象は改善されており、発生しません。