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. Bei Check-Out-Replikaten mit versionierten Daten wird eine neue benannte Version erstellt. Sie dient als Child-Replikatversion, wenn das Child eine Enterprise-Geodatabase ist.
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.
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 "EigenesReplikat" erstellen, da die vollständigen Replikatnamen "User1.EigenesReplikat" und "User2.EigenesReplikat" lauten. User1 kann jedoch nicht mehr als ein Replikat mit dem Namen "EigenesReplikat" erstellen, weil der Replikatname dann nicht eindeutig wäre.
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 das 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.
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.
