Standard または Advancedのライセンスで利用可能。
異なるジオデータベースにデータを分散すること、および各データベースのデータに対して行われた変更を同期することが、さまざまなワークフローで必要になります。 このトピックでは、システムでデータ分散、ジオデータベース レプリカ、および同期を最適に使用する方法について説明します。
まず、「データ分散の概要」をご参照ください。このトピックでは、ジオデータベース レプリケーションとデータを分散させるための方法について、その概要が説明されています。 「シナリオ」では、ジオデータベース レプリケーションを使用するための一般的なユース ケースが紹介されています。 ジオデータベース レプリケーションがシステムに最も適した方法と考えられる場合は、次の手順としてレプリカを作成します。
レプリカの作成
次の情報は、システムのレプリカを作成するための最適な方法を判断するのに役立ちます。
- どのようなレプリカが必要か判断する: レプリカを 1 つか 2 つだけ作成すれば十分な場合もあれば、多くのレプリカが必要になる場合もあります。 たとえば、多くのレプリカが必要になるのは、現場でモバイル デバイスを使用して操作するフィールド担当者にデータを配布する場合です。 2 つのエンタープライズ ジオデータベースを同期させたい場合は、レプリカが 1 つあれば十分でしょう。 レプリカとはどのようなもので、ジオデータベースでどのような役割を果たすのかについては、「レプリカとジオデータベース」をご参照ください。
- レプリケーションの種類を判断する:「レプリケーションの種類」では、利用可能な 3 種類のレプリケーションを説明しています。 システムでは、ケース バイ ケースで種類の異なるレプリカを使い分けなければならないことがあります。 たとえば、別のオフィスとの同期には双方向レプリケーションが適しており、マップ公開用のジオデータベースの更新には一方向レプリケーションを使用することが適してきます。
- レプリカの作成に使用するツールを選択する: ArcGIS には、ジオデータベース レプリケーションを操作するための複数のツールが用意されています。 ツールによって利点はそれぞれ異なります。 次に、各ツールで提供される機能を説明します。
- レプリカ作成ウィザード: レプリカ作成ウィザードには、ArcMap の [分散ジオデータベース] ツールバーからアクセスできます。 このウィザードは多くのオプションで構成されており、ArcMap と密に統合された使いやすいユーザー インターフェイスを備えています。 最初にレプリカを作成する場合、または少数のレプリカを作成する予定である場合は、レプリカ作成ウィザードを使用することが推奨されます。
- [レプリカの作成 (Create Replica)] ジオプロセシング ツール: [レプリカの作成 (Create Replica)] ジオプロセシング ツールも、レプリカの作成に使用できます。 このツールは多くのオプションで構成されていますが、レプリカ作成ウィザードが提供する一部のより高度なオプションが含まれていません。
[レプリカの作成 (Create Replica)] ジオプロセシング ツールは、レプリカを定期的に作成しなければならない場合に適しています。 定期的に実行できるモデルやスクリプトは、ジオプロセシング環境で簡単に構築することができます。 たとえば、現場担当者が日常的に使用するチェックアウト レプリカを作成するためのモデルを構築して保存しておくことができます。 詳細については、[レプリカの作成 (Create Replica)] ジオプロセシング ツールのヘルプをご参照ください。
- ArcObjects API: レプリカを作成するコードを複数の言語のいずれかで記述するために、ArcObjects API も利用できます。 この API は、レプリカの作成方法をカスタマイズしたい場合や、複雑なオプションを持つレプリカを定期的に作成したい場合に役立ちます。
- バージョン対応のワークフローにレプリケーションを統合する: ジオデータベース レプリケーションはバージョニングをベースに構築されています。 レプリカの作成時に、親レプリカと子レプリカの両方にレプリカ バージョンが定義されます。 これは、同期の際に変更を送受信するバージョンです。 詳細については、「レプリカの作成とバージョニング」をご参照ください。
レプリカ バージョンは変更を同期するためのパイプであるため、レプリカを作成する前に、レプリカ バージョンをどのように操作するか計画してください。 たとえば、同期の際に、受信した変更に整合チェックを実行してから、メインのワークフローに統合する計画を立てたとします。 この場合は、同期後にレプリカ バージョンの内容を解析してから、通常の作業バージョンにリコンサイルしてポストします。 また、DEFAULT バージョンをレプリカ バージョンとして使用することもできます。 これは、同期の際に、変更内容を直接 DEFAULT バージョンにポストしたい場合に使用できます。
- 複製するデータを定義する: ジオデータベース レプリケーションでは、エンタープライズ ジオデータベースまたはワークグループ ジオデータベースの一部またはすべてのデータセットを複製できます。 また、フィルターおよびリレーションシップ クラスを使用して、複製するフィーチャまたは行を定義することもできます。 レプリカを作成する際には、常にフィルターが先に適用され、次にフィーチャと行をさらに追加するためにリレーションシップ クラスが使用されます。 詳細については、「レプリケーションのためのデータの準備」をご参照ください。
複製するデータを定義する際には、将来のニーズについて検討します。 たとえば、双方向レプリカと一方向レプリカを一度だけ作成して、繰り返し同期するような場合、 レプリカの作成時に定義したフィルターは、同期時にも適用されます。 時間経過に伴ってニーズが変化し、より大きなレプリカ エリアが必要となることがあります。 また、複製するデータのタイプについて検討することも重要です。 データの整合性を維持するために、ジオメトリック ネットワークやトポロジといったコンプレックス データ タイプを複製する際には、追加のルールが適用されます。 次のヘルプ トピックには、これらのルールの説明と例が記載されています。「ジオメトリック ネットワーク」、「トポロジ」、「リレーションシップ クラス」、「ラスター データ」、「テレインとネットワーク データセット」
- レプリカ作成オプションを検討する: レプリカの作成プロセスをできるだけ効率化するためのオプションがいくつか追加されました。 これらのオプションは特定のケースを対象に設計されているため、ワークフローに適さない場合もあります。 次のリストを参照して、これらのオプションを利用できるかどうか確認してください。
- スキーマの再使用: [スキーマの再使用] オプションを使用して、複製するデータのスキーマがすでに存在するターゲット ジオデータベースを指定します。 これにより、レプリカの作成時にスキーマを作成する必要がなくなるため、時間を節約することができます。 このオプションは、チェックアウト レプリカのみに使用できます。可能であれば、常にこのオプションを使用してください。
- スキーマのみ: [スキーマのみ] オプションを使用して、行 (データ) を含まないレプリカを作成できます。 この場合、レプリカの作成時にコピーされるのはスキーマだけです。 このオプションは、チェックアウト レプリカのみに使用できます。 このオプションを使用する状況としては、新しい情報のみを入力する予定の現場担当者のためにレプリカを作成する場合が挙げられます。 このオプションを使用することで、ウィザードで各データセットをスキーマのみに設定する必要がなくなります。
- 既存データのみ登録: 大量のデータを複製する場合は、[既存データのみ登録] オプションの使用を検討してください。 このオプションを使用することで、レプリカの作成時にデータのコピーを省略し、既存のジオデータベースをレプリカとして登録することができます。 このオプションを使用するには、レプリカを作成する前に特別な手順を実行する必要があります。 ジオプロセシング ツールを使用する場合、このオプションは利用できないことに注意してください。
- 関連データのレプリカ: レプリカの作成時に、複製するデータを決定するために、最初にフィルターが適用され、次にリレーションシップ クラスが処理されます。 リレーションシップ クラスの処理をオフにすると、時間を節約することができます。 リレーションシップ クラスの処理をオフにしても、リレーションシップ クラスは含まれますが、レプリカの作成および同期の際に処理されません。 リレーションシップ クラスの処理をオフにするためのオプションは、レプリカ作成ウィザードとジオプロセシング ツールの高度な設定セクションにあります。 レプリカ作成ウィザードでは、特定のリレーションシップ クラスの処理をオフにすることもできます。
- 履歴管理を使用して変更を追跡: バージョニングに関連付けられた差分テーブルの代わりに、履歴管理を使用して変更を追跡する場合、システムにレプリカ バージョンは作成されません。 そのため、リコンサイル、ポスト、圧縮などのプロセスは影響を受けず、バージョン管理とレプリケーション管理が独立したものになります。 これによって、同期のスケジュールもより柔軟に設定できます。
- 接続環境または非接続環境のどちらを使用するかを検討してください。レプリカは、接続環境と非接続環境のどちらでも作成できます。 接続環境では、同じネットワークに接続されている間に作成と同期が行われます。 非接続環境では、ネットワークが使用されません。 作成と同期を行うには、XML ドキュメントなどのファイルをエクスポートし、そのファイルをターゲットに送信してから、ターゲットにインポートします。 詳細については、「接続環境と非接続環境のレプリケーション」をご参照ください。
信頼性のないネットワークしか使用できない場合は、非接続環境のレプリケーションを使用することも検討してください。 速度の遅いネットワーク上でレプリカ作成プロセスを実行すると、非常に時間がかかり、信頼できない結果になる場合があります。 非接続環境のレプリケーションでは、ファイルにエクスポートした後、情報がネットワーク上で送信されるまで待機せずに引き続き作業を実行できます。 ただし、この場合には、ファイルが失われるといけないので、ターゲットにインポートする前に、これらのファイルのバックアップを作成しておきます。
レプリカの同期
レプリカが作成されたら、レプリカ ジオデータベース間で変更の同期を開始することができます。 詳細については、「同期とは」をご参照ください。 システムを効果的に運用するには、変更を同期するための計画を立てることが重要です。 システムに最適な手法を決定する際には、以下の点を考慮する必要があります。
- 同期の方法: はじめに、システムに最適な同期の方法を決定します。 選択肢は次のとおりです。
- 手動による同期: 操作するレプリカの数が少なく、変更の同期を頻繁に実行する必要がない場合は、ArcGIS に用意されているツールの使用を検討します。 カタログ ツリーの [分散ジオデータベース] ツールバーと [分散ジオデータベース] ショートカット メニューには、同期を実行するためのウィザードが含まれています。 これらのウィザードは、ジオデータベース コネクションと、カタログ ツリーの ArcGIS Server を通じて公開されるジオデータサーバー オブジェクトで利用できます。 これにより、ローカル接続とインターネット経由のリモート接続の両方で、同期を実行できるようになります。 また、[分散ジオデータベース] ジオプロセシング ツールにも、同じ機能を提供するツールがあります。
- エージェントによる自動化された同期: レプリカの数が多いシステムまたは同期が頻繁に行われるシステムでは、レプリケーション エージェントの構築を検討する必要があります。 レプリケーション エージェントは、複製先のジオデータベースに自動的に接続して、同期を実行する仕組みになっています。 この場合、同期は自動的に開始されるため、エンド ユーザーが明示的に実行する必要はありません。 接続された環境では、次の手法を使用して、同期エージェントを構築することができます。
- ジオプロセシング ツールによる同期: ジオプロセシング ツールで、レプリカを同期するためのモデルを簡単に構築することができます。これには、ローカル ジオデータベース接続またはインターネット経由で実行されるジオデータ サーバー オブジェクトへの接続のどちらかを使用します。 これらのモデルを Python スクリプトにエクスポートして、Python で実行することができます。 スクリプトを実行するためのコマンドを Windows スケジューラなどのスケジューリング ソフトウェアに追加すると、コマンドを定期的に実行できます。 たとえば、2 つのエンタープライズ ジオデータベースの同期を週に一度、ピーク時以外の時間帯にスケジュール設定することができます。
- ArcObjects による同期: ArcObjects API を使用して同期を行うこともできます。 この API を使用して、ジオプロセシング ツールによって構築されるものよりも高度な同期エージェントを構築することができます。 たとえば、ノート PC がネットワークに接続したことをオペレーティング システムが検出したときに、ノート PC のレプリカを同期する機能を構築することができます。
- 同期と競合: レプリカのデータに加えられた編集内容が相対レプリカから同期された編集内容と競合している場合は、競合を解決する方法を決定しなければなりません。 リコンサイル ポリシーを適用して競合を自動的に解決するか、後から手動で競合を解決することができます。 システムで競合が発生しているかどうかを確認するには、「同期とバージョニング」をご参照ください。 競合に対処するもう 1 つの方法は、ArcObjects API を使用して、競合を処理するためのシステムを構築することです。 このシステムでは、同期に手動のリコンサイル ポリシーを使用しますが、後から自動的に実行されるセカンダリ プロセスを使用して、発生した競合を自動的に解決します。
- 同期するデータ: チェックアウト レプリカの場合は、子レプリカでのすべてのデータ変更が同期されます。 双方向レプリカと一方向レプリカの場合は、フィルターとリレーションシップ クラスの要件を満たす変更だけが適用されます。 レプリカ マネージャーを使用して、複製先のデータセットに適用されたフィルターとリレーションシップ クラスのルールを特定することができます。 レプリカ フットプリントを作成して、この情報をローカルに保存し、各レプリカの空間フィルターを表示することもできます。
データの整合性を維持するために、ジオメトリック ネットワークやトポロジといったコンプレックス データ タイプを同期する際には、追加のルールが適用されます。 リレーションシップ クラスを処理して、同期するデータを追加することもできます。 さまざまなデータ タイプの同期について理解するには、「トポロジの同期」、「関連データの同期」、「ジオメトリック ネットワークの同期」をご参照ください。
複製することを選択したデータのメタデータは、レプリカ作成プロセス中にコピーされます。メタデータへの変更はレプリカの同期中には適用されません。
- データの量: 同期の際には、最後の同期以降に加えられた変更だけが適用されます。 ArcGIS は、すでに送信および承認された変更を除外します。 また、いったん送信された変更が元のレプリカに返信されることはありません。 このようにして、送信するデータの量を必要なものだけに減らします。
変更がデータに適用される割合に応じて、同期の頻度を計画してください。 変更の量に十分に対応できる頻度で同期を実行しないと、同期処理に時間がかかる場合があります。 また、ピーク時以外の時間帯に同期を実行することも推奨されます。 非接続環境では、データ変更をエクスポートする際に、XML ファイルなどの非圧縮形式ではなく、常に ZIP ファイルを使用する必要があります。 承認メッセージを定期的に送信する作業を取り入れることもお勧めします。
- レプリカを同期する順番: 複数のレプリカを操作する場合は、それらを同期する順番が重要になる可能性があります。 たとえば、単一のジオデータベースから複数の双方向レプリカを作成する場合について考えてみます。 これらのレプリカの同期をとる方法の 1 つは、各子レプリカを親レプリカと双方向で同期させることです。 この場合は、子レプリカが変更を親レプリカに送信し、親レプリカも変更を子レプリカに送信します。 もう 1 つの方法では、各子レプリカが先に変更を親レプリカに送信します。 親レプリカはすべての変更を取り込んだ後、変更を各子レプリカに返送します。 1 つ目の方法では、親レプリカが送信するのは親レプリカでの変更だけですが、2 つ目の方法では、他のすべてのレプリカから取り込まれた変更も送信します。 どちらの方法が適切であるかは、システムの要件によります。
- スキーマの変更: ジオデータベース レプリケーションでは、スキーマの変更が可能です。 これは、複製されたデータにスキーマの変更が加えられた場合でも、引き続き同期が機能することを意味します。 一部の制限を除き、レプリカにまたがってスキーマの変更を適用することが可能です。 詳細については、「スキーマの変更の操作」をご参照ください。
一般に、スキーマの変更は最小限に抑えることをお勧めします。 スキーマの変更を複数のレプリカに適用したい場合は、計画的な手順で実行することが肝心です。 たとえば、複数のレプリカにフィールドを追加する場合は、はじめに、最上位の親レプリカのフィーチャクラスにフィールドを追加します。 次に、下位のすべてのレプリカにスキーマの変更を適用するプロセスに着手します。 詳細については、「スキーマの変更とレプリカ」をご参照ください。
- エラーへの対処: 同期の際には、さまざまな理由でエラーが発生する可能性があります。 接続されているシステムでは、コンピューター ネットワークで障害が発生したり、競合しているレプリカを同期しようとしたりすることがあります。 接続されていないシステムでは、メッセージが失われたり、メッセージを間違った順序でインポートしようとしたりすることがあります。 どのような場合でも、システムは整合性のある状態を維持できるように設計されています。 変更がロールバックされ、不適切なメッセージは破棄されます。 レプリカ アクティビティ ログを使用して、発生したエラーを検索し、復旧方法を判断することができます。 ほとんどの場合は、続けて変更を同期するだけで、システムがエラーから自動的に復旧します。 レプリカには、送信された変更セットの数と受信された変更セットの数を示す世代情報も含まれています。 詳細については、「レプリカの管理」をご参照ください。