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

SQL Server 2005、SQL Server 2008、SQL Server 2008 R2、または SQL Server 2012 から SQL Server 2014 にアップグレードするときに、ログ配布構成を保持できます。 このトピックでは、ログ配布構成のアップグレードの複数のシナリオとベスト プラクティスについて説明します。

注意

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

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

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

データを保護するには

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

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

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

監視サーバー インスタンスのアップグレード

監視サーバー インスタンスがある場合、そのインスタンスはいつアップグレードしてもかまいません。

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

単一のセカンダリ サーバーを含むログ配布構成のアップグレード

ここでは、プライマリ サーバーと単一のセカンダリ サーバーから成る構成のアップグレード プロセスについて説明します。 次の図はこの構成を表しています。図の A がプライマリ サーバー インスタンス、B が単一のセカンダリ サーバー インスタンスです。

複数のセカンダリ サーバーのアップグレードについては、このトピックの「 複数のセカンダリ サーバー インスタンスのアップグレード」を参照してください。

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

アップグレード プロセスでは、プライマリ サーバー インスタンスをアップグレードする前に、SQL Server 2005 以降のログ配布構成のセカンダリ サーバー インスタンスを SQL Server 2014 にアップグレードする必要があります。 常にセカンダリ サーバー インスタンスを先にアップグレードします。 セカンダリ サーバーの前にプライマリ サーバーがアップグレードされた場合、新しいバージョンの SQL Server で作成されたバックアップを古いバージョンのSQL Serverに復元できないため、ログ配布は失敗します。

アップグレードされたセカンダリ サーバーは、SQL Server 2005 以降のプライマリ サーバーからログ バックアップを復元し続けるので、ログ配布はアップグレード プロセス全体で続行されます。 セカンダリ サーバー インスタンスのアップグレード プロセスの一部は、ログ配布構成にセカンダリ サーバーが複数あるかどうかによって異なります。 詳細については、このトピックの「 複数のセカンダリ サーバー インスタンスのアップグレード」を参照してください。

セカンダリ サーバー インスタンスをアップグレードしている間はログ配布のコピーと復元のジョブが実行されないため、復元されないトランザクション ログ バックアップが蓄積されていきます。 蓄積される量は、プライマリ サーバーの定期バックアップの頻度に依存します。 また、独立した監視サーバーが構成されている場合は、構成されている間隔を経過しても復元が行われないことを知らせる警告が生成されることがあります。

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

注意

サーバーのアップグレード中、セカンダリ データベースは SQL Server 2014 データベースにアップグレードされません。 データベースのアップグレードが行われるのは、データベースがオンラインになってからです。

重要

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

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

アップグレードの計画では、データベースを使用できなくなる時間が重要な考慮事項になります。 最も単純なシナリオでは、プライマリ サーバーをアップグレードする間、データベースを使用できなくなります (下のシナリオ 1)。

より複雑なアップグレード プロセスでは、元のプライマリ サーバーをアップグレードする前に、SQL Server 2005 以降のプライマリ サーバーを SQL Server 2014 セカンダリ サーバーにフェールオーバーすることで、データベースの可用性を最大化できます (以下のシナリオ 2)。 フェールオーバーのシナリオは 2 種類あります。 1 つは、元のプライマリ サーバーにスイッチ バックして、元のログ配布構成を引き続き使用するシナリオ。 もう 1 つは、元のログ配布構成を削除してから元のプライマリ サーバーをアップグレードし、その後、新しいプライマリ サーバーを使用して新しい構成を作成するシナリオです。 ここでは、この両方のシナリオについて説明します。

重要

必ず、プライマリ サーバー インスタンスをアップグレードする前にセカンダリ サーバー インスタンスをアップグレードしてください。 詳細については、このトピックの「 セカンダリ サーバー インスタンスのアップグレード」を参照してください。

シナリオ 1: フェールオーバーを使用せずにプライマリ サーバー インスタンスをアップグレードする

このシナリオは、フェールオーバーを使用するシナリオより単純ですが、ダウンタイムが長くなります。 プライマリ サーバー インスタンスを単純にアップグレードするため、その間データベースを使用できなくなります。

サーバーのアップグレードが完了すると、データベースが自動的にオンラインに戻り、データベースのアップグレードが行われます。 データベースのアップグレードが完了すると、ログ配布ジョブが再開されます。

シナリオ 2: フェールオーバーを使用してプライマリ サーバー インスタンスをアップグレードする

このシナリオでは、可用性を最大限に高め、ダウンタイムを最小限に抑えることができます。 セカンダリ サーバー インスタンスへの制御されたフェールオーバーを活用して、元のプライマリ サーバー インスタンスをアップグレードする間もデータベースを使用できるようにします。 これにより、プライマリ サーバー インスタンスのアップグレードに要する時間から、フェールオーバーに要する比較的短い時間へと、ダウンタイムを短縮できます。

フェールオーバーを使用してプライマリ サーバー インスタンスをアップグレードするには、セカンダリ サーバーへの制御されたフェールオーバーの実行、元のプライマリ サーバー インスタンスの SQL Server 2014 へのアップグレード、SQL Server 2014 プライマリ サーバー インスタンスでのログ配布の設定の 3 つの一般的な手順が必要です。 ここではこれらの手順について説明します。

重要

セカンダリ サーバー インスタンスを新しいプライマリ サーバー インスタンスとして使用する場合は、ログ配布構成を削除し、 元のプライマリ サーバー インスタンスをアップグレードしてからログ配布 (新しいプライマリから新しいセカンダリへのログ配布) を再構成する必要があります。 詳細については、「ログ配布の削除 (SQL Server)」を参照してください。

手順 1: セカンダリ サーバーへの制御されたフェールオーバーの実行

セカンダリ サーバーへの制御されたフェールオーバー:

1. WITH NORECOVERY を指定して、プライマリ データベースでトランザクション ログの ログ末尾バックアップ を手動で実行します。 このログ バックアップは、まだバックアップされていないログ レコードをキャプチャし、データベースをオフラインにします。 データベースがオフラインの間は、ログ配布バックアップ ジョブは失敗します。

   プライマリ サーバーの AdventureWorks データベースのログ末尾のバックアップを作成する例を次に示します。 バックアップ ファイルの名前は、 Failover_AW_20080315.trnです。

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

   手動で作成したバックアップ ファイルとログ配布バックアップ ジョブによって作成されたバックアップ ファイルを区別できるように、それぞれに異なるファイル名前付け規則を使用することをお勧めします。

2. セカンダリ サーバーで次の手順を実行します。

   1. ログ配布バックアップ ジョブによって自動的に作成されたバックアップがすべて適用されていることを確認します。 どのバックアップ ジョブが適用されているかをチェックするには、モニター サーバーまたはプライマリ サーバーとセカンダリ サーバーでsp_help_log_shipping_monitor システム ストアド プロシージャを使用します。 同じファイルを last_backup_file、 last_copied_file、 およびlast_restored_file列に 一覧表示する必要があります。 コピーおよび復元されていないバックアップ ファイルがあった場合は、ログ配布構成のコピーと復元のエージェント ジョブを手動で呼び出します。

      ジョブの開始については、「 Start a Job」を参照してください。

   2. ステップ 1. で作成した最後のログ バックアップ ファイルを、ファイル共有から、セカンダリ サーバーでログ配布に使用されるローカルの場所にコピーします。

   3. WITH RECOVERY を指定して最後のログ バックアップを復元します。データベースがオンラインになり、 オンライン化の一環として、データベースは SQL Server 2014 にアップグレードされます。

      セカンダリ データベースで AdventureWorks データベースのログ末尾のバックアップを復元する例を次に示します。 この例では WITH RECOVERY オプションが使用されているため、データベースがオンラインになります。

      RESTORE LOG AdventureWorks 
        FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
         WITH RECOVERY;
      GO
      

      注意

      複数のセカンダリ サーバーを含む構成では、他にも注意点があります。 詳細については、このトピックの「 複数のセカンダリ サーバー インスタンスのアップグレード」を参照してください。

   4. 元のプライマリ サーバー (サーバー A) からオンラインのセカンダリ サーバー (サーバー B) にクライアントをリダイレクトして、データベースをフェールオーバーします。

   5. セカンダリ データベースがオンラインになっている間にデータベースのトランザクション ログがいっぱいにならないように注意してください。 そのためには、トランザクション ログをバックアップする必要がある場合もあります。 その場合は、そのバックアップを他のサーバー インスタンスで復元に使用できるように、共有の場所 ( バックアップ共有) にバックアップすることをお勧めします。

手順 2: 元のプライマリ サーバー インスタンスを SQL Server 2014 にアップグレードする

元のプライマリ サーバー インスタンスを SQL Server 2014 にアップグレードした後も、データベースはオフラインで、形式になります。

手順 3: SQL Server 2014 でログ配布を設定する

残りのアップグレード プロセスは、ログ配布がまだ構成されているかどうかによって、次のように異なります。

• SQL Server 2005 以上のログ配布構成を保持している場合は、元のプライマリ サーバー インスタンスに戻ります。 詳細については、このセクションの「 元のプライマリ サーバー インスタンスにスイッチ バックするには」を参照してください。

• フェールオーバーの前にログ配布構成を削除した場合は、元のセカンダリ サーバー インスタンスを新しいプライマリ サーバー インスタンスにする新しいログ配布構成を作成します。 詳細については、このセクションの「 古いセカンダリ サーバー インスタンスを新しいプライマリ サーバー インスタンスとして保持するには」を参照してください。

元のプライマリ サーバー インスタンスにスイッチ バックするには

1. 暫定プライマリ サーバー (サーバー B) で、WITH NORECOVERY を使用してログの末尾をバックアップします。ログ末尾のバックアップが作成され、データベースがオフラインになります。 ログ末尾のバックアップには Switchback_AW_20080315.trnという名前が付けられます。以下に例を示します。

   BACKUP LOG AdventureWorks 
     TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
      WITH NORECOVERY;
   GO
   

2. 暫定プライマリ データベースでトランザクション ログ バックアップ (ステップ 1. で作成したログ末尾のバックアップを除く) を実行した場合は、WITH NORECOVERY を使用してそれらのログ バックアップを元のプライマリ サーバー (サーバー A) 上のオフライン データベースに復元します。 データベースは、最初のログ バックアップが復元されるときに、SQL Server 2014 形式にアップグレードされます。

3. WITH RECOVERY を使用してログ末尾のバックアップ (Switchback_AW_20080315.trn) を元のプライマリ データベース (サーバー A 上) で復元します。データベースがオンラインになります。

4. 元のプライマリ サーバーからオンライン セカンダリ サーバーにクライアントをリダイレクトして、元のプライマリ データベース (サーバー A 上) にスイッチ バックします。

データベースがオンラインになると、元のログ配布構成が再開されます。

古いセカンダリ サーバー インスタンスを新しいプライマリ サーバー インスタンスとして保持するには

古いセカンダリ サーバー インスタンス (B) をプライマリ サーバーとして使用し、古いプライマリ サーバー インスタンス (A) を新しいセカンダリ サーバーとして使用する、新しいログ配布構成を設定します。

重要

プロセスの開始時 (トランザクション ログ バックアップを手動で実行してデータベースをオフラインにする前) に元のプライマリ サーバーから古いログ配布構成が削除されている必要があります。

1. 新しいセカンダリ サーバー (サーバー A) でデータベースの完全なバックアップと復元を行わなくても済むように、新しいプライマリ データベースのログ バックアップを新しいセカンダリ データベースに適用します。 この例の構成で言うと、サーバー B で作成されたログ バックアップをサーバー A のデータベースに復元します。

2. 新しいプライマリ データベース (サーバー B 上) のログをバックアップします。

3. WITH NORECOVERY を使用してログ バックアップを新しいセカンダリ サーバー インスタンス (サーバー A) に復元します。 最初の復元操作では、データベースが SQL Server 2014 に更新されます。

4. 以前のセカンダリ サーバー (サーバー B) をプライマリ サーバー インスタンスとするログ配布を構成します。

   重要

   SQL Server Management Studioを使用する場合は、セカンダリ データベースが既に初期化されていることを指定します。

   詳細については、「ログ配布の構成 (SQL Server)」を参照してください。

5. 元のプライマリ サーバー (サーバー A) からオンラインのセカンダリ サーバー (サーバー B) にクライアントをリダイレクトして、データベースをフェールオーバーします。

   重要

   新しいプライマリ データベースにフェールオーバーするときは、そのデータベースのメタデータと元のプライマリ データベースのメタデータに一貫性があることを確認します。 詳細については、「データベースを別のサーバー インスタンスで使用できるようにするときのメタデータの管理 (SQL Server)」を参照してください。

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

次の図はこの構成を表しています。図の A がプライマリ サーバー インスタンス、B と C がセカンダリ サーバー インスタンスです。

ここでは、フェールオーバーを使用し、その後、元のプライマリ サーバーにスイッチ バックすることでアップグレードする方法について説明します。 フェールオーバーを使用してプライマリ インスタンスをアップグレードする場合、セカンダリ サーバー インスタンスが複数あるとプロセスがより複雑になります。 次の手順では、すべてのセカンダリ サーバーをアップグレードした後、アップグレードしたセカンダリ データベースのいずれかにプライマリ サーバーをフェールオーバーし、 元のプライマリ サーバーをアップグレードした後、元のプライマリ サーバーにログ配布をスイッチ バックします。

重要

常に、セカンダリ サーバー インスタンスをすべてアップグレードしてからプライマリ サーバーをアップグレードします。

フェールオーバーを使用し、その後、元のプライマリ サーバーにスイッチ バックすることでアップグレードするには

1. すべてのセカンダリ サーバー インスタンス (サーバー B およびサーバー C) をアップグレードします。

2. プライマリ データベース (サーバー A 上) で、WITH NORECOVERY を使用してトランザクション ログをバックアップします。トランザクション ログの末尾が取得され、データベースがオフラインになります。

3. フェールオーバー先となるセカンダリ サーバー (サーバー B) で、WITH RECOVERY を使用してログ バックアップを復元します。セカンダリ データベースがオンラインになります。

4. 他のすべてのセカンダリ サーバー (サーバー C) で、WITH NORECOVERY を使用してログ バックアップを復元します。セカンダリ データベースはオフラインのままになります。

   注意

   セカンダリ サーバーではログ配布のコピーと復元のジョブが実行されますが、新しいログ バックアップ ファイルがバックアップ共有に配置されないため、何も行われません。

5. 元のプライマリ サーバー (サーバー A) からオンラインのセカンダリ サーバー (サーバー B) にクライアントをリダイレクトして、データベースをフェールオーバーします。 オンライン データベースが暫定プライマリ サーバーになり、元のプライマリ サーバー (サーバー A) がオフラインになっている間も引き続きデータベースを使用できるようになります。

6. 元のプライマリ サーバー (サーバー A) をアップグレードします。

7. 中間プライマリ データベース (サーバー B) をフェールオーバーしたデータベースで、WITH NORECOVERY を使用してトランザクション ログを手動でバックアップします。 データベースがオフラインになります。

8. 暫定プライマリ データベース (サーバー B 上) で作成したすべてのトランザクション ログ バックアップを、WITH NORECOVERY を使用して他のすべてのセカンダリ データベース (サーバー C 上) に復元します。 これにより、元のプライマリ データベースをアップグレードした後、元のプライマリ データベースからのログ配布を再開する際に、各セカンダリ データベースでデータベースの完全な復元を行う必要がなくなります。

9. WITH RECOVERY を使用して、暫定プライマリ サーバー (サーバー B) のトランザクション ログを元のプライマリ データベース (サーバー A 上) に復元します。

ログ配布の再配置

ログ配布構成を移行するときに上記のいずれの方法も使用したくない場合、プライマリ データベースの完全バックアップおよび復元によってセカンダリ データベースを初期化し直すことで、ログ配布を始めから再配置できます。 使用しているデータベースが小さい場合、またはアップグレード中は高い可用性が必要ない場合、この方法が適しています。

ログ配布を有効にする方法については、「ログ配布の構成 (SQL Server)」を参照してください。

参照

トランザクション ログ バックアップ (SQL Server)トランザクション ログ バックアップの適用 (SQL Server)ログ配布テーブルとストアド プロシージャ