Mit der Standard- oder Advanced-Lizenz verfügbar.
Die Geodatabase-Replikation beruht auf der Versionierung. Bei der Replikaterstellung werden Versionen der Quell- und Ziel-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. Informationen zum Festlegen der Replikatversion für das Parent- oder Child-Replikat finden Sie im Thema Erstellen eines Check-Out-Replikats.
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 wie V1 und V2, die unten dargestellt werden. Da File- und Personal-Geodatabase-Typen die Versionierung nicht unterstützen, wird in der zweiten unidirektionalen Replikation (siehe rechts) keine Replikatversion in der Child-Geodatabase erstellt.
Mit der Check-Out-/Check-In-Replikation können versionierte und nicht versionierte Daten repliziert werden. Das Child-Replikat kann in einer Personal-, File- oder 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 Child-Replikatdaten zu bearbeiten, stellen Sie eine Verbindung mit der Enterprise-Geodatabase her, und ändern Sie die Version im Dialogfeld Version ändern in die Child-Replikatversion. Nach dem Herstellen der Verbindung mit der Child-Replikatversion können Sie eine Bearbeitungssitzung starten. Die Änderungen müssen in der Child-Replikatversion vorgenommen werden, um sie mit dem Parent-Replikat synchronisieren zu können.
Mit der Check-Out-/Check-In-Replikation können auch Personal- oder 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-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-Geodatabase gehostet (dies kann auch eine Personal-Geodatabase sein), das andere von einer Enterprise-Geodatabase. 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 der Replikatversion in der Parent-Version, die zur Erstellung verwendet wurde, übernommen.
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- und Personal-Geodatabase-Typen die Versionierung nicht unterstützen, wird keine Replikatversion für die Child-File- oder -Personal-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.
