Die Komprimierung einer Geodatabase in Oracle führt u. U. zu blockierenden Bedingungen in ArcGIS, wodurch es nicht mehr reagiert

Beschreibung

Es treten möglicherweise blockierende Bedingungen in Oracle auf, wenn die versionierte Geodatabase bei der Bearbeitung einer versionierten Klasse komprimiert wird. Bei einer blockierten Oracle-Sitzung ist das beobachtete Verhalten von ArcGIS, dass es nicht mehr reagiert.

Hinweis: Die ArcSDE-Software, einschließlich Anwendungsserver, Befehlswerkzeugen und SDK mit C- und Java-APIs, wird in ArcSDE 10.2.2 nicht mehr unterstützt und nicht mehr ausgeliefert.

Dies tritt nur ein, wenn der Editor eine versionierte Aktualisierung vornimmt, wenn er die versionierte Klasse, die zu diesem Zeitpunkt von der Geodatabase komprimiert wird, löscht oder wenn die Komprimierung blockiert ist und auf die Ausführung der Komprimierung wartet.

Die Dauer der blockierenden Bedingung ist abhängig von der Dauer der Editiersitzung, in der die Sperre für die versionierte Klasse abgerufen wurde, bzw. von der Transaktionsdauer des Komprimierungsvorgangs für die Klasse.

Ursache

Um die Lesekonsistenz von versionierten Daten bei der Bearbeitung und Komprimierung sicherzustellen, muss eine Sperre für die Deletes-Tabelle der versionierten Klasse abgerufen werden.

Da Oracle ein optimistisches Sperrmodell verwendet, bei dem Benutzer mit Lesezugriff nicht von Benutzern mit Schreibzugriff gesperrt werden, muss zur Verhinderung von Racebedingungen ein Sperrmodell in die Anwendung implementiert werden. So wird sichergestellt, dass eine Zeile nicht in einer Sitzung ausgelesen wird, während dieselbe Zeile in einer anderen Sitzung aktualisiert wird.

In ArcGIS wird die Racebedingung dadurch verhindert, dass beim Aktualisieren oder Löschen eine exklusive Zeilensperre für die Deletes-Tabelle einer versionierten Klasse abgerufen wird. Bei der Komprimierung hingegen wird eine gemeinsam genutzte Sperre für die Deletes-Tabelle der versionierten Klasse abgerufen. Beide Sperren bleiben für die Dauer der jeweiligen Transaktion bestehen. Bei einer Aktualisierung oder Löschung in der Anwendung entspricht die Transaktionsdauer der Laufzeit der Bearbeitungsoperation (durch den Aufruf von "stopeditoperation" wird die Transaktion bestätigt und durch "aborteditoperation" wird sie zurückgesetzt). Die Komprimierungssperre bleibt nur solange bestehen, wie eine einzelne Tabelle komprimiert wird, und nicht für den gesamten Komprimierungsvorgang.

Durch die exklusive Zeilensperre entstehen keine blockierenden Bedingungen, wenn mehrere Benutzer eine versionierte Klasse bearbeiten; es wird lediglich der Komprimierungsvorgang blockiert. Analog dazu werden durch den Komprimierungsvorgang Editoren blockiert, die Aktualisierungen und Löschungen durchführen.

Sobald vom Komprimierungsvorgang die gemeinsam genutzte Sperre abgerufen wurde, werden Editoren nicht mehr blockiert und können Aktualisierungen oder Löschvorgänge durchführen. Das vom Endbenutzer beobachtete Verhalten ist, dass die Anwendung nicht mehr reagiert. Die Dauer der Blockierung hängt vollständig davon ab, wie lange das Kürzen der versionierten Tabelle im Rahmen der Komprimierung dauert, was sich wiederum nach der Anzahl an Zeilen richtet, die aus der zu kürzenden Klasse entfernt werden (erfolgt die Komprimierung regelmäßig bzw. jede Nacht, sollte das Volumen gering sein).

Ein weiterer Umstand, der zu blockierenden Bedingungen führen kann, besteht darin, wenn ein Editor eine exklusive Zeilensperre für die Klasse abgerufen und die Bearbeitungsoperation noch nicht beendet hat (das Beenden führt zur Bestätigung und Entfernung der Sperre). Wenn die Sperre einer Editiersitzung über einen längeren Zeitraum hinweg bestehen bleibt (beispielsweise aufgrund großer Datenmengen, die aktualisiert oder gelöscht werden müssen), blockiert die Sitzung des Editors den Komprimierungsvorgang. Ist der Komprimierungsvorgang blockiert, verwaltet Oracle die Warteschlange für Sitzungen, die eine Sperre anfordern, nach dem FIFO-Prinzip (First In First Out). Somit wird die Komprimierung durch die Editiersitzung blockiert, und gleichzeitig blockiert die Anforderung des Komprimierungsvorgangs andere Editiersitzungen, die eine Sperre anfordern. Dieser Kaskadeneffekt stellt das erwartete Verhalten von Oracle dar (es ist der einzige Mechanismus, mit dem die Verarbeitung der Sperranforderungen in der korrekten Reihenfolge sichergestellt wird).

Die Konsequenzen dieses Sperrverhaltens bestehen in den Auswirkungen auf die Editoren sowie in längeren Wartezeiten, die beim Anfordern von Sperren zu Zwecken der Datenkonsistenz entstehen.

Lösung oder Problemumgehung

Planen Sie den Komprimierungsvorgang so, dass er in Zeiten mit geringer Auslastung, wo nur wenige Benutzer versionierte Klassen bearbeiten, ausgeführt wird.

Wird festgestellt, dass der Komprimierungsvorgang zu blockierenden Bedingungen in der Oracle-Instanz führt und die Bearbeitung durch Benutzer verhindert, kann die Sitzung, von der der Komprimierungsbefehl ausgeführt wird, einfach beendet werden.

Der Komprimierungsvorgang wurde mit Hinblick auf Transaktionskonsistenz konzipiert, sodass auch bei einem Vorgangsabbruch die Datenintegrität gewährleistet ist.