非接続環境での同期

このトピックは、ArcEditor および ArcInfo にのみ適用されます。

このトピックでは、非接続環境で実行される同期について説明します。

非接続環境のレプリカを同期させるには、ユーザが手動でレプリカ間のメッセージ交換を行う必要があります。これは、あるレプリカからメッセージをファイルにエクスポートした後、ファイルのメッセージを相対レプリカにインポートする、という方法で行われます。非接続環境では、ファイルを CD や DVD などのメディアに焼き、配送業者に配達してもらうなどの方法でデータの受け渡しを行うことになります。

レプリカは常にデータの送り手またはデータの受け手になります。レプリカがデータの送り手と受け手のどちらであるかを判断する方法については、「レプリカ管理のクイック ツアー」をご参照ください。データの送り手は、データ変更メッセージをデルタ ファイルにエクスポートします。デルタ ファイルには、相対レプリカに適用する変更内容が含まれています。データの受け手は、承認メッセージを承認ファイルにエクスポートして、受け取った変更を承認します。

データの受け手は、承認メッセージをできるだけ頻繁にエクスポートし送り手に送信することが重要となります。送り手側に受け手側からの承認メッセージが受信されない場合、データの送り手は変更内容を再送します。またそれらの変更が承認されるまで、変更内容を再送するのに必要な情報を維持し続けます。このため、データの送り手のジオデータベースのサイズが増えるだけでなく、新しいデータ変更メッセージに再送される変更メッセージが含まれるため、メッセージのデータ サイズが増える可能性があります。

必須ではありませんが、データの受け手は、データ変更メッセージを受信するたびに承認メッセージを送り手側に送信するのが理想的です。ただし、 1 つの承認メッセージはそのレプリカのすべてのデータ変更メッセージを承認するため、1 つの承認メッセージですべてのデータ変更メッセージを承認することも可能です。たとえば、レプリカが 3 つのデータ変更メッセージを受信した場合、それらを変更メッセージを 1 つの承認メッセージを送信することで承認することができます。

次の図では、親レプリカがデータ変更メッセージを子レプリカに送信した後、子レプリカから承認メッセージを受信しています。この場合は、親レプリカがデータの送り手、子レプリカがデータの受け手です。

データの送り手とデータの受け手の役割を交換することもできます。役割の交換は、データの送り手が最後のデータ変更メッセージを送信し、そのメッセージに役割を交換するための指示が含まれていた場合に開始されます。メッセージがデータの受け手によってインポートされた時点で、役割が交換され、システムがデータを反対方向に送信できる状態になります。

次の図では、親レプリカが役割の交換を指示するデータ変更メッセージを送信しています。親レプリカは、メッセージをエクスポートした時点で、データの受け手になります。子レプリカは、メッセージをインポートした時点で、データの送り手になり、変更メッセージを親レプリカに送信できるようになります。

メッセージの交換は、レプリカの種類によって決まります。双方向レプリカは、データ変更メッセージと承認メッセージを使用し、役割を交換することができます。一方向レプリカの場合、親レプリカは常にデータの送り手であり、役割を交換することはできませんが、子レプリカが承認メッセージを送信することが必要です。チェックアウト レプリカの場合、子レプリカは常にデータの送り手であり、承認メッセージは必要ありません。

上記は、親レプリカと子レプリカの間でメッセージがやり取りされる、基本的なメッセージ交換パターンを表しています。このパターンを継続すれば、システムは正常に機能し、メッセージが紛失した場合でも自動的に修正されます。ただし、次に示すように、メッセージ交換のシナリオについて検討しなければならないケースもあります。

非承認メッセージの再送

レプリカは承認されていないデータ変更を再送することもできます。これが必要になるのは、データの送り手から送信されたデータ変更メッセージが紛失したかその疑いがあるために、再送しなければならない場合です。あるいは、メッセージの再送を次にデータ変更を送信するまで待つこともできます。データ変更メッセージには、デフォルトで、新しいデータ変更と非承認のデータ変更の両方が含まれるためです。

次の図は、非承認の変更を再送しなければならないケースを示しています。この場合、親レプリカはデータ変更メッセージを送信し、送り手と受け手を切り替えます。ところが、メッセージが紛失したために、親レプリカと子レプリカの両方がデータの受け手になってしまいます。この問題を解決するために、役割を交換したばかりのデータの受け手が必要に応じて非承認メッセージを再送することができます。この場合、親レプリカは役割を交換するためのメッセージを子レプリカに再送することができます。

役割を交換した後の変更の承認

役割を交換した後、データの送り手は役割交換メッセージを承認するために、承認メッセージをエクスポートすることができます。あるいは、このメッセージを暗黙的に承認することになるデータ変更メッセージを送信することもできます。ただし、すぐにデータ変更メッセージを送信する予定がない場合は、役割交換メッセージを承認する承認メッセージを送信することが推奨されます。

次の図では、親レプリカが役割を交換するデータ変更メッセージを送信しています。メッセージを受信した子レプリカはデータの送り手になりますが、役割を交換した直後のレプリカは役割交換メッセージを承認する承認メッセージを送信することができます。

データ変更なしでの役割の交換

役割の交換のみでデータ変更を含まないデータ変更メッセージを送信することも可能です。これが必要になるのは、データの送り手がデータの受け手から変更を取得する必要があり、送り手側からは、まだデータ変更を送信する準備ができていない場合です。データをまったく送信せずに、役割を交換するためのメッセージを送信する方法については、「データ変更メッセージのエクスポート」をご参照ください。

口頭での承認

データ変更を送信する際、デフォルトでは、すべての新しいデータ変更と非承認のデータ変更が送信されます。新しいデータ変更とは、最後のデータ変更メッセージがエクスポートされた後にレプリカ バージョンに適用されたすべての挿入、更新、削除です。非承認のデータ変更には、エクスポート済みの変更のうち、承認メッセージを受信していない変更です。送信済みのデータ変更に対して承認メッセージを受信していないものが多数ある場合、データ変更メッセージのデータ サイズが大きくなる可能性があります。

最も効果的な解決策は、データの受け手が承認メッセージを送信することです。ただし、状況によっては、これが難しい場合があります。

代替策は、口頭での承認を使用することです。この場合、データの送り手は、データ変更を受信したデータの受け手を管理しているユーザから、口頭で承認を受けます。レプリカによって送信および受信された変更は、レプリカ マネージャを使用して確認することができます。口頭での承認により、データの送り手は新しい変更だけを送信します。データの受け手は、送信済みのデータ変更を受信していることを正しく報告している場合に限り、この新しい変更をインポートすることができます。送信済みのデータ変更がインポートされていないことが検出された場合は、エラーになります。複数のデータ変更メッセージが一度に送信された場合には、正しい順序でインポートしなければなりません。不正な順序でインポートを試みた場合もエラーになります。

エラーが発生した場合は、エラー メッセージが送信されます。ただし、自動化されたシステムを使用している場合には、ユーザにエラーが表示されない可能性があります。この場合、同期中に発生したエラーは、レプリカ アクティビティ ログで検出することができます。レプリカ ログには、必要に応じて、復旧方法に関する指示も含まれています。

口頭での承認は、承認メッセージを使用することと同じではありません。承認メッセージのインポートは、レプリカの変更を再送するために必要な、システム管理のバージョンを削除するための唯一の手段です。これらのシステム バージョンは徐々に圧縮の妨げとなり、データの送り手のジオデータベースを肥大化させる原因となります。このため、口頭での承認を使用する場合であっても、承認メッセージを定期的に使用することが重要です。