Nicht verbundene Synchronisierung

Dieses Thema gilt nur für ArcGIS for Desktop Standard und ArcGIS for Desktop Advanced.

Zum Synchronisieren von Replikaten in einer nicht vernetzten Umgebung müssen Meldungen manuell ausgetauscht werden. Dies wird erreicht, indem eine Meldung von einem Replikat in eine Datei exportiert und aus der Datei in das relative Replikat importiert wird. In nicht vernetzten Systemen können Dateien auf Medien wie CDs oder DVDs gespeichert und über Logistikdienstleister wie private Kurierdienste, die Post usw. gesendet werden.

Ein Replikat kann zu einem gegebenen Zeitpunkt entweder ein Datenabsender oder ein Datenempfänger sein. Ein Datenabsender exportiert Datenänderungsmeldungen in Delta-Dateien. Diese Dateien enthalten Änderungen, die auf das relative Replikat angewendet werden sollen. Ein Datenempfänger exportiert Bestätigungsmeldungen in Bestätigungsdateien, um den Empfang bestimmter Daten zu bestätigen. Sie können festlegen, ob ein Replikat ein Datensender oder ein Datenempfänger ist, indem Sie den Replikatstatus im Replikat-Manager in ArcMap aktivieren. Weitere Informationen zum Replikat-Manager finden Sie unter Kurzer Überblick über die Replikatverwaltung.

Für den Datenempfänger ist es wichtig, Bestätigungsmeldungen so oft wie möglich zu exportieren. Wenn keine Bestätigungsmeldungen empfangen werden, sendet der Datenabsender die Änderungen standardmäßig erneut und bewahrt die zum erneuten Senden erforderlichen Informationen auf, bis die betreffenden Änderungen bestätigt wurden. Aus diesem Grund kann die Geodatabase des Datenabsenders stark anwachsen, und nachfolgende neue Datenänderungsmeldungen können ebenfalls umfangreich ausfallen.

Ein optimales, jedoch nicht erforderliches Verfahren besteht darin, dass der Datenempfänger stets eine Bestätigungsmeldung sendet, wenn eine Datenänderungsmeldung empfangen wurde. Es ist außerdem wichtig zu wissen, dass mit einer Bestätigungsmeldung sämtliche Datenänderungsmeldungen bestätigt werden. Wenn ein Replikat z. B. drei Datenänderungsmeldungen empfängt und importiert, kann es alle drei durch Senden einer einzigen Bestätigungsmeldung bestätigen.

In der folgenden Abbildung wird veranschaulicht, wie ein Parent-Replikat Änderungen an ein Child-Replikat sendet und anschließend eine Bestätigungsmeldung vom Child-Replikat empfängt. In diesem Fall ist das Parent-Replikat der Datenabsender und das Child-Replikat der Datenempfänger.

Bei bidirektionalen Replikaten können der Datenabsender und der Datenempfänger die Rollen auch tauschen. Der Tausch wird vom Datenabsender eingeleitet, wenn er in der letzten Datenänderungsmeldung Anweisungen zum Tauschen der Rollen sendet. Sobald die Meldung vom Datenempfänger importiert wurde, werden die Rollen getauscht, und das System kann die Daten jetzt in der entgegengesetzten Richtung senden.

Die folgende Abbildung zeigt, wie ein Parent-Replikat eine Datenänderungsmeldung mit Anweisungen zum Tauschen der Rollen sendet. Wenn das Parent-Replikat die Meldung exportiert, wird es zum Datenempfänger. Wenn das Child-Replikat die Meldung empfängt, wird es zum Datenabsender. Das Child-Replikat sendet dann eine Datenänderungsmeldung an das Parent-Replikat.

Wie bereits erwähnt, verwenden bidirektionale Replikate Datenänderungs- und Bestätigungsmeldungen und können die Rollen wechseln. Mit unidirektionalen Replikaten ist jedoch kein Rollenwechsel möglich. Bei unidirektionalen Parent-zu-Child-Replikaten übernimmt das Parent-Replikat immer die Rolle des Datenabsenders. Bei unidirektionalen Child-zu-Parent-Replikaten übernimmt das Child-Replikat immer die Rolle des Datenabsenders. In beiden Fällen ist es dennoch wichtig, dass der Datenempfänger Bestätigungsmeldungen so oft wie möglich sendet. Bei Check-Out-Replikaten ist das Child-Replikat stets der Datenabsender. Bestätigungsmeldungen sind nicht erforderlich. Weitere Informationen zu verschiedenen Typen von Replikaten finden Sie unter Replikationstypen.

Bisher wurde in diesem Abschnitt ein einfaches Meldungsaustauschmuster beschrieben, bei dem Meldungen zwischen dem Parent-Replikat und dem Child-Replikat übermittelt werden. Wenn die Meldungen gemäß diesem Muster ausgetauscht werden, funktioniert das System ordnungsgemäß und kann sich beim Verlust von Meldungen sogar selbst korrigieren. Betrachten Sie jedoch auch die folgenden Meldungsaustauschszenarien.

Erneutes Senden von nicht bestätigten Meldungen

Das System ermöglicht es Replikaten, nicht bestätigte Datenänderungen erneut zu senden. Diese Option bietet sich an, wenn Sie als Datenabsender wissen oder annehmen, dass eine frühere Datenänderungsmeldung verloren gegangen ist und erneut gesendet werden muss. Eine weitere Option besteht darin, bis zum nächsten Senden von Datenänderungen zu warten, weil Datenänderungsmeldungen standardmäßig sowohl alle neuen als auch alle noch nicht bestätigten Änderungen enthalten.

Die folgende Abbildung zeigt eine Situation, in der Sie nicht bestätigte Datenänderungen erneut senden müssen. Hierbei sendet das Parent-Replikat eine Datenänderungsmeldung und wechselt von der Absender- in die Empfängerrolle. Die Meldung geht jedoch verloren, wodurch sowohl das Parent-Replikat als auch das Child-Replikat zu Datenempfängern werden. Um dieses Problem zu lösen, kann der Datenempfänger, mit dem eben die Rollen getauscht wurden, die nicht bestätigten Meldungen erneuten exportieren. In der vorliegenden Situation kann das Parent-Replikat die Meldung erneut senden, um die Rollen mit dem Child-Replikat zu tauschen.

Bestätigen von Änderungen nach dem Tausch von Rollen

Nach dem Rollenwechsel in einem bidirektionalen Replikat kann der Datenabsender eine Bestätigungsmeldung exportieren, um die Meldung zu bestätigen, aufgrund der die Rollen getauscht wurden. Eine weitere Möglichkeit besteht darin, eine Datenänderungsmeldung zu senden, weil die aktuelle Meldung durch diese Meldung implizit bestätigt wird. Wenn Sie jedoch für die nähere Zukunft keine Datenänderungsmeldungen planen, sollten Sie eine Bestätigungsmeldung senden.

Die folgende Abbildung verdeutlicht, wie ein Parent-Replikat eine Datenänderungsmeldung sendet, aufgrund der die Rollen getauscht werden. Wenn das Child-Replikat die Meldung empfängt, wird es zum Datenabsender. Da die Rollen jedoch gerade erst getauscht wurden, darf es noch eine Bestätigungsmeldung senden.

Tauschen von Rollen ohne Senden von Datenänderungen

Eine Datenänderungsmeldung kann auch mit Anweisungen zum Tauschen der Rollen, aber ohne Datenänderungen gesendet werden. Dies empfiehlt sich, wenn Sie als Datenabsender Änderungen vom Datenempfänger benötigen, selbst jedoch keine Datenänderungen senden möchten. Weitere Informationen zum Senden einer Meldung mit dem Ziel, Rollen ohne das Senden von Daten zu tauschen, finden Sie unter Exportieren einer Datenänderungsmeldung.

Umgehen der Bestätigungsmeldungsdatei

Wenn Sie Datenänderungen senden, werden in der Standardeinstellung alle neuen Datenänderungen und alle nicht bestätigten Datenänderungen gesendet. Als neue Änderungen werden alle Einfügungen, Aktualisierungen und Löschungen in der Replikatversion seit dem letzten Export einer Datenänderungsmeldung behandelt. Zu den nicht bestätigten Datenänderungen zählen bereits exportierte Änderungen, für die Sie noch keine Bestätigung empfangen haben. Wenn Sie mehrere Datenänderungsmeldungen gesendet haben, für die Sie noch keine Bestätigung empfangen haben, können die Datenänderungsdateien umfangreich ausfallen.

Die beste Lösung besteht darin, dass der Datenempfänger eine Bestätigungsmeldungsdatei sendet. Je nach Kommunikationssystem ist dies möglicherweise nicht immer möglich. Wenn die Replikate beispielsweise getrennt sind und zum Senden einer Bestätigungsdatei das Versenden von Medien zum Austauschen von Dateien erforderlich ist, ist es eventuell empfehlenswert, eine E-Mail an die Person zu senden, die das Datenabsenderreplikat verwaltet, um zu bestätigen, dass Sie die Datenänderungen empfangen und importiert haben.

Beachten Sie, dass das Umgehen der Bestätigungsmeldungsdatei eine komplizierte Synchronisierungsverwaltung zur Folge haben kann.

• Der Import von Bestätigungsmeldungen ist die einzige Möglichkeit für das System, Systemversionen zu löschen, die zum erneuten Senden von Änderungen für ein Replikat erforderlich sind. Nicht gelöschte Systemversionen können mit der Zeit die Komprimierung behindern, zum Anwachsen der Geodatabase beitragen und die Performance der Geodatabase verlangsamen. Aus diesem Grund ist es wichtig, Bestätigungsmeldungen zumindest regelmäßig zu senden.
• Das Umgehen der Ergebnisse von Bestätigungsmeldungsdateien führt dazu, dass seitens der Person, die das Datenabsenderreplikat verwaltet und seitens der Person, die den Datenempfänger verwaltet, ein höheres Maß an manueller Intervention erforderlich ist.

  Mit dem Replikat-Manager können Sie ermitteln, welche Änderungen gesendet und von einem Replikat empfangen wurden. Um zu verhindern, das eine unnötig große Datenänderungsmeldung gesendet wird, muss der Datenabsender die Option Unbestätigte Datenänderungen einbeziehen beim nächsten Senden von Datenänderungen deaktivieren.

• Wenn Sie die Verwendung der Bestätigungsmeldungsdatei umgehen möchten, ist der Synchronisierungs-Workflow fehleranfälliger.

  Neue Änderungen können vom Datenempfänger nur dann importiert werden, wenn vorherige Änderungen tatsächlich importiert wurden. Wenn das System erkennt, dass zuvor gesendete Änderungen nicht importiert wurden, wird ein Fehler zurückgegeben und die aktuellen Änderungen können nicht importiert werden. Wenn mehrere Datenänderungsmeldungen gemeinsam gesendet werden, müssen diese in der richtigen Reihenfolge importiert werden. Wenn Sie versuchen, den Import in einer falschen Reihenfolge vorzunehmen, gibt das System eine Fehlermeldung zurück.

  Bei Fehlern werden Fehlermeldungen ausgegeben. Wenn Sie jedoch ein automatisiertes System verwenden, sind Sie möglicherweise nicht anwesend und bemerken die Fehler nicht. In diesem Fall können Sie im Replikataktivitätsprotokoll ermitteln, ob während der Synchronisierung Fehler aufgetreten sind. Das Protokoll enthält ggf. auch Anweisungen für die Wiederherstellung.