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