SQL Server レプリケーションの動作の変更

このトピックでは、SQL Server レプリケーションの動作変更について説明します。動作変更によって、SQL Server 2008 の機能や操作方法が SQL Server の以前のバージョンと異なっています。

SQL Server 2005 での動作の変更

このセクションでは、SQL Server 2005 のレプリケーション機能の動作変更について説明します。

あらゆる種類のレプリケーションに影響を与える動作の変更

次の変更はすべての種類のレプリケーションに影響を与えます。

機能

説明

レプリケーション エージェント セキュリティ モデル

SQL Server の以前のバージョンの既定では、エージェントは SQL Server エージェント サービス アカウントのコンテキストで実行されていました。現在は、レプリケーション エージェントが実行されデータベースなど他のリソースへの Microsoft Windows 統合接続が行われる際の各アカウントに対して、きめ細かい制御が可能になり、エージェントごとに異なるアカウントを指定できるようになりました。詳細については、「セキュリティと保護 (レプリケーション)」および「レプリケーション エージェントのセキュリティ モデル」を参照してください。この変更がアップグレードに与える影響については、「レプリケートされたデータベースのアップグレードに関する注意点」の「新しいレプリケーション エージェントのセキュリティ モデル」および「SQL Server レプリケーションにおける重大な変更」を参照してください。

Windows 同期マネージャ

SQL Server 2005 より前のバージョンの SQL Server では、同期マネージャとサブスクリプションを同期する機能が既定で有効になっていました。SQL Server 2005 で同期マネージャを使用する場合は、このオプションを明示的に有効にする必要があります。詳細については、「Windows 同期マネージャを使用してサブスクリプションを同期する方法 (Windows 同期マネージャ)」を参照してください。

レプリケーション競合表示モジュール

SQL Server 2000 では、レプリケーション競合表示モジュールは、再配布用にパッケージされていました。SQL Server 2005 では、この表示モジュールは個別にパッケージされていません。レプリケーション競合表示モジュールをアプリケーションに含めるには、アプリケーションの配置先のコンピュータに Microsoft .NET Framework 2.0 をインストールし、そのコンピュータに各種のファイルをコピーする必要があります。詳細については、アップグレード アドバイザの「レプリケーションのアップグレードに関するその他の問題」を参照してください。アップグレード アドバイザの詳細については、「アップグレード アドバイザを使用したアップグレードの準備」を参照してください。

スキーマ オプションの変更

スキーマ オプションでは、インデックスや制約など、テーブルに関連付けられた属性とオブジェクトをレプリケートする方法を指定できます。SQL Server 2005 では、いくつかのスキーマ オプションの動作が変更されました。詳細については、このトピックの次のセクションで説明します。

スキーマ オプションの動作の変更

次の表は、SQL Server 2005 のスキーマ オプションの変更点をまとめたものです。

注意注意

0x8000 スキーマ オプションが SQL Server 2000 で設定されている場合は、SQL Server 2005 へのアップグレード中に無効になります。スキーマ オプション 0x10 または 0x40 の場合、SQL Server 2005 では、レプリケーションによって SQL Server 2000 より多くのインデックスが作成されます。

オプション

SQL Server 2000 でオプションが設定されている場合の動作

SQL Server 2005 でオプションが設定されている場合の動作

0x80

制約またはインデックスを作成します。オプション 0x8000 も有効な場合、主キーがインデックス付きの制約として作成されます。オプション 0x8000 が有効でない場合は、主キー列のインデックスのみが作成されます。

サブスクライバで主キー制約を作成します。0x10 および 0x40 オプションが有効になっていない場合でも (これらのオプションは他のケースのインデックス作成を制御します)、この制約に関連するインデックスがあれば、そのインデックスもレプリケートされます。

0x4000

制約またはインデックスを作成します。オプション 0x8000 も有効な場合、一意制約がインデックス付きの制約として作成されます。オプション 0x8000 が有効でない場合は、列のインデックスのみが作成されます。

サブスクライバに一意制約を作成します。0x10 および 0x40 オプションが有効になっていない場合でも (これらのオプションは他のケースのインデックス作成を制御します)、この制約に関連するインデックスがあれば、そのインデックスもレプリケートされます。

0x8000

0x80 または 0x4000 オプションも指定されている場合、主キー制約と一意制約を作成します。これらのオプションのどちらも指定されていない場合、0x8000 オプションは無効です。

オプションは無効です。

トランザクション レプリケーションの動作の変更

次の変更はトランザクション レプリケーションに影響を与えます。

機能

説明

サブスクライバ オブジェクトの所有権

SQL Server 2005 のパブリケーションの新規作成ウィザードを使用してパブリケーションを作成する場合、既定では、サブスクライバで作成されるオブジェクトの所有者はパブリッシャで対応するオブジェクトの所有者の値になります。以前のリリースでは、サブスクライバでのオブジェクト作成時に所有者は指定されませんでした。既定で、サブスクライバへの接続に使用されたディストリビューション エージェント アカウントに関連付けられた所有者になりました。ストアド プロシージャ sp_addarticle (Transact-SQL) の場合、動作は変更されていません。

更新可能なサブスクリプションのセキュリティ モード

sp_link_publication@security_mode パラメータは、即時更新サブスクリプションのトリガがどのようにパブリッシャで呼び出しを実行するかを指定します。SQL Server 2005 では、このパラメータのオプションは次のとおりです。

  • 0 : このストアド プロシージャでログインおよびパスワードとして指定されたログインで SQL Server 認証を使用します。

  • 1 : サブスクライバで変更を行うユーザーのセキュリティ コンテキスト (SQL Server 認証または Windows 統合認証) を使用します。

  • 2 : 既存のユーザー定義リンク サーバー ログインを使用します。

SQL Server の以前のバージョンでは、オプション 0 を使用して、リンク サーバーではなく、サブスクライバからパブリッシャへの動的なリモート プロシージャ コール (RPC) を指定していました。

マージ レプリケーションの動作の変更

次の変更はマージ レプリケーションに影響を与えます。

機能

説明

パブリケーションの互換性レベル

以前のバージョンの SQL Server では、高い互換性レベルを必要とする機能を有効にすると、互換性レベルが自動的に上がりました。SQL Server 2005 では、互換性レベルを手動で 90RTM に設定してから、その互換性レベルを必要とする機能を有効にする必要があります。詳細については、「レプリケーション トポロジにおける複数バージョンの SQL Server の使用」の「マージ パブリケーションの互換性レベル」セクションを参照してください。

補正アクション

以前のバージョンの SQL Server では、同期中にエラー (制約違反など) が発生すると、補正アクションが行われました。この動作が望ましい場合もありますが、状況によってはって問題となることもあります。たとえば、サブスクライバの不適切な構成が原因でエラーが発生すると、パブリッシャおよびその他すべてのサブスクライバで変更が取り消され、元の状態に戻ります。

SQL Server 2005 では、sp_addmergearticle@compensate_for_errors パラメータを使用して補正アクションを行うかどうかを制御します。False (既定値) に設定すると、補正アクションは無効になります。ただし、エラーがログに記録され、それ以降のマージでは引き続き変更の適用が試行されます。一見、影響を受ける行のデータが収束しないように思えますが、エラーに対処した時点で変更を適用できるようになり、データが収束します。True に設定した場合、同期中、ノードに適用できない変更があると、補正アクションが実行され、他のすべてのノードの変更が元に戻ります。

注意注意
アーティクルのソース テーブルが別のパブリケーションで既にパブリッシュされている場合、@compensate_for_errors の値は、両方のアーティクルで同じである必要があります。SQL Server 2000 Version 8.00.858 以前のバージョン (Service Pack 3 を含む) を実行しているサブスクライバでのプル サブスクリプションの場合、@compensate_for_errors が False に設定されていても補正アクションは行われます。

競合テーブル

以前のバージョンの SQL Server では、マージ レプリケーションは、パブリケーションのテーブル アーティクルごとに conflict_<ArticleName> 形式の名前を持つ 1 つの競合テーブルを作成していました。SQL Server 2005 では、情報は 2 つのテーブルに格納されます。MSmerge_conflicts_info、および MSmerge_conflict_<PublicationName>_<ArticleName> 形式の名前を持つテーブルです。

保有期間に基づくメタデータのクリーンアップ

SQL Server 2005 では保有期間に基づくメタデータのクリーンアップを使用します。この機能は SQL Server 2000 Service Pack 1 から導入されました。メタデータは定期的に次のシステム テーブルから削除されます。

  • MSmerge_contents

  • MSmerge_tombstone

  • MSmerge_genhistory

  • 変更前イメージ テーブル (存在する場合)。パブリケーションに対して同期の最適化オプション @keep_partition_changes が有効になっている場合、変更前イメージ テーブルが存在します (このオプションについては、次のセクションを参照してください)。

@keep_partition_changes パラメータ

SQL Server の以前のバージョンでは、既定で @keep_partition_changes パラメータが False に設定されていました。これは、パブリッシャに格納されるデータが多くなるためです。パブリケーションの互換性レベルが 90RTM 以上であり、@use_partition_groups パラメータが False に設定されている場合、このオプションは True に設定されるようになりました。これらのオプションの詳細については、「パラメータ化された行フィルタ」を参照してください。