Bei der Geodatabase-Komprimierung werden nicht erforderliche States und Zeilen aus den Geodatabase-Systemtabellen entfernt, die traditionelle Versionen und versionierte Änderungen protokollieren.
Was bedeutet Geodatabase-Komprimierung?
Bei der Komprimierung werden alle States entfernt, die nicht mehr von einer traditionellen Version referenziert werden. Alle Zeilen in den Delta-Tabellen werden in die Business-Tabelle verschoben. Geodatabase-Komprimierung kann nur vom Geodatabase-Administrator ausgeführt werden, die Komprimierung wird jedoch unabhängig vom jeweiligen Besitzer der Version, auf alle States der Geodatabase angewendet.
Die Komprimierung ist aus folgendem Grund erforderlich: Wenn eine Geodatabase, die die traditionelle Versionierung verwendet, über einen Zeitraum hinweg bearbeitet wird, erhöhen sich die Größe der Delta-Tabellen und die Anzahl der States. Je umfangreicher die Tabellen und je zahlreicher die States, desto mehr Daten müssen von ArcGIS jedes Mal verarbeitet werden, wenn Sie eine Version anzeigen oder abfragen. Die größten Auswirkungen auf die Performance hat daher nicht die Anzahl der Versionen, sondern der Umfang der Änderungen in den Delta-Tabellen für jede Version. Im Ergebnis können die Versionen unterschiedliche Zeiten für die Reaktion auf Abfragen aufweisen.
Um die Performance aufrechtzuerhalten, muss der Geodatabase-Administrator in regelmäßigen Abständen eine Komprimierung der Geodatabase ausführen, um nicht verwendete Daten zu löschen.
Sie können dazu den ArcGIS Desktop-Befehl "Komprimieren" oder das Geoverarbeitungswerkzeug "Komprimieren" bzw. ein Python-Skript verwenden.
Was geschieht während der Komprimierung?
Während der Komprimierung wird zunächst die State-Tree-Konfiguration der Instanz in den Speicher eingelesen. Mithilfe dieser Information werden beim Komprimieren alle nicht zu einer Lineage gehörenden States gelöscht. Wenn Sie einen State löschen, werden alle mit dem gelöschten State verknüpften Zeilen der Delta-Tabellen gelöscht.
In einem weiteren Schritt werden alle States jeder einzelnen Lineage zu einem State zusammengefasst. In diesem Fall umfasst die Lineage eine Gruppe von States, die zu einem State zusammengefasst werden kann, ohne dass dabei die logische Ausprägung von Tabellen in einer bestimmten Version beeinflusst wird.
Zuletzt werden ggf. die Zeilen der Delta-Tabellen in die Basistabellen (oder Business-Tabellen) verschoben.
Bei jedem Schritt dieses Vorgangs werden die Datenbanktransaktionen beim Komprimieren der einzelnen Tabellen gestartet und wieder gestoppt. So kann überprüft werden, dass jede Tabelle in den unterschiedlichen Phasen des Komprimierungsvorgangs konsistent ist.
Die Komprimierung kann auch während der Ausführung gestoppt werden, da er auf eine direkte Konsistenz der Daten abzielt. Wenn daher während der Ausführung ein Fehler auftritt, diese fehlschlägt oder abrupt abbricht, sind die komprimierten versionierten Tabellen in Bezug auf die Darstellung einer beliebigen Version logisch richtig. Ein möglicher Grund für den Abbruch der Komprimierung liegt möglicherweise dann vor, wenn Sie die Komprimierung ausführen, während Benutzer mit der Geodatabase verbunden sind, und Sie dann feststellen, dass die Komprimierung einen Großteil Ihrer Systemressourcen beansprucht. In diesem Fall beenden Sie den Vorgang und führen ihn erneut aus, wenn weniger oder keine Benutzer mit der Geodatabase verbunden sind.
Vergewissern Sie sich, dass Sie genügend logische Protokolldateien erstellen, um die längste Transaktion auszuführen. Normalerweise treten beim Komprimieren einer Geodatabase lange Transaktionen auf. Sie müssen die logischen Protokolldateien sichern, bevor Sie die durch den Parameter "LTXHWM" in der IBM Informix-Datei "onconfig" vorgegebene Länge überschreiten. Sie sollten ohne die Zustimmung eines erfahrenen Mitarbeiters des technischen Supports von Informix, der sich mit dem Verhalten des Informix Spatial DataBlade auskennt, keine Änderungen an den Parametern "LTXHWM" oder "TXEHWM" vornehmen. Wenn eine Transaktion nicht erfolgreich abgeschlossen werden kann und wiederholt werden muss, weil sie die vorgegebene Länge überschreitet, verfügen Sie nicht über genügend logische Protokolldateien.
Während der Komprimierung großer Geodatabases verfügt die Informix-Datenbank häufig nicht mehr über genügend Sperren. Um dies zu verhindern, können Tabellen während der Komprimierung exklusiv gesperrt werden. Wenn Sie die Datenbank mit bestehenden Benutzerverbindungen komprimieren möchten, muss die exklusive Sperrfunktion während des Komprimierungsvorgangs deaktiviert werden. Um die Komprimierung mit gleichzeitigen Benutzerverbindungen zuzulassen, kann der Konfigurationsparameter "USE_EXCLUSIVE_LOCKING" als falsch festgelegt werden. Weitere Anweisungen zum Ändern von Konfigurationsparameterwerten finden Sie unter Ändern von Konfigurationsschlüsselwörtern.
Vollständiges Komprimieren einer Geodatabase
In einer vollständig komprimierten Geodatabase sind keine Zeilen in den Delta-Tabellen vorhanden, und der State-Tree wird auf 0 zurückgesetzt. Die größte Performance-Steigerung ergibt sich durch vollständige Komprimierung der Geodatabase. Gehen Sie dazu folgendermaßen vor:
- Zunächst müssen Sie alle ausstehenden Änderungen der Child-Versionen mit der Default-Version abgleichen und sie zurückschreiben. Als Geodatabase-Administrator können Sie sehen, in welcher Reihenfolge die Versionen abgeglichen werden sollten, in dem Sie in ArcMap im Dialogfeld Geodatabase-Verwaltung die Unterregisterkarte Abgleichreihenfolge der Registerkarte Versionen öffnen. Informationen zur Unterregisterkarte Abgleichreihenfolge finden Sie unter Versionseigenschaften.
- Löschen Sie die Nachfolgeversionen, nachdem Sie Bearbeitungen abgeglichen und zurückgeschrieben haben.
- Stellen Sie sicher, dass kein Benutzer mit der Geodatabase verbunden ist.
- Komprimieren der Geodatabase
Die Ergebnisse der jeweiligen Komprimierung in ArcGIS Desktop werden in der Tabelle "compress_log" angezeigt. Sie können auch anhand der Tabelle "versions" in der Datenbank prüfen, ob die State-ID für die Default-Version auf 0 zurückgesetzt wurde. Wenn dies der Fall ist und keine weiteren offenen Versionen vorhanden sind, wurde eine vollständige Komprimierung der Datenbank erreicht.
Es kann sein, dass Sie vor einer Komprimierung nicht immer Versionen abgleichen, zurückschreiben oder löschen können oder die Benutzer von der Datenbank trennen können. Wenn Sie beispielsweise den Verlauf mithilfe von Versionen verfolgen oder Designversionen für ein Projekt beibehalten müssen, bleiben die Verlaufs- und Designversionen einem State innerhalb des State-Trees zugeordnet und werden daher während des Komprimierungsvorgangs nicht gelöscht. Eine Performance-Verbesserung kann auch erreicht werden, wenn Sie zur Komprimierung nicht alle genannten Schritte ausführen.
Häufigkeit von Komprimierungen
Wie häufig die Geodatabase komprimiert werden muss, hängt davon ab, wie viele Bearbeitungsvorgänge in der Geodatabase ausgeführt werden. Wenn Sie viele Bearbeitungsvorgänge ausführen, sollten Sie die Geodatabase einmal täglich komprimieren. Bei einer mittleren oder geringen Anzahl von Bearbeitungsvorgängen sollten Sie die Datenbank mindestens einmal wöchentlich komprimieren.
Nach der Komprimierung der Geodatabase
Nachdem Sie die Komprimierung ausgeführt haben, sollten Sie die Geodatabase-Statistiken aktualisieren. Der Geodatabase-Administrator muss die Statistik in den versionierten Systemtabellen aktualisieren und einzelne Benutzer können die Statistik ihrer bearbeiteten Datasets aktualisieren.