レプリケーションの管理者に関してよく寄せられる質問

いいえ。 パブリケーションの作成中でもデータベースの操作を継続することができます。 ただし、スナップショットの生成には大量のリソースが必要な点に注意してください。そのため、スナップショットはデータベースでの操作が少ない時間帯に生成することをお勧めします (既定では、パブリケーションの新規作成ウィザードを終了するとスナップショットが生成されます)。

ロックが設定される時間の長さは、使用するレプリケーションの種類によって以下のように異なります。

• マージ パブリケーションの場合、スナップショット エージェントはロックを設定しません。

• トランザクション パブリケーションの場合、既定では、スナップショット エージェントによりスナップショット生成の初期フェーズの間だけロックが設定されます。

• スナップショット パブリケーションの場合、スナップショット エージェントがスナップショット生成処理の間中、ロックを設定します。

ロックが設定されると他のユーザーがテーブルを更新できなくなるため、特にスナップショット パブリケーションの場合、データベースに対する操作が少ない時間帯にスナップショット エージェントを起動するようにスケジュールを設定することをお勧めします。

サブスクリプションは、スナップショットがサブスクリプション データベースに適用された後で利用可能になります。 それ以前にもサブスクリプション データベースにアクセスできますが、スナップショットの適用が完了するまではデータベースを使用しないでください。 スナップショットの生成と適用の状態を確認するには、レプリケーション モニターを使用します。

• スナップショットはスナップショット エージェントによって生成されます。 パブリケーションのスナップショットの生成状態は、レプリケーション モニターの [エージェント] タブで確認します。 詳細については、「View information and perform tasks using Replication Monitor」 (レプリケーション モニターを使用して情報を表示し、タスクを実行する) を参照してください。

• スナップショットはディストリビューション エージェントまたはマージ エージェントによって適用されます。 スナップショットの適用状態は、レプリケーション モニターの [ディストリビューション エージェント] ページまたは [マージ エージェント] ページで確認します。 詳細については、「View information and perform tasks using Replication Monitor」 (レプリケーション モニターを使用して情報を表示し、タスクを実行する) を参照してください。

ディストリビューション エージェントまたはマージ エージェントがスナップショット エージェントと同時に実行されてもエラーになることはありません。 ただし、以下の点に注意してください。

• ディストリビューション エージェントまたはマージ エージェントが連続して実行されるように構成されている場合は、スナップショット エージェントが終了した後でスナップショットが自動的に適用されます。

• ディストリビューション エージェントまたはマージ エージェントが、スケジュールまたは要求時に実行されるように構成されており、エージェント起動時には利用可能なスナップショットがなかった場合には、エージェントはスナップショットが利用できないことを示すメッセージを表示して終了します。 スナップショットを適用するためには、スナップショット エージェントが完了した後でエージェントを再度実行する必要があります。 エージェントの実行については、「Synchronize a Push Subscription」 (プッシュ サブスクリプションの同期)、「Synchronize a Pull Subscription」 (プル サブスクリプションの同期)、「Replication Agent Executables Concepts」 (レプリケーション エージェント実行可能ファイルの概念) を参照してください。

はい。 レプリケーション構成をスクリプト化するのは、レプリケーション トポロジのディザスター リカバリー計画の重要な部分です。 スクリプト作成の詳細については、「 Scripting Replication」を参照してください。

単純復旧モデル、一括ログ復旧モデル、完全復旧モデルのいずれの復旧モデルでも、レプリケーションは正常に機能します。 マージ レプリケーションでは、メタデータ テーブルに情報を格納することで変更が追跡されます。 トランザクション レプリケーションでは、トランザクション ログにマークを付けることにより変更が追跡されますが、復旧モデルによってこのマーク設定処理が影響を受けることはありません。

変更を追跡するため、マージ レプリケーションとキュー更新サブスクリプションを使用したトランザクション レプリケーションでは、パブリッシュされたすべてのテーブルのすべての行を一意に識別できる必要があります。 これには、以下を行う必要があります。

• マージ レプリケーションでは、列 rowguid がすべてのテーブルに追加されます。ただし、データ型が uniqueidentifier で ROWGUIDCOL プロパティが設定されている列が、テーブルに既にある場合を除きます (このような列がある場合は、その列が使用されます)。 テーブルがパブリケーションから削除されると、 rowguid 列も削除されます。既存の列を追跡に使用していた場合は、その列は削除されません。

• トランザクション パブリケーションがキュー更新サブスクリプションをサポートしている場合は、レプリケーションによってすべてのテーブルに msrepl_tran_version 列が追加されます。 テーブルがパブリケーションから削除されても、 msrepl_tran_version 列は削除されません。

• フィルターには、レプリケーションで行の識別に使用される rowguidcol を含めることはできません。 既定では、これはマージ レプリケーションのセットアップ時に追加される列であり、 rowguidという名前が付けられます。

パブリッシュされたテーブル上の制約については、注意すべき問題がいくつかあります。

• トランザクション レプリケーションでは、パブリッシュされた各テーブルで主キー制約が必要です。 マージ レプリケーションでは主キーは不要ですが、もし主キーがある場合には、レプリケートする必要があります。 スナップショット レプリケーションでは主キーは不要です。

• 既定では、主キー制約、インデックス、および CHECK 制約がサブスクライバーにレプリケートされます。

• 外部キー制約と CHECK 制約に対しては、NOT FOR REPLICATION オプションが既定で指定されます。この制約は、ユーザー操作に対しては適用されますが、エージェント操作には適用されません。

制約がレプリケートされるかどうかを制御するスキーマ オプションの設定の詳細については、「 Specify Schema Options」を参照してください。

サブスクライバーでの更新を含むレプリケーション トポロジでは、自動 ID 範囲管理が提供されます。 詳細については、「Replicate Identity Columns」 (ID 列のレプリケート) を参照してください。

はい。ただし、制限があります。 詳細については、「Publish Data and Database Objects」 (データとデータベース オブジェクトのパブリッシュ) の「Publishing Tables in More Than One Publication」 (複数のパブリケーションでのテーブルのパブリッシュ) を参照してください。

はい。 同じディストリビューション データベースを使用するパブリケーションの数や種類に制限はありません。 指定されたパブリッシャーのすべてのパブリケーションで、同じディストリビューターとディストリビューション データベースを使用する必要があります。

複数のパブリケーションがある場合は、ディストリビューターで複数のディストリビューション データベースを構成することにより、各ディストリビューション データベースのデータ フローを、単一のパブリケーションから渡すことができます。 [ディストリビューターのプロパティ] ダイアログ ボックスまたは sp_adddistributiondb (Transact-SQL) を使用して、分散データベースを追加します。 このダイアログ ボックスへのアクセスの詳細については、「View and Modify Distributor and Publisher Properties」 (ディストリビューターとパブリッシャーのプロパティの表示および変更) を参照してください。

この情報は、SQL Server Management Studio およびいくつかのレプリケーション ストアド プロシージャを使用して参照できます。 詳細については、「 Distributor and Publisher Information Script」を参照してください。

いいえ。 レプリケーションでは、データベースに格納されるデータやネットワーク経由で転送されるデータは暗号化されません。 詳細については、「レプリケーションのセキュリティ設定の表示および変更」のトピックの暗号化に関する説明を参照してください。

インターネット経由のデータのレプリケーションでは、以下を使用します。

• 仮想プライベート ネットワーク (VPN)。 詳細については、「Publish Data over the Internet Using VPN」 (VPN を使用したインターネット経由のデータのパブリッシュ) を参照してください。

• マージ レプリケーション用の Web 同期オプション。 詳細については、「 Web Synchronization for Merge Replication」を参照してください。

すべての種類の Microsoft SQL Server レプリケーションは、VPN 経由でデータをレプリケートできますが、マージ レプリケーションを使用している場合は Web 同期を検討してください。

はい。 接続が切断された場合には、中断した時点からレプリケーション処理が再開されます。 不安定なネットワーク経由でマージ レプリケーションを使用している場合は、論理レコードの利用を検討してください。これにより、関連する変更が 1 つの単位として処理されるようになります。 詳細については、「Group Changes to Related Rows with Logical Records」 (論理レコードによる関連行への変更のグループ化) を参照してください。

はい。低帯域接続経由でもレプリケーションは機能します。 TCP/IP 経由の接続では、プロトコルによって提供される圧縮を利用しますが、それ以外の圧縮は行われません。 HTTPS 経由の Web 同期接続の場合は、プロトコルで提供される圧縮に加え、変更をレプリケートするために使用する XML ファイルの圧縮も使用されます。

いいえ。レプリケーションは、実際のサーバー名を使用する場合にのみ機能します。 SQL Server Management Studio (SSMS) 18.0 (およびそれ以降のバージョン) では、実際のサーバー名とポート番号を使用してレプリケーションを構成できます。

いいえ。 ただし、SSIS パッケージを作成することで、ログインとパスワードをパブリッシャーから 1 つ以上のサブスクライバーに転送することができます。

Microsoft SQL Server 2005 (9.x) 以降、 スキーマ には 2 つの意味で用いられています。

• CREATE TABLE ステートメントなどの、オブジェクトの定義。 既定では、レプリケートされるすべてのオブジェクトの定義がサブスクライバーにコピーされます。

• オブジェクトが作成される名前空間: <Database>.<Schema>.<Object>。 スキーマは、CREATE SCHEMA ステートメントで定義します。

• 既定では、パブリケーションの新規作成ウィザードは、スキーマとオブジェクトの所有権に関して、以下のように動作します。

• 互換性レベル 90 以上のマージ パブリケーションと、スナップショット パブリケーション、およびトランザクション パブリケーションのアーティクルの場合、既定では、サブスクライバーでのオブジェクト所有者は、パブリッシャーでの対応するオブジェクトの所有者と同じになります。 オブジェクトを所有するスキーマがサブスクライバーに存在しない場合は、スキーマが自動的に作成されます。

• 互換性レベルが 90 未満のマージ パブリケーションのアーティクルの場合。既定では、所有者名は空白のままなり、サブスクライバーにオブジェクトを作成する際に dbo と指定されます。

• Oracle パブリケーションのアーティクルの場合。既定では、所有者名が dboと指定されます。

• キャラクター モードのスナップショット (SQL Server 以外のバージョンのサブスクライバーや SQL Server Compact サブスクライバーで使用されます) を使用するパブリケーションのアーティクルの場合。既定では、所有者は空白のままになります。 既定の所有者は、サブスクライバーに接続しているディストリビューション エージェントまたはマージ エージェントで使用されるアカウントに関連付けられている所有者になります。

オブジェクトの所有者は、[アーティクルのプロパティ - <Article>] ダイアログ ボックスと、ストアド プロシージャの sp_addarticle、sp_addmergearticle、sp_changearticle、sp_changemergearticle で変更できます。 詳細については、「View and Modify Publication Properties」 (パブリケーション プロパティの表示および変更)、「Define an Article」 (アーティクルの定義)、および「View and Modify Article Properties」 (アーティクルのプロパティの表示および変更) を参照してください。

既定では、レプリケーションではサブスクリプション データベース上で GRANT ステートメントは実行されません。 サブスクリプション データベース上の権限をパブリケーション データベース上の権限に一致させる場合は、次のいずれかの方法を使用します。

• サブスクリプション データベース上で GRANT ステートメントを直接実行します。

• ポストスナップショット スクリプトを使用してステートメントを実行します。 詳細については、「スナップショットが適用される前および後のスクリプトの実行」を参照してください。

• ストアド プロシージャ sp_addscriptexec を使用してステートメントを実行します。

既定では、サブスクリプションを再初期化すると、サブスクライバーのオブジェクトは削除され、その後、再作成されます。それらのオブジェクトに対して付与された権限は削除されます。 これに対処するには、2 つの方法があります。

• 再初期化後に、前のセクションで説明した方法を使用して、権限を再適用します。

• サブスクリプションを再初期化するときに、オブジェクトを削除しないように指定します。 再初期化の前に、次のいずれかを実行します。

  • sp_changearticle または sp_changemergearticleを実行します。 @property パラメーターの値として "pre_creation_cmd" (sp_changearticle) または "pre_creation_command" (sp_changemergearticle) を指定し、@value パラメーターの値として "none"、"delete"、または "truncate" を指定します。

  • [宛先オブジェクト] セクションの [アーティクルのプロパティ - <アーティクル>] ダイアログ ボックスで、[既存のオブジェクトを変更せずに保持] の値を選択し、[データの削除] を選択します。アーティクルに行フィルターがある場合は、フィルターに一致するデータのみを削除します。 または、名前が使用されている場合は、オプション アクション の既存のオブジェクト内のすべてのデータを切り捨てます。 このダイアログ ボックスへのアクセスの詳細については、「View and Modify Publication Properties」 (パブリケーションのプロパティの表示および変更) を参照してください。

TRUNCATE TABLE は、個別の行削除を記録せず、DML トリガーを開始しない DDL ステートメントです。 操作による変更を追跡できないため、このコマンドは許可されていません。トランザクション レプリケーションでは、トランザクション ログを通じて変更が追跡され、マージ レプリケーションでは、パブリッシュされたテーブルの DML トリガーを通じて変更が追跡されます。

トランザクション レプリケーションの場合、他の挿入と同様に一括挿入も追跡およびレプリケートされます。 マージ レプリケーションでは、変更を追跡するメタデータが正しく更新されるようにする必要があります。

はい。 データベースのレプリケーションに関係する特別な注意点がいくつかあります。 詳細については、「 レプリケートされたデータベースのバックアップと復元」を参照してください。

マージ レプリケーションとスナップショット レプリケーションは、トランザクション ログのサイズには影響しません。ただし、トランザクション レプリケーションは影響する場合があります。 データベースに 1 つ以上のトランザクション パブリケーションが含まれている場合、それらのパブリケーションに関連するすべてのトランザクションがディストリビューション データベースに配布されるまで、トランザクション ログの切り捨ては行われません。 トランザクション ログが大きくなりすぎ、ログ リーダー エージェントをスケジュールによって実行している場合は、実行間隔を短くすることを検討してください。 または、連続モードで実行するように設定してください。 連続モードで実行するように設定されている場合は (既定値)、実行中であることを確認してください。 ログ リーダー エージェントの状態の確認の詳細については、「レプリケーション モニターを使用して情報を表示し、タスクを実行する」を参照してください。

また、パブリケーション データベースまたはディストリビューション データベース上で "sync with backup" オプションを設定している場合は、すべてのトランザクションのバックアップが完了するまでトランザクション ログの切り捨ては行われません。 トランザクション ログが大きくなりすぎ、かつ、このオプションを設定している場合は、トランザクション ログのバックアップ間隔を短くしてください。 トランザクション レプリケーションに関係するデータベースのバックアップと復元の詳細については、「Strategies for Backing Up and Restoring Snapshot and Transactional Replication」 (スナップショット レプリケーションおよびトランザクション レプリケーションのバックアップと復元の方式) を参照してください。

インデックスの再構築にはいくつかのメカニズムがあります。 どのメカニズムもレプリケーションに関して特別な注意をせずに使用できます。ただし、トランザクション パブリケーションのテーブルでは主キーが必要なため、主キーの削除や再作成を行うことはできません。

レプリケーションに関して特別な注意をしなくても、パブリッシャーまたはサブスクライバーでインデックスを追加できます (インデックスがパフォーマンスに影響する点に注意してください)。 CREATE INDEX および ALTER INDEX はレプリケートされないため、たとえばパブリッシャーでインデックスを追加または変更した場合、サブスクライバーに反映するには、同じ追加または変更を行う必要があります。

SQL Server 2005 (9.x) より前のバージョンでは、データベース ファイルの移動または名前の変更を行うには、データベースのデタッチと再アタッチが必要でした。 レプリケートされたデータベースはデタッチできないため、まずデータベースからレプリケーションを削除する必要がありました。 SQL Server 2005 (9.x) 以降では、データベースのデタッチと再アタッチを行わなくてもファイルの移動や名前の変更が行え、レプリケーションに影響を与えることもありません。 ファイルの移動と名前の変更については、「ALTER DATABASE (Transact-SQL)」を参照してください。

まず sp_droparticle、sp_dropmergearticle、[パブリケーションのプロパティ - <パブリケーション]> ダイアログ ボックスのいずれかを使用してパブリケーションからアーティクルを削除し、次に DROP <Object> を使用してデータベースからアーティクルを削除します。 サブスクリプションを追加した後で、スナップショット パブリケーションまたはトランザクション パブリケーションからアーティクルを削除することはできません。まずサブスクリプションを削除する必要があります。 詳細については、「Add Articles to and Drop Articles from Existing Publications」 (既存のパブリケーションでのアーティクルの追加および削除) を参照してください。

SQL Server では、列の追加や削除などの、パブリッシュされたオブジェクトに対するスキーマのさまざまな変更がサポートされています。 たとえば、ALTER TABLE … DROP COLUMN をパブリッシャーで実行すると、ステートメントがサブスクライバーにレプリケートされて実行され、列が削除されます。 SQL Server 2005 (9.x) より前のバージョンの SQL Server が実行されているサブスクライバーでは、ストアド プロシージャ sp_repladdcolumn および sp_repldropcolumn で列の追加と削除がサポートされています。 詳細については、「パブリケーション データベースでのスキーマの変更」を参照してください。

検証機能を使用します。 検証では、指定したサブスクライバーがパブリッシャーと同期されているかどうかがレポートされます。 詳細については、「レプリケートされたデータの検証」 を参照してください。 正しく同期されていない行がある場合、検証を行っても、同期されていない行についての情報が表示されませんが、 tablediff ユーティリティ では表示されます。

テーブル (または他のオブジェクト) を追加するときに、パブリケーション データベースまたはサブスクリプション データベースに対する操作を停止する必要はありません。 パブリケーションにテーブルを追加するには、[パブリケーションのプロパティ - <パブリケーション]> ダイアログ ボックスか、ストアド プロシージャ sp_addarticle および sp_addmergearticle を使用します。 詳細については、「Add Articles to and Drop Articles from Existing Publications」 (既存のパブリケーションでのアーティクルの追加および削除) を参照してください。

パブリケーションからテーブルを削除するには、sp_droparticle、sp_dropmergearticle、または [パブリケーションのプロパティ - <パブリケーション]> ダイアログ ボックスを使用します。 サブスクリプションを追加した後で、スナップショット パブリケーションまたはトランザクション パブリケーションからアーティクルを削除することはできません。まずサブスクリプションを削除する必要があります。 詳細については、「Add Articles to and Drop Articles from Existing Publications」 (既存のパブリケーションでのアーティクルの追加および削除) を参照してください。

アーティクルやパブリケーションに対する変更の中には、サブスクリプションの再初期化が必要になるものがあります。 詳細については、「Change Publication and Article Properties」 (パブリケーションおよびアーティクルのプロパティの変更) を参照してください。

アーティクルやパブリケーションに対する変更の中には、スナップショットが無効になり、新しいスナップショットを生成する必要が生じるものがあります。 詳細については、「Change Publication and Article Properties」 (パブリケーションおよびアーティクルのプロパティの変更) を参照してください。

データベースからレプリケーションを削除するために必要な操作は、データベースがパブリケーション データベースであるか、サブスクリプション データベースであるか、その両方であるかによって異なります。

トランザクション レプリケーションの場合は、ストアド プロシージャか、レプリケーション モニターの [未配布のコマンド] タブを使用します。 詳細については、「レプリケートされたコマンドとディストリビューション データベースの情報の表示 (レプリケーション Transact-SQL プログラミング)」および「レプリケーション モニターを使用して情報を表示し、タスクを実行する」を参照してください。

マージ レプリケーションの場合は、ストアド プロシージャ sp_showpendingchangesを使用します。 詳細については、「sp_showpendingchanges (Transact-SQL)」を参照してください。

ストアド プロシージャ sp_replmonitorsubscriptionpendingcmds か、レプリケーション モニターの [未配布のコマンド] タブを使用します。 ストアド プロシージャとタブには、次の内容が表示されます。

• ディストリビューション データベース内のコマンドで、選択したサブスクライバーにまだ配布されていないコマンドの数を示します。 コマンドは、1 つの Transact-SQL データ操作言語 (DML) ステートメントまたは 1 つのデータ定義言語 (DDL) ステートメントから構成されます。

• コマンドをサブスクライバーに配布するのに要すると推定される時間を示します。 スナップショットを生成してサブスクライバーに適用するのに必要な時間よりもこの値が大きい場合は、サブスクライバーの再初期化を検討してください。 詳細については、「 サブスクリプションの再初期化」を参照してください。

詳細については、「sp_replmonitorsubscriptionpendingcmds (Transact-SQL)」および「レプリケーション モニターを使用して情報を表示し、タスクを実行する」を参照してください。

はい。 詳細については、「ログ配布とレプリケーション (SQL Server)」および「データベース ミラーリングとレプリケーション (SQL Server)」を参照してください。

はい。 データはすべてクラスターの 1 つのディスク セットに格納されるため、特別な注意は不要です。

サポートを受ける上で問題がございましたら、サード パーティベンダーにお問い合わせください。 一般に、問題が SQL Server に付属する主要なレプリケーションの問題としてベンダーによって分離されている場合は、Microsoft サポートがさらに支援を続けます。

参照

レプリケーション管理に関する FAQ
Best Practices for Replication Administration