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

適用対象: ○SQL Server XAzure SQL Database XAzure SQL Data Warehouse XParallel Data WarehouseAPPLIES TO: yesSQL Server noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

SQL ServerSQL Server ログ配布構成を新しい SQL Server 2017SQL Server 2017 バージョン、新しい SQL ServerSQL Server サービス パック、または SQL ServerSQL Server の累積的な更新プログラムにアップグレードする場合、適切な順序でログ配布サーバーをアップグレードすることで、ログ配布のディザスター リカバリー ソリューションが保持されます。When upgrading from a SQL ServerSQL Server log shipping configuration to a new SQL Server 2017SQL Server 2017 version, a new SQL ServerSQL Serverservice pack, or a SQL ServerSQL Servercumulative update, upgrading your log shipping servers in the appropriate order will preserve your log shipping disaster recovery solution.

注意

バックアップの圧縮SQL Server 2008 EnterpriseSQL Server 2008 Enterpriseで導入されました。Backup compression was introduced in SQL Server 2008 EnterpriseSQL Server 2008 Enterprise. アップグレードされたログ配布構成では、 バックアップの圧縮の既定 サーバー レベル構成オプションを使用して、トランザクション ログ バックアップ ファイルにバックアップ圧縮を使用するかどうかを制御します。An upgraded log shipping configuration uses the backup compression default server-level configuration option to control whether backup compression is used for the transaction log backup files. ログ バックアップのバックアップ圧縮動作は、ログ配布構成ごとに指定できます。The backup compression behavior of log backups can be specified for each log shipping configuration. 詳細については、「 ログ配布の構成 (SQL Server)で導入されました。For more information, see Configure Log Shipping (SQL Server).

このトピックの内容In This Topic:

前提条件Prerequisites

作業を開始する前に、次の重要な情報を確認してください。Before you begin, review the following important information:

アップグレード前のデータの保護Protect Your Data Before the Upgrade

ログ配布のアップグレードを行う前にデータを保護することをお勧めします。As a best practice, we recommend that you protect your data before a log shipping upgrade.

データを保護するにはTo protect your data

  1. すべてのプライマリ データベースを対象にデータベースの完全バックアップを実行します。Perform a full database backup on every primary database.

    詳細については、データベースの完全バックアップの作成 データベースの完全バックアップの作成 (SQL Server)を使用してデータベースの差分バックアップを作成します。For more information, see Create a Full Database Backup (SQL Server).

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

重要

セカンダリのアップグレードで見込まれる時間内はログのバックアップ コピーが保持されるように、プライマリ サーバーに十分な領域があることを確認します。Ensure that you have sufficient space on your primary server to hold the log backup copies for as long as the upgrade of the secondaries is expected to take. セカンダリにフェールオーバーする場合は、同じ問題がセカンダリ (新しいプライマリ) にも適用されます。If you are failing over to a secondary, this same concern applies to the secondary (the new primary).

(省略可能な) 監視サーバー インスタンスのアップグレードUpgrading the (Optional) Monitor Server Instance

監視サーバー インスタンスがある場合、そのインスタンスはいつアップグレードしてもかまいません。The monitor server instance, if any, can be upgraded at any time. ただし、プライマリとセカンダリ サーバーをアップグレードするときに、省略可能な監視サーバーをアップグレードする必要はありません。However, you do not need to upgrade the optional monitor server when you upgrade the primary and secondary servers.

監視サーバーのアップグレード中もログ配布構成は引き続き機能しますが、その状態は監視テーブルに記録されません。While the monitor server is being upgraded, the log shipping configuration continues to work, but its status is not recorded in the tables on the monitor. また、監視サーバーをアップグレードしている間は、構成されている警告がトリガーされません。Any alerts that have been configured will not be triggered while the monitor server is being upgraded. アップグレードの完了後、sp_refresh_log_shipping_monitor システム ストアド プロシージャを実行して監視テーブルの情報を更新できます。After the upgrade, you can update the information in the monitor tables by executing the sp_refresh_log_shipping_monitor system stored procedure. 監視サーバーの詳細については、「ログ配布について (SQL Server)」を参照してください。For more information about a monitor server, see About Log Shipping (SQL Server).

セカンダリ サーバー インスタンスのアップグレードUpgrading the Secondary Server Instances

このアップグレード プロセスでは、 SQL ServerSQL Server のセカンダリ サーバー インスタンスを SQL Server 2017SQL Server 2017 にアップグレードしてからプライマリ サーバー インスタンスをアップグレードします。The upgrade process involves upgrading the secondary server instances of SQL ServerSQL Server to SQL Server 2017SQL Server 2017 before upgrading the primary server instance. 常にセカンダリの SQL ServerSQL Server インスタンスを最初にアップグレードしてください。Always upgrade the secondary SQL ServerSQL Server instances first. アップグレードされたセカンダリ サーバーでは引き続き SQL ServerSQL Server のプライマリ サーバー インスタンスからログ バックアップの復元が行われるため、アップグレード プロセスの間もログ配布は継続されます。Log shipping continues throughout the upgrade process because the upgraded secondary server instances continue to restore the log backups from SQL ServerSQL Server primary server instance. セカンダリ サーバー インスタンスより先にプライマリ サーバー インスタンスをアップグレードすると、ログ配布が失敗します。これは、新しいバージョンの SQL ServerSQL Server で作成されたバックアップを古いバージョンの SQL ServerSQL Serverで復元することはできないためです。If the primary server instance is upgraded before the secondary server instance, log shipping will fail because a backup created on a newer version of SQL ServerSQL Server cannot be restored on an older version of SQL ServerSQL Server. セカンダリ インスタンスは同時でも順番にでもアップグレードできますが、ログ配布のエラーを避けるため、プライマリ インスタンスのアップグレード前にすべてのセカンダリ インスタンスをアップグレードする必要があります。You can upgrade the secondary instances simultanously or serially, but all secondary instance must be upgraded before the primary instance is upgraded to avoid a log shipping failure.

セカンダリ サーバー インスタンスをアップグレードしている間はログ配布のコピーと復元のジョブは実行されません。While a secondary server instance is being upgraded, the log shipping copy and restore jobs do not run. つまり、復元されていないトランザクション ログのバックアップがプライマリに蓄積されるため、その復元されていないバックアップを保持するための十分な領域が必要です。This means that unrestored transaction log backups will accumulate on the primary and you need to have sufficient space to hold these unrestored backups. 蓄積される量は、プライマリ サーバー インスタンスでスケジュールされているバックアップの頻度と、セカンダリ インスタンスをアップグレードする順序によって異なります。The amount of accumulation depends on the frequency of scheduled backup on the primary server instance and the sequence in which you upgrade the secondary instances. また、独立した監視サーバーが構成されている場合は、構成されている間隔を経過しても復元が行われないことを知らせる警告が生成されることがあります。Also, if a separate monitor server has been configured, alerts might be raised indicating restores have not been performed for longer than the configured interval.

セカンダリ サーバー インスタンスのアップグレードが完了すると、ログ配布エージェント ジョブが再開され、引き続きプライマリ サーバー インスタンスのログ バックアップがセカンダリ サーバー インスタンスにコピーおよび復元されます。Once the secondary server instances have been upgraded, the log shipping agents jobs resume and continue to copy and restore log backups from the primary server instance to the secondary server instances. セカンダリ サーバー インスタンスでセカンダリ データベースが最新の状態になるまでにかかる時間は、セカンダリ サーバー インスタンスのアップグレードにかかった時間とプライマリ サーバーのバックアップの頻度に依存します。The amount of time required for the secondary server instances to bring the secondary database up to date varies, depending on the time taken to upgrade the secondary server instance and the frequency of the backups on the primary server.

注意

サーバー アップグレードの過程では、セカンダリ データベース自体は SQL Server 2017SQL Server 2017 データベースにアップグレードされません。During the server upgrade, the secondary database itself is not upgraded to a SQL Server 2017SQL Server 2017 database. ログ配布済みデータベースのフェールオーバーを開始してオンラインになるとアップグレードされます。It will get upgraded only if it is brought online by initiating a failover of the log shipped database. 理論上は、この状況は無限に続きます。In theory, this condition could persist indefinitely. フェールオーバーが開始され、データベースのメタデータのアップグレードにかかる時間はわずかです。The amount of time to upgrade the database metadata when a failover is initiated is small.

重要

アップグレードが必要なデータベースに対しては RESTORE WITH STANDBY オプションはサポートされません。The RESTORE WITH STANDBY option is not supported for a database that requires upgrading. アップグレードされたセカンダリ データベースが RESTORE WITH STANDBY を使用して構成されている場合、アップグレード後にトランザクション ログを復元できなくなります。If an upgraded secondary database has been configured by using RESTORE WITH STANDBY, transaction logs can no longer be restored after upgrade. そのセカンダリ データベースでのログ配布を再開するには、そのスタンバイ サーバーでもう一度ログ配布を設定する必要があります。To resume log shipping on that secondary database, you will need to set up log shipping again on that standby server. STANDBY オプションの詳細については、「トランザクション ログ バックアップの復元 (SQL Server)」を参照してください。For more information about the STANDBY option, see Restore a Transaction Log Backup (SQL Server).

プライマリ サーバー インスタンスのアップグレードUpgrading the Primary Server Instance

ログ配布は主にディザスター リカバリー ソリューションであるため、最も単純で一般的なシナリオは、プライマリ インスタンスを適切にアップグレードすることです。データベースはこのアップグレード中は使用できなくなります。Since log shipping is primarily a disaster recovery solution, the simplest and most common scenario is to upgrade the primary instance in-place and the database is simply unavailable during this upgrade. サーバーのアップグレードが完了すると、データベースが自動的にオンラインに戻り、データベースのアップグレードが行われます。Once the server is upgraded, the database is automatically brought back online, which causes it to be upgraded. データベースのアップグレードが完了すると、ログ配布ジョブが再開されます。After the database is upgraded, the log shipping jobs resume.

注意

ログ配布では、ログ配布のセカンダリへのフェールオーバー (SQL Server)のオプションもサポートしています。また、プライマリ ログ配布サーバーとセカンダリ ログ配布サーバー間でのロールの変更 (SQL Server)もできます。Log shipping also supports the option to Fail Over to a Log Shipping Secondary (SQL Server), and optionally Change Roles Between Primary and Secondary Log Shipping Servers (SQL Server). ただし、ログ配布が高可用性ソリューションとして構成されることは今後ほとんどないため (新しいオプションの方が堅牢性がかなり高い)、フェールオーバーでは通常ダウンタイムが最小化されません。フェールオーバーではシステム データベース オブジェクトが同期されず、昇格したセカンダリを見つけて接続しやすくするためのクライアントを有効にする方が難しいためです。However, since log shipping is rarely configured as a high availability solution anymore (newer options are much more robust), failing over generally will not minimize downtime because system database objects will not be synchronized and enabling clients to easily locate and connect to a promoted secondary can be an ordeal.

参照See Also

インストール ウィザードを使用した SQL Server 2016 へのアップグレード (セットアップ) Upgrade to SQL Server 2016 Using the Installation Wizard (Setup)
コマンド プロンプトからの SQL Server 2016 のインストール Install SQL Server 2016 from the Command Prompt
ログ配布の構成 (SQL Server) Configure Log Shipping (SQL Server)
ログ配布の監視 (Transact-SQL) Monitor Log Shipping (Transact-SQL)
ログ配布テーブルとストアド プロシージャLog Shipping Tables and Stored Procedures