Das Abgleichen einer Version ist langsam oder nimmt viel Zeit in Anspruch

Beschreibung

Beim Durchführen eines Abgleichs ist der Abgleichvorgang in einigen Fällen langsam oder nimmt viel Zeit in Anspruch.

Beim Durchführen eines Abgleichs ist es wichtig zu verstehen, welcher Prozess intern ausgeführt wird und warum der Workflow einer Organisation erhebliche Auswirkungen auf die Abgleich-Performance haben kann.

Hinweis: Dieser Artikel gilt für die ArcGIS-Versionen 8.x und 9.x. Höhere Versionen von ArcGIS enthalten möglicherweise andere Funktionalität sowie andere Namen für Menüs, Befehle und Geoverarbeitungswerkzeuge, die sich auch an anderen Orten befinden können.

Ursache

Während eines Abgleichs werden alle Bearbeitungen in der Quellenversion, also der bearbeiteten und mit einer Zielversion abgeglichenen Version (wobei die Zielversion die Primär- oder DEFAULT-Version ist), in die Zielversion kopiert. Etwaige Konflikte werden erkannt und im Dialogfeld "Konfliktlösung" angezeigt.

Die für den Abgleich erforderliche Zeit ist abhängig von der Anzahl der Bearbeitungen. Um besser zu verstehen, warum die Abgleichdauer von der Anzahl der Bearbeitungen abhängt, müssen Sie den State-Tree der versionierten Geodatabase verstehen.

Jede Bearbeitung in einer versionierten Geodatabase wird durch eine "state_id" eindeutig identifiziert. Die Sammlung von Zuständen in einer versionierten Geodatabase wird als State-Tree bezeichnet. Jeder Zustand ist Teil einer State-Lineage mit dem Ursprung "Zustand 0" als Basiszustand. Jede Lineage im State-Tree repräsentiert unterschiedliche Editiersitzungen oder unterschiedliche Versionen.

Die einzige Beziehung des State-Tree zu einer Version ist der Zustand, den die Version referenziert. Die Versionshierarchie hat jedoch Einfluss darauf, welche Versionen abgeglichen werden können. Ein Abgleich kann nur für eine Version und einen direkten Vorgänger, beispielsweise die Primärversion oder die Vorversion der Primärversion usw., durchgeführt werden.

Damit ist die Beziehung zwischen Versionen und Geodatabase-Zuständen jedoch nicht vollständig abgebildet. Im folgenden Beispiel ist Version "Editor2" eine Sekundärversion, die aus der Version "Trans_mnt" erstellt wurde. Die Struktur des State-Tree und auf welche Weise Versionen spezifischen Zuständen entsprechen, ist jedoch nicht sichtbar.

In dieser Hierarchie kann "Editor1" mit "Trans_mnt" oder DEFAULT abgeglichen werden.

Beim Abgleich einer Version mit einer Zielversion werden alle Bearbeitungen in der Lineage der Quellenversion, die nicht mit der Lineage der Zielversion übereinstimmen, in einen neuen Zustand in der Zielversion-Lineage kopiert. Im folgenden Beispiel haben "Trans_mnt" und "Editor1" den gemeinsamen Vorgängerzustand 40.

Hier sind die folgenden Lineages für die Versionen zu sehen:

• Trans_mnt: 0, 40, 41, 52
• Editor1: 0, 40, 78, 92, 97
• Editor2: 0, 40, 56

Der oberste Zustand ist in der Lineage beider Versionen identisch. Die nicht in Konflikt stehenden Bearbeitungen für die Zustände 78, 92 und 97 werden jeweils in die Zielversion-Lineage kopiert. Die eindeutigen Zustände für die Lineage von "Editor1" (78, 92 und 97) werden in einen neuen Zustand in der Lineage von "Trans_mnt" kopiert. Der neue Zustand in der Geodatabase ist Zustand 99.

Im Diagramm oben ist nicht angegeben, wie viele Bearbeitungen die Zustände 78, 92 und 97 umfassen. Wenn pro Zustand nur eine Bearbeitung für eine Feature-Class vorliegt, enthält der Abgleichzustand 99 nur drei Bearbeitungen, die in den Zuständen 78, 92 und 97 durchgeführt wurden. Daraus resultieren 3 neue Zeilen in den Adds- und Deletes-Tabellen der Feature-Classes.

Wenn für Zustand 92 jedoch 50.000 Features aktualisiert werden, müssen während des Abgleichvorgangs alle 50.000 Bearbeitungen in Zustand 99 kopiert und in die Adds- und Deletes-Tabellen der Feature-Classes eingefügt werden. Es gäbe dann also 50.000 Bearbeitungen für Zustand 92 und weitere 50.000 Bearbeitungen für Zustand 99.

Zusätzlich muss die Geodatabase Änderungen zwischen den beiden Lineages der Version erkennen, um während des Abgleichs Konflikte zu identifizieren. Konflikte werden in folgende Gruppen kategorisiert:

• Updates-Update-Konflikte
• Update-Delete-Konflikte
• Delete-Update-Konflikte

Nicht in Konflikt stehende Bearbeitungen oder mit in Konflikt stehenden Objekten in Beziehung stehende Bearbeitungen werden in den Abgleichzustand der Zielversion kopiert. In Konflikt stehende Bearbeitungen werden im Dialogfeld "Konfliktlösung" angezeigt.

Die Anzahl der Bearbeitungen in der Lineage der Quellenversion wirkt sich auf die Abgleich-Performance aus.

In Workflows muss dies entsprechend berücksichtigt werden.

Lösung oder Problemumgehung

Beim Arbeiten mit einer versionierten Geodatabase ist der Workflow für das Erstellen und Abgleichen von Versionen sehr wichtig. Bei mehreren Sekundärversionen einer Primärversion ist die Reihenfolge, in der die Sekundärversionen abgeglichen und in die Primärversion zurückgeschrieben werden, ebenfalls von Bedeutung.

Wenn die Zielversion seit der Erstellung und Bearbeitung der Quellenversion nicht geändert wurde, müssen beim Abgleichvorgang keine Änderungen kopiert werden, da alle Versionen dieselbe Lineage aufweisen. In diesen Fällen werden die Quellen- und die Zielversion aktualisiert und referenzieren denselben Datenbankzustand, wenn sie vom Benutzer nach dem Abgleich zurückgeschrieben werden.

Im folgenden Beispiel wurde die Version "Trans_mnt" bzw. die Primärversion nicht geändert, seit die Versionen "Editor1" und "Editor2" erstellt wurden. Die Version "Trans_mnt" referenziert Zustand 40, also den gemeinsamen Vorgängerzustand der Versionen "Editor1" und "Editor2".

Das folgende Beispiel zeigt den State-Tree vor dem Abgleich. Die Lineages für die Versionen lauten wie folgt:

• Trans_mnt: 0, 40
• Editor1: 0, 40, 78, 92, 97
• Editor2: 0, 40, 56

Beachten Sie, dass die Version "Trans_mnt" Zustand 40 referenziert. Die Lineage der Version "Editor1" lautet 0, 40, 78, 92, 97.

Wenn "Editor1" mit der Version "Trans_mnt" abgeglichen wird, ist es nicht erforderlich, alle Bearbeitungen aus der aktuellen Lineage von "Editor1" in einen neuen Zustand für die Version "Trans_mnt" zu kopieren.

Das folgende Beispiel zeigt den State-Tree nach dem Abgleich. Version "Editor1" wird mit Version "Trans_mnt" abgeglichen. In diesem Fall referenziert die Version "Trans_mnt" einen Zustand aus derselben Lineage wie "Editor1", sodass die Bearbeitungen nicht in einen Abgleichzustand kopiert werden müssen.

Wenn in Zustand 92 50.000 Aktualisierungen durchgeführt wurden, werden die Bearbeitungen nicht in Zustand 99 kopiert, da sie in der Lineage der Version bereits vorhanden sind. In diesem Fall ist der Abgleich sehr schnell, da keine Konflikte erkannt und keine Bearbeitungen in den Zustand einer Zielversion kopiert werden müssen.

Wenn auf den Befehl "Zurückschreiben" geklickt wird, referenzieren die Versionen "Editor1" und "Trans_mnt" denselben Zustand, also Zustand 99.

Wenn der Workflow fortgesetzt wird, wird die Version "Editor2" abgeglichen und in "Trans_mnt" zurückgeschrieben.

Für diesen Abgleich wurde die Version "Trans_mnt" (die Primärversion) geändert und referenziert einen neuen Zustand, beispielsweise Zustand 99, der sich in einer anderen Lineage befindet als die Version "Editor2". Zum Abgleichen der Bearbeitungen aus der Version "Editor2" werden alle Bearbeitungen aus dem Zustand 56 in einen neuen Zustand der Lineage von "Trans_mnt" kopiert.

Wenn mehrere Sekundärversionen aus derselben Primärversion erstellt werden, müssen im Rahmen der Abgleichvorgänge stets die Bearbeitungen aus einer Lineage in eine andere Lineage kopiert werden. Um die Menge der zu kopierenden Daten zu minimieren, können Sie die Version mit der größten Anzahl von Bearbeitungen zuerst abgleichen und zurückschreiben. Dadurch wird die Anzahl der Datensätze, die kopiert und in den Adds- und Deletes-Tabellen der Feature-Classes gespeichert werden, reduziert.

Die Überlegungen zum Workflow für das Abgleichen sind besonders wichtig, wenn eine sehr große Anzahl an Bearbeitungen in einer Sekundärversion oder eine Massenbearbeitung durchgeführt wird. Versionen, die für die Massenbearbeitung verwendet werden, sollten nach Möglichkeit immer mit der entsprechenden Zielversion abgeglichen werden, bevor die Zielversion geändert wird.