ジオデータベース レプリケーションでは、エンタープライズ ジオデータベースでホストされているレプリカに対する同期プロセスでバージョニングが使用されます。バージョニングによって、送信する変更内容と受信する変更内容が決定されます。ただし、一方向レプリケーションで変更の履歴管理を使用している場合は例外です。
ここでは、次の各同期プロセスでバージョニングがどのように使用されるかを説明します。
変更の送信
レプリカから変更が送信されると、レプリカ バージョン (レプリカの作成時に定義される) とシステム バージョンが解析されます。この解析により、以前の同期時にすでに送信されている編集内容を除外したり、再送が必要な変更を判断したりすることができます。ファイル ジオデータベース内のチェックアウト/チェックイン レプリカの場合は、すべての編集内容が含まれている内部テーブルが解析されます。履歴管理を使用している一方向レプリケーションの場合は、アーカイブ クラスを解析することにより、送信する変更内容を決定します。
変更の受信
レプリカによる変更の受信は、以下の手順で行われます。
まず、変更が同期バージョンに適用されます。同期バージョンは、レプリカ バージョンへのリコンサイルとポストが終了するまで同期済みの変更を一時的に保持するように設計されたレプリカ バージョンの子です。双方向レプリカと一方向レプリカの場合は、同期の実行時までバージョンが作成されませんが、チェックアウト/チェックイン レプリカの場合は、レプリカの作成時にバージョンが作成されます。下の図にあるレプリカ バージョンには、デフォルト バージョンと名前付きバージョンをどちらも使用することができます。
次に、同期バージョンがレプリカ バージョンに対してリコンサイルされます。この段階での動作は、レプリカの種類によって異なります。
- 双方向レプリカ - 双方向レプリカの場合は、リコンサイル時に競合が発生する可能性があります。競合が検出された場合は、リコンサイル ポリシーによって、競合の処理方法が決定されます。競合が存在しないか自動リコンサイル ポリシーによって自動的に競合した場合、レプリカ バージョンに対して同期バージョンがポストされます。
- チェックアウト/チェックイン レプリカ - チェックアウト/チェックイン レプリカでは、リコンサイルとポストはオプションの処理であり、デフォルトで実行されません。リコンサイルとポストを実行しない場合、変更は同期バージョンに残るため、 後からリコンサイルとポストを手動で実行することができます。リコンサイルとポストを手動で実行する場合の手順は、双方向レプリカの場合と同じです。
- 一方向レプリカ - 一方向レプリカでは、レプリカ バージョンの変更が常に上書きされるので、未解決の競合は存在しません。シンプル モデル タイプを使用している場合は、子レプリカ内のデータをバージョン対応登録する必要がありません。子レプリカがバージョン対応登録されていない場合は、変更がベース テーブルに直接適用されます。また、子レプリカがファイル ジオデータベースでホストされている場合は、変更が直接上書きされます。
変更がレプリカ バージョンにポストされると、同期バージョンが削除されます。双方向レプリカの場合は、同期バージョンが存在する限り、レプリカは競合状態と見なされます。レプリカが競合状態の場合、そのレプリカは変更を受信することは可能ですが、変更を送信することはできません。
メモ:
リコンサイルとポストは、レプリカの所有者としてサイン インしている際に実行することをお勧めします。デフォルトでは、同期バージョンはプライベートであり、レプリカ所有者しかアクセスできません。このバージョンをパブリックにすれば、レプリカ所有者以外のユーザーとしてリコンサイルと変更の保存ができますが、 レプリカ バージョンの所有者としてサイン インしている際に、変更をポストする必要があります。