SQL Server 2016 へのログ配布のアップグレード (Transact-SQL)

  • [アーティクル]

適用対象:SQL Server

ログ配布のディザスター リカバリー ソリューションを保持するには、適切な順序でサービス更新プログラムをアップグレードするか、適用します。 サービス更新プログラムには、サービス パックまたは累積的な更新プログラムが含まれます。

Note

バックアップの圧縮 は SQL Server 2008 (10.0.x) Enterpriseで導入されました。 アップグレードされたログ配布構成では、 バックアップの圧縮の既定 サーバー レベル構成オプションを使用して、トランザクション ログ バックアップ ファイルにバックアップ圧縮を使用するかどうかを制御します。 ログ バックアップのバックアップ圧縮動作は、ログ配布構成ごとに指定できます。 詳細については、「ログ配布の構成 (SQL Server)」を参照してください。

このトピックの内容

前提条件

作業を開始する前に、次の重要な情報を確認してください。

アップグレード前のデータの保護

ログ配布のアップグレードを行う前にデータを保護することをお勧めします。

データを保護するには

  1. すべてのプライマリ データベースを対象にデータベースの完全バックアップを実行します。

    詳細については、「 データベースの完全バックアップの作成 (SQL Server)」を参照してください。

  2. すべてのプライマリ データベースで DBCC CHECKDB コマンドを実行します。

重要

セカンダリのアップグレードで見込まれる時間内はログのバックアップ コピーが保持されるように、プライマリ サーバーに十分な領域があることを確認します。 セカンダリにフェールオーバーする場合は、同じ問題がセカンダリ (新しいプライマリ) にも適用されます。

(省略可能な) 監視サーバー インスタンスのアップグレード

監視サーバー インスタンスがある場合、そのインスタンスはいつアップグレードしてもかまいません。 ただし、プライマリとセカンダリ サーバーをアップグレードするときに、省略可能な監視サーバーをアップグレードする必要はありません。

監視サーバーのアップグレード中もログ配布構成は引き続き機能しますが、その状態は監視テーブルに記録されません。 また、監視サーバーをアップグレードしている間は、構成されている警告がトリガーされません。 アップグレードの完了後、sp_refresh_log_shipping_monitor システム ストアド プロシージャを実行して監視テーブルの情報を更新できます。 監視サーバーの詳細については、「ログ配布について (SQL Server)」を参照してください。

セカンダリ サーバー インスタンスのアップグレード

このアップグレード プロセスでは、SQL Server のセカンダリ サーバー インスタンスをアップグレードしてからプライマリ サーバー インスタンスをアップグレードします。 常にセカンダリの SQL Server インスタンスを最初にアップグレードしてください。 アップグレードされたセカンダリ サーバー インスタンスでは引き続きプライマリ サーバー インスタンスからログ バックアップの復元が行われるため、アップグレード プロセスの間もログ配布は継続されます。 セカンダリ サーバー インスタンスより先にプライマリ サーバー インスタンスをアップグレードすると、ログ配布が失敗します。これは、新しいバージョンの SQL Server で作成されたバックアップを古いバージョンの SQL Serverで復元することはできないためです。 セカンダリ インスタンスは同時にアップグレードすることも、順番にアップグレードすることもできますが、ログ配布のエラーを避けるため、プライマリ インスタンスのアップグレード前にすべてのセカンダリ インスタンスをアップグレードする必要があります。

セカンダリ サーバー インスタンスをアップグレードしている間はログ配布のコピーと復元のジョブは実行されません。 つまり、復元されていないトランザクション ログのバックアップがプライマリに蓄積されるため、その復元されていないバックアップを保持するための十分な領域が必要です。 蓄積される量は、プライマリ サーバー インスタンスでスケジュールされているバックアップの頻度と、セカンダリ インスタンスをアップグレードする順序によって異なります。 また、独立した監視サーバーが構成されている場合は、構成されている間隔を経過しても復元が行われないことを知らせる警告が生成されることがあります。

セカンダリ サーバー インスタンスのアップグレードが完了すると、ログ配布エージェント ジョブが再開され、引き続きプライマリ サーバー インスタンスのログ バックアップがセカンダリ サーバー インスタンスにコピーおよび復元されます。 セカンダリ サーバー インスタンスでセカンダリ データベースが最新の状態になるまでにかかる時間は、セカンダリ サーバー インスタンスのアップグレードにかかった時間とプライマリ サーバーのバックアップの頻度に依存します。

注意

サーバー アップグレードの過程では、セカンダリ データベース自体は新しいバージョンにアップグレードされません。 ログ配布済みデータベースのフェールオーバーを開始してオンラインになるとアップグレードされます。 理論上は、この状況は無限に続きます。 フェールオーバーが開始され、データベースのメタデータのアップグレードにかかる時間はわずかです。

重要

アップグレードが必要なデータベースに対しては RESTORE WITH STANDBY オプションはサポートされません。 アップグレードされたセカンダリ データベースが RESTORE WITH STANDBY を使用して構成されている場合、アップグレード後にトランザクション ログを復元できなくなります。 そのセカンダリ データベースでのログ配布を再開するには、そのスタンバイ サーバーでもう一度ログ配布を設定する必要があります。 STANDBY オプションの詳細については、「トランザクション ログ バックアップの復元 (SQL Server)」を参照してください。

プライマリ サーバー インスタンスのアップグレード

ログ配布は主にディザスター リカバリー ソリューションであるため、最も単純で一般的なシナリオは、プライマリ インスタンスを適切にアップグレードすることです。データベースはこのアップグレード中は使用できなくなります。 サーバーのアップグレードが完了すると、データベースが自動的にオンラインに戻り、データベースのアップグレードが行われます。 データベースのアップグレードが完了すると、ログ配布ジョブが再開されます。

注意

ログ配布では、ログ配布のセカンダリへのフェールオーバー (SQL Server) のオプションもサポートしています。また、プライマリ ログ配布サーバーとセカンダリ ログ配布サーバー間でのロールの変更 (SQL Server) もできます。 ただし、ログ配布が高可用性ソリューションとして構成されることは今後ほとんどないため (新しいオプションの方が堅牢性がかなり高い)、フェールオーバーでは通常ダウンタイムが最小化されません。フェールオーバーではシステム データベース オブジェクトが同期されず、昇格したセカンダリを見つけて接続しやすくするためのクライアントを有効にする方が難しいためです。

参照

インストール ウィザードを使用した SQL Server 2016 へのアップグレード (セットアップ)
コマンド プロンプトからの SQL Server 2016 のインストール
ログ配布の構成 (SQL Server)
ログ配布の監視 (Transact-SQL)
ログ配布テーブルとストアド プロシージャ