接続されたレプリカの同期

Standard または Advancedのライセンスで利用可能。

ArcGIS Pro 内の [変更の同期 (Synchronize Changes)] ジオプロセシング ツールを使用して、ユーザーが指定した同期方向で 2 つのレプリカ ジオデータベース間の更新を同期させることができます。

以下では、各設定の同期処理に対する影響を理解できるように、ツールの入力パラメーターとオプションについて説明します。

入力ジオデータベースとレプリカ

同期のための関連レプリカを含むジオデータベースまたはジオデータ サービスと、同期の際の変更内容の送信方向を定義します。

ジオデータベースまたはジオデータ サービスをジオデータベース 1 に指定し、その他をジオデータベース 2 に指定します。 これにより、競合の自動解決を選択した場合に、同期中に変更内容を送信する方向と競合する変更の解決方法を、後から定義できるようになります。

注意:

ジオデータ サービスから相対レプリカにアクセスする場合、[変更の同期 (Synchronize Changes)] ツールを実行する ArcGIS Pro プロジェクトには、そのジオデータ サービスが実行されている ArcGIS Server サイトへの接続が含まれている必要があります。

指定するジオデータ サービスが ArcGIS Pro サービス ランタイムを使用していることを確認してください。ArcMap サービス ランタイムはサポートが終了しているからです。 サービス ランタイムの詳細とジオデータ サービスの移行方法については、「サービスを ArcGIS Pro サービス ランタイムに移行」をご参照ください。

• ジオデータベース 1 - 同期するレプリカを含んでいるファイル ジオデータベース、エンタープライズ ジオデータベース、またはジオデータ サービス。

  [変更の同期 (Synchronize Changes)] ツールを [レプリカの管理] ウィンドウのメニュー ボタン または 分散ジオデータベース ショートカット メニューから起動した場合、ジオデータベース 1 には現在のワークスペースからの接続情報が含まれます。

• [レプリカ] - 入力ジオデータベースとして、親レプリカおよび子レプリカが含まれている有効なレプリカ。 レプリカ パラメーターにはジオデータベース 1 のワークスペースで見つかった最初のレプリカが入力されますが、別のレプリカを選択することもできます。

  [レプリカの管理] ウィンドウで特定のジオデータベース レプリカから [変更の同期 (Synchronize Changes)] ツールを開いた場合、レプリカ パラメーターにはそのレプリカの名前が入力されます。

• ジオデータベース 2 - ジオデータベース 1 にあるレプリカに関連するレプリカを含んでいるファイル ジオデータベース、エンタープライズ ジオデータベース、またはジオデータ サービス。

  相対レプリカの接続情報がジオデータ サービスを参照する場合は、適切な ArcGIS Server サイトに移動して、ジオデータ サービスを選択します。

  ユーザーが [レプリカ] パラメーターに指定したレプリカがジオデータベースを参照する場合、ツールは [ジオデータベース 2] パラメーターにその情報を入力し、レプリカに格納された情報を使用してジオデータベースにアクセスします。 ツールがジオデータベースにアクセスできない場合、[ジオデータベース 2] パラメーター値はツール内で無効としてマークされるので、作業を進める前に問題を修正する必要があります。

  ツールがジオデータベースにアクセスできない理由に関するいくつかの例を以下に示します。

  • ツールを実行しているコンピューターが、ファイル ジオデータベースまたはデータベース接続ファイル (.sde) の格納されたフォルダーにアクセスできない。
  • 接続するユーザーのパスワードが変更されたか、ジオデータベースに格納されているライセンスが期限切れてあるために、エンタープライズ ジオデータベース接続が有効でなくなった。
  • ファイル ジオデータベースまたはデータベース接続ファイルが削除された。

方向

関連するレプリカを含むジオデータベースまたはジオデータ サービスを定義したら、変更の送信方向を選択します。

双方向レプリカの場合は、以下のいずれかのオプションを使用できます。

一方向レプリカの場合は、ジオデータベース 1 からジオデータベース 2 に、またはジオデータベース 2 からジオデータベース 1 の方向に同期できます。

チェックアウト/チェックイン レプリカの場合は、子レプリカから親レプリカに変更を送信するオプションのみ使用できます。 子となるジオデータベースまたはジオデータ サービスをツールが決定し、それに応じて方向を設定します。ユーザーが変更することはできません。

• [ジオデータベース 1 → ジオデータベース 2] - 変更内容がジオデータベース 1 からジオデータベース 2 に同期されます。
• [ジオデータベース 2 → ジオデータベース 1] - 変更内容がジオデータベース 2 からジオデータベース 1 に同期されます。
• [双方向] - 変更内容はまず一方向に送信され、次に逆方向に送信されます。 これは、双方向レプリカに対するデフォルト設定です。

競合解決ポリシー

レプリカの同期の際には、同期バージョンとレプリカ バージョンの間でリコンサイルとポスト プロセスが実行されます。 このリコンサイル プロセス中に、競合が発生することがあります。 これらの競合の処理方法を定義するためのポリシーを選択できます。

同期バージョンとレプリカ バージョンの詳細、およびリコンサイル プロセスが実行される場合の詳細については、「同期とバージョニング」をご参照ください。

以下のいずれかの競合解決ポリシーを選択します。

• [競合を手動で解決] - このポリシーでは、競合が発生するとリコンサイル操作は停止し、レプリカは競合を含むことを示すようにマークされます 。 これにより、後から手動で、またはカスタム リコンサイル コードを実行して、リコンサイルを実行することができるので、競合を個別に評価できます。 リコンサイル プロセスを実行して、変更をレプリカ バージョンにポストすると、レプリカは競合を含まない状態になります。 詳細については、「手動による同期の競合の解決」をご参照ください。

  注意:

  レプリカに同期の競合が含まれる場合、引き続き変更を受信することは可能ですが、変更を送信することはできません。

  双方向レプリカでは、同期方向に双方向を選択した場合、手動の競合の解決ポリシーは選択できません。

• [ジオデータベース 1 を優先して解決] - 競合が生じると、ジオデータベース 2 の状態ではなく、ジオデータベース 1 の状態が自動的に使用されます。 競合は自動的に解決されるため、このポリシーを使用して同期した後に、レプリカが競合状態になることはありません。
• [ジオデータベース 2 を優先して解決] - 競合が生じると、ジオデータベース 1 の状態ではなく、ジオデータベース 2 の状態が自動的に使用されます。 競合は自動的に解決されるため、このポリシーを使用して同期した後に、レプリカが競合状態になることはありません。

競合の定義

前のセクションで説明したように、同期の際に実行されるリコンサイル プロセス中に、競合が発生することがあります。

リコンサイル プロセスとオプションの詳細については、「バージョニング オプション」をご参照ください。

競合と見なされる変更のタイプを定義するには、次のいずれかのオプションを選択します。

• [行単位の競合] - 両方のバージョンに同じフィーチャまたは行の変更がある場合、競合として認識されます。
• [列単位の競合] - 両方のバージョンに同じ属性またはフィーチャクラスのジオメトリの変更がある場合、競合として認識されます。

親バージョンとリコンサイル

このオプションは、チェックアウト/チェックイン レプリカでのみ使用可能で、データの変更が親レプリカに送信された際に、競合が存在しない場合は親レプリカに自動的に変更をリコンサイルするかどうかを示します。

• [リコンサイルしない] - リコンサイル プロセスは実行されません。 これがデフォルトです。
• [リコンサイル] - 自動的にリコンサイルします。

トラディショナル バージョンに編集をリコンサイルおよびポストする方法の詳細

注意:

同期プロセスのインポート フェーズは、トランザクション内で実行されます。 同期の第 2 フェーズに含まれるリコンサイル プロセスも、トランザクション内で実行されます。 必要なリソース (UNDO 領域や論理ログ ファイルなど) は、同期する変更の数によって異なります。 インポート フェーズが完了してリコンサイル フェーズがエラーになった場合、レプリカは競合状態 であるかのように表示されるため、後で手動でリコンサイルを完了することができます。

エラー処理

同期中にエラーが発生した場合、操作はロールバックされます。 適用されたすべての変更内容は削除され、システムは変更の同期前の状態に戻されます。

この場合の唯一の例外は、双方向で同期した際に発生する可能性があります。 ここでは、一方向の変更を適用するプロセスの完了後にエラーが発生した場合、これらの変更はコミットされますが、システムは一貫性のある状態のままで、それ以降の同期プロセスは影響を受けません。