Replikation und Versionierung

Mit der Standard- oder Advanced-Lizenz verfügbar.

Die Geodatabase-Replikation beruht auf der traditionellen Versionierung. Bei der Replikaterstellung werden Versionen der Quell- und Ziel-Enterprise-Geodatabases als Replikatversionen festgelegt. Änderungen an diesen Replikatversionen werden während der Synchronisierung ausgetauscht. Da die Replikatversionen verknüpft sind, können Sie sie sich als eine Art von Erweiterung des Versionsverzeichnisses vorstellen, das mehrere Geodatabases abdeckt.

Die Default-Version oder eine beliebige benannte Version kann als Replikatversion für das Parent- oder Child-Replikat verwendet werden. Zudem können mehrere Replikate die gleiche Replikatversion aufweisen.

Unidirektionale und bidirektionale Replikate

Das folgende Diagramm zeigt die Replikatversionen für unidirektionale und bidirektionale Replikate. Bei der bidirektionalen Replikation verwendet das Parent-Replikat die benannte Version RV1 als Replikatversion. Im Beispiel der unidirektionalen Replikation verwendet das Parent-Replikat die benannte Version RV2 als Replikatversion für beide Beispiele.

Für beide in Enterprise-Geodatabases gehostete Child-Replikate ist die Default-Version die Replikatversion. Abgesehen von der Tatsache, dass sie für die Replikation verwendet werden, unterscheiden sich Replikatversionen nicht von anderen Versionen. Da File-Geodatabases Versionierung nicht unterstützen, wird bei einem unidirektionalen Replikat keine Replikatversion in der Child-Geodatabase erstellt.

Hinweis:

Zudem ist es im folgenden Diagramm möglich, in den Enterprise-Geodatabases eine benannte Version als Replikatversion zu verwenden.

Check-Out-Replikate

Mit der Check-Out-/Check-In-Replikation können versionierte und nicht versionierte Daten repliziert werden, und das Child-Replikat kann in einer File-Geodatabase oder einer Enterprise-Geodatabase gehostet werden.

Wenn ein Child-Replikat in einer Enterprise-Geodatabase gehostet wird, wird eine Version mit einem neuen Namen erstellt, um das Bearbeiten zu vereinfachen und als Replikatversion des Child-Replikats zu fungieren. Der Name der Child-Replikatversion ist identisch mit dem Namen des Replikats. Um die Daten des Child-Replikats zu bearbeiten, stellen Sie eine Verbindung zur Enterprise-Geodatabase her, und verwenden Sie entweder das Dialogfeld Geodatabase-Verbindungseigenschaften oder das Dialogfeld Version ändern, um die Version in die Child-Replikatversion zu ändern. Nachdem Sie eine Verbindung zur Child-Replikatversion hergestellt haben, können Sie eine Editiersitzung starten. Die Änderungen müssen in der Child-Replikatversion vorgenommen werden, um sie mit dem Parent-Replikat synchronisieren zu können.

Bei Verwendung der Check-Out-/Check-In-Replikation wird eine neue Version mit dem Namen des Replikats erstellt. Die Kombination aus Benutzername und Replikatname muss eindeutig sein. User1 und User2 können z. B. jeweils ein Replikat mit dem Namen MyReplica erstellen, da die vollständigen Replikatnamen user1.MyReplica und user2.MyReplica lauten. User1 kann jedoch nicht mehr als ein Replikat mit dem Namen MyReplica erstellen, weil der Replikatname dann nicht eindeutig wäre.

Mit der Check-Out-/Check-In-Replikation können auch File-Geodatabases Child-Replikate hosten. Da dieser Geodatabase-Typ keine Versionierung unterstützt, wird für das Child keine Replikatversion erstellt. Dies ist auch beim Auschecken nicht versionierter Daten der Fall. In diesen Szenarien wird eine zusätzliche Logik eingesetzt, um die Änderungen zu ermitteln, die während der Synchronisierung gesendet werden.

Das folgende Diagramm zeigt zwei Beispiele für Check-Out-/Check-In-Replikate und deren Replikatversionen. Ein Parent-Replikat verwendet Version RV1 als Replikatversion, das andere verwendet Version RV2 als Replikatversion. Ein Child-Replikat wird von einer File- und das andere von einer Enterprise-Geodatabase gehostet. Für die Enterprise-Geodatabase, die das Child-Replikat hostet, wurde RV2 automatisch erstellt und bei der Erstellung als Replikatversion festgelegt. Der Name RV2 für diese Replikatversion wurde vom Namen des Replikats übernommen. In dieser Replikatversion werden Änderungen am Child vorgenommen, die mit dem Parent synchronisiert werden.

Detailinformationen:

Für Check-Out-/Check-In-Replikate wird während der Erstellung eine Synchronisierungsversion zur Geodatabase des Parent-Replikats hinzugefügt. Die Synchronisierungsversion ist ein Child der Replikatversion. Sie wird jedoch oben nicht dargestellt, da sie nur während der Synchronisierung verwendet wird. Weitere Informationen finden Sie unter Synchronisierung und Versionierung.

Verwenden der Archivierung zum Nachverfolgen von Replikatänderungen

Nur bei der unidirektionalen Replikation können Sie statt der Versionierung die Archivierung nutzen, um Replikatänderungen nachzuverfolgen. Für diese Option muss die Parent-Geodatabase eine Enterprise-Geodatabase sein, die die Default-Version referenziert. Der Vorteil einer Verwaltung der Replikation auf diese Weise ist, dass Abgleichen, Zurückschreiben und Komprimieren unabhängig von der Synchronisierung ausgeführt werden.

Wenn die Versionierung zum Nachverfolgen von Änderungen verwendet wird, werden Systemversionen erstellt. Wegen dieser Systemversionen müssen Sie regelmäßig eine Synchronisierung durchführen, um eine effektive Komprimierung zu erreichen. Wenn die Archivierung zum Nachverfolgen von Replikatänderungen verwendet wird, werden keine Systemversionen erstellt. Daher ist das Abgleichen, Zurückschreiben und Komprimieren nicht betroffen, sodass die Versionsverwaltung und Replikationsverwaltung unabhängig erfolgen kann. Außerdem kann der Zeitplan für die Synchronisierung dann flexibler gestaltet werden. Um Replikatänderungen mittels Archivierung zu verfolgen, müssen die Quelldaten als versioniert in der Enterprise-Geodatabase registriert sein, und die Quell-Replikatversion muss als Default-Version festgelegt sein.

Im folgenden Diagramm wird eine unidirektionale Parent-zu-Child-Replikation mittels Archivierung zwischen Enterprise-Geodatabases dargestellt. Dabei wird die Default-Version als Replikatversion für die Parent- und Child-Replikate in der Enterprise-Geodatabase verwendet. Da File-Geodatabases Versionierung nicht unterstützen, wird keine Replikatversion in der Child-Geodatabase erstellt.

Die unidirektionale Child-zu-Parent-Replikation kann auch verwendet werden, wenn beide Geodatabases Enterprise-Geodatabases sind. In diesem Fall muss die Child-Replikatversion die Default-Version sein.