Replikaterstellung und Versionierung

Dieses Thema gilt nur für ArcEditor und ArcInfo.

Die Replikation von Geodatabases baut auf der Versionierung auf. Bei der Replikaterstellung werden Versionen aus der Quell- und der Ziel-Geodatabase als Replikatversionen festgelegt. Bei der Synchronisierung werden die Änderungen an diesen Replikatversionen ausgetauscht. Da die Replikatversionen miteinander verknüpft sind, können Sie sich diese als Erweiterung der Versionsstruktur auf mehrere Geodatabases vorstellen.

Als Replikatversion für das Parent- oder das Child-Replikat kann die Default-Version oder eine beliebige benannte Version verwendet werden. Zudem kann eine Replikatversion von mehreren Replikaten verwendet werden. Informationen zum Festlegen der Replikatversion auf dem Parent oder dem Child finden Sie unter Erstellen eines Replikats.

Im folgenden Diagramm werden die Replikatversionen für unidirektionale und bidirektionale Replikate angezeigt. Bei bidirektionaler Replikation verwendet das Parent-Replikat die benannte Version RV1 als Replikatversion. Das Parent-Replikat in den Beispielen für die unidirektionale Replikation verwendet die benannte Version RV2 als Replikatversion für beide Beispiele.

Hinweis:

Alle Replikate hätten auch aus der gleichen benannten Version, aus der Default-Version oder einer beliebigen Kombination aus benannten Versionen und/oder der Default-Version erstellt werden können.

Für beide Child-Replikate, die in ArcSDE-Geodatabases gehostet werden, ist die Default-Version die Replikatversion. Abgesehen davon, dass sie für die Replikation verwendet werden, unterscheiden sich die Replikatversionen nicht von anderen Versionen, z. B. von den unten dargestellten Versionen V1 und V2.

Hinweis:

In der Abbildung unten wäre es auch möglich gewesen, in einer der ArcSDE-Geodatabases eine benannte Version als Replikatversion zu verwenden.

Da File- und Personal-Geodatabases Versionierung nicht unterstützen, wird für das Child-Replikat in der zweiten unidirektionalen Replikation keine Replikatversion erstellt (rechts).

Bei der Check-Out-Replikation können sowohl versionierte als auch nicht versionierte Daten repliziert werden. Bei Check-Out-Replikaten mit versionierten Daten wird eine neue benannte Version erstellt, die als Replikatversion für das Child-Replikat dient.

Bei der Check-Out-/Check-In-Replikation können auch Personal- oder File-Geodatabases Child-Replikate hosten. Da diese Arten von Geodatabases keine Versionierung unterstützen, wird für das Child-Replikat keine Replikatversion erstellt. Dies gilt auch für das Auschecken von nicht versionierten Daten. Bei diesen Szenarien werden die Änderungen, die bei der Synchronisierung übertragen werden sollen, durch zusätzliche Programmlogik ermittelt.

Im folgenden Diagramm werden zwei Beispiele für Check-Out-Replikate und deren Replikatversionen gezeigt. Ein Parent-Replikat verwendet RV1 als Replikatversion, das andere Parent-Replikat RV2. Ein Child-Replikat wird in einer File-Geodatabase gehostet (oder auch in einer Personal-Geodatabase), das andere in einer ArcSDE-Geodatabase. Für die ArcSDE-Geodatabase, in der das Child-Replikat gehostet wird, wurde RV2 automatisch erstellt und dabei als Replikatversion für das Replikat festgelegt. Der Name RV2 für diese Replikatversion wurde vom Namen der Replikatversion im Parent-Replikat übernommen, das für die Erstellung verwendet wurde.

Bei Check-Out-Replikaten wird der Geodatabase des Parent-Replikats bei der Erstellung eine Synchronisierungsversion hinzugefügt. Die Synchronisierungsversion ist eine Child-Version der Replikatversion. Sie wird oben jedoch nicht gezeigt, weil sie nur bei der Synchronisierung verwendet wird. Unter Synchronisierung und Versionierung finden Sie weitere Informationen.

Verwenden der Archivierung zum Verfolgen von Replikatänderungen

Für die unidirektionale Replikation können Sie angeben, dass Replikatänderungen mithilfe der Archivierung statt der Versionierung nachverfolgt werden sollen. Um diese Option nutzen zu können, muss die Quellversion des Replikats die DEFAULT-Version sein.

Der Vorteil bei dieser Art der Replikationsverwaltung besteht darin, dass das Abgleichen, Zurückschreiben und Komprimieren separat vom Synchronisierungsvorgang erfolgt. Wenn die Versionierung zum Verfolgen von Änderungen verwendet wird, werden Systemversionen erstellt. Aufgrund dieser Systemversionen müssen Sie regelmäßig eine Synchronisierung durchführen, um eine effektive Komprimierung zu erzielen.

Wenn die Archivierung zum Verfolgen 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.

Da die Archivierung eine Versionierung der Daten erfordert, muss sich das Quellreplikat in einer ArcSDE-Geodatabase befinden. Die Quellversion des Replikats muss gleichzeitig die DEFAULT-Version sein.

In der Abbildung unten ist die unidirektionale Replikation vom Typ "Parent zu Child" zwischen ArcSDE-Geodatabases dargestellt, wobei die DEFAULT-Version sowohl für den Parent als auch für das Child als Replikatversion verwendet wird. Da File- und Personal-Geodatabases die Versionierung nicht unterstützen, wird für das Child-Replikat im anderen unidirektionalen Replikat keine Replikatversion erstellt (dargestellt in der Abbildung).

Die unidirektionale Child-zu-Parent-Replikation kann auch verwendet werden, wenn es sich bei beiden Geodatabases um ArcSDE-Geodatabases handelt. Die Version des Child-Replikats muss in diesem Fall die DEFAULT-Version sein.