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

[アーティクル]
06/25/2013

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

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

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

このトピックの内容

アップグレード前のデータの保護
監視サーバーインスタンスのアップグレード
単一のセカンダリサーバーを含むログ配布構成のアップグレード
複数のセカンダリサーバーインスタンスのアップグレード
ログ配布の再配置

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

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

データを保護するには

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

詳細については、「データベースの完全バックアップの作成 (SQL Server)」を参照してください。
すべてのプライマリデータベースで DBCC CHECKDB コマンドを実行します。

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

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

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

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

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

セカンダリサーバーが 1 台で、監視サーバーはなし

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

このセクションの内容

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

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

このアップグレードプロセスでは、SQL Server 2005、SQL Server 2008、または SQL Server 2008 R2 ログ配布構成のセカンダリサーバーインスタンスを SQL Server 2012 にアップグレードしてからプライマリサーバーインスタンスをアップグレードします。常にセカンダリサーバーインスタンスを先にアップグレードします。セカンダリサーバーより先にプライマリサーバーをアップグレードすると、ログ配布が失敗します。これは、新しいバージョンの SQL Server で作成されたバックアップを古いバージョンの SQL Server で復元することはできないためです。

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

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

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

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

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

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

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

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

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

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

このセクションの内容

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

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

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

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

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

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

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

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

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

このセクションの内容

手順 1: セカンダリサーバーへの制御されたフェールオーバーの実行
手順 2: 元のプライマリサーバーインスタンスの SQL Server 2012 へのアップグレード
手順 3: SQL Server 2012 でのログ配布の設定

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

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

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

プライマリサーバーの AdventureWorks データベースのログ末尾のバックアップを作成する例を次に示します。バックアップファイルの名前は、Failover_AW_20080315.trn です。
```
BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
   WITH NORECOVERY;
GO
```
手動で作成したバックアップファイルとログ配布バックアップジョブによって作成されたバックアップファイルを区別できるように、それぞれに異なるファイル名前付け規則を使用することをお勧めします。

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

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

ジョブの開始については、「ジョブの開始」を参照してください。
ステップ 1. で作成した最後のログバックアップファイルを、ファイル共有から、セカンダリサーバーでログ配布に使用されるローカルの場所にコピーします。

WITH RECOVERY を指定して最後のログバックアップを復元します。データベースがオンラインになり、その過程で SQL Server 2012 にアップグレードされます。

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

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

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

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

手順 2: 元のプライマリサーバーインスタンスの SQL Server 2012 へのアップグレード

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

手順 3: SQL Server 2012 でのログ配布の設定

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

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

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

暫定プライマリサーバー (サーバー B) で、WITH NORECOVERY を使用してログの末尾をバックアップします。ログ末尾のバックアップが作成され、データベースがオフラインになります。ログ末尾のバックアップには Switchback_AW_20080315.trn という名前が付けられます。以下に例を示します。
```
BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
   WITH NORECOVERY;
GO
```
暫定プライマリデータベースでトランザクションログバックアップ (ステップ 1. で作成したログ末尾のバックアップを除く) を実行した場合は、WITH NORECOVERY を使用してそれらのログバックアップを元のプライマリサーバー (サーバー A) 上のオフラインデータベースに復元します。最初のログバックアップが復元されるときにデータベースが SQL Server 2012 形式にアップグレードされます。
WITH RECOVERY を使用してログ末尾のバックアップ (Switchback_AW_20080315.trn) を元のプライマリデータベース (サーバー A 上) で復元します。データベースがオンラインになります。
元のプライマリサーバーからオンラインセカンダリサーバーにクライアントをリダイレクトして、元のプライマリデータベース (サーバー A 上) にスイッチバックします。

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

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

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

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

新しいセカンダリサーバー (サーバー A) でデータベースの完全なバックアップと復元を行わなくても済むように、新しいプライマリデータベースのログバックアップを新しいセカンダリデータベースに適用します。この例の構成で言うと、サーバー B で作成されたログバックアップをサーバー A のデータベースに復元します。
新しいプライマリデータベース (サーバー B 上) のログをバックアップします。
WITH NORECOVERY を使用してログバックアップを新しいセカンダリサーバーインスタンス (サーバー A) に復元します。最初の復元操作により、データベースが SQL Server 2012 に更新されます。
以前のセカンダリサーバー (サーバー B) をプライマリサーバーインスタンスとするログ配布を構成します。

重要

SQL Server Management Studio を使用する場合は、セカンダリデータベースを初期化済みとして指定します。

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

重要
SQL Server Management Studio を使用する場合は、セカンダリデータベースを初期化済みとして指定します。

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

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

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

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

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

セカンダリサーバーが 2 台で、監視サーバーはなし

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

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

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

すべてのセカンダリサーバーインスタンス (サーバー B およびサーバー C) をアップグレードします。
プライマリデータベース (サーバー A 上) で、WITH NORECOVERY を使用してトランザクションログをバックアップします。トランザクションログの末尾が取得され、データベースがオフラインになります。
フェールオーバー先となるセカンダリサーバー (サーバー B) で、WITH RECOVERY を使用してログバックアップを復元します。セカンダリデータベースがオンラインになります。

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

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

元のプライマリサーバー (サーバー A) からオンラインのセカンダリサーバー (サーバー B) にクライアントをリダイレクトして、データベースをフェールオーバーします。オンラインデータベースが暫定プライマリサーバーになり、元のプライマリサーバー (サーバー A) がオフラインになっている間も引き続きデータベースを使用できるようになります。
元のプライマリサーバー (サーバー A) をアップグレードします。
先ほどフェールオーバーしたデータベース (サーバー B 上の暫定プライマリデータベース) で、WITH NORECOVERY を使用してトランザクションログを手動でバックアップします。データベースがオフラインになります。
暫定プライマリデータベース (サーバー B 上) で作成したすべてのトランザクションログバックアップを、WITH NORECOVERY を使用して他のすべてのセカンダリデータベース (サーバー C 上) に復元します。これにより、元のプライマリデータベースをアップグレードした後、元のプライマリデータベースからのログ配布を再開する際に、各セカンダリデータベースでデータベースの完全な復元を行う必要がなくなります。
WITH RECOVERY を使用して、暫定プライマリサーバー (サーバー B) のトランザクションログを元のプライマリデータベース (サーバー A 上) に復元します。

ログ配布の再配置

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

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

Share via

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

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

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

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

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

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

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

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

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

手順 2: 元のプライマリサーバーインスタンスの SQL Server 2012 へのアップグレード

手順 3: SQL Server 2012 でのログ配布の設定

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

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

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

ログ配布の再配置

関連項目

概念

その他のリソース

Share via

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

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

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

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

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

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

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

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

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

手順 2: 元のプライマリ サーバー インスタンスの SQL Server 2012 へのアップグレード

手順 3: SQL Server 2012 でのログ配布の設定

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

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

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

ログ配布の再配置

関連項目

概念

その他のリソース

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

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

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

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

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

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

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

手順 2: 元のプライマリサーバーインスタンスの SQL Server 2012 へのアップグレード

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

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

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