Compress der Datenbank ist nicht vollständig (End_State_Count nicht auf 1)

Grundlagen

Um Daten editieren zu können und dabei Geodatabase-Funktionalität wie regelbasierte Topologie nutzen zu können, müssen Feature Classes/Tabellen als versioniert registriert werden. Dabei werden die sogenannten Deltatabellen angelegt:

- A-Tabelle (Adds) für neu hinzugekommene Features/Sätze

- D-Tabelle (Deletes) für gelöschte Features/Sätze.

Dies ist auch Voraussetzung für das Arbeiten mit Versionen.

Bei der Anmeldung an die Datenbank wird eine Version gewählt. Auch wenn keine explizite Version angelegt wurde, gibt es eine Standardversion: die DEFAULT-Version.

Jede Bearbeitungssitzung bzw. Version zeigt dabei die Daten zu einem bestimmten Stand. Jede Änderung bekommt dazu eine STATE_ID. Die Abstammungslinien von STATE_IDs werden über Systemtabellen verfolgt. D.h. um den aktuellen ‚Stand‘ einer Version zu ermitteln, muss das System nicht nur die Businesstabelle, sondern auch die Deltatabellen und Systemtabellen auswerten.

Änderungen werden in die Deltatabellen eingetragen. Die eigentliche Businesstabelle (Tabelle/Feature Class) ändert sich nicht mehr. Änderungen werden erst aus den Deltatabellen in die Businesstabelle überführt, wenn der SDE- Benutzer die Funktion „versionierte Datenbank komprimieren“, d.h. ein Compress durchführt. Dies ist vom Eigentümer des Repositories durchzuführen.

Kontrolle des jeweiligen Compress der Datenbank mit sqlplus unter den Tabellen <nutzer>.states sowie  <nutzer>.compress_log (<nutzer> bei Benutzerschema-Geodatabase) bzw. sde.compress_log (Plugable Database, Containerdatenbank -> Nutzer sde bei Abfrage auf Master Geodatabase)

select count(*) from states; -> Anzahl der aktuell vorliegenden states
select * from compress_log; -> END_STATE_COUNT beim Compress

Beispiel für einen nicht vollständigen Compress:

SQL> select * from compress_log;

SDE_ID  SERVER_ID D COMPRESS START_STATE_COUNT COMPRESS END_STATE_COUNT COMPRESS_STATUS
---------- ---------- - -------- ----------------- -------- ----------- ---------------
       186       9940 N 09.02.23               517 09.02.23          10         SUCCESS

       187       5328 N 09.02.23                10 09.02.23          10         SUCCESS

Ein Compress _kann nur vollständig (END_STATE_COUNT = 1) werden, wenn:

• es keine offenen Versionen mehr gibt
• wenn niemand mehr angemeldet ist
• wenn es keine Sperren mehr gibt durch laufende Dienste, ArcCatalog,...
• wenn es keine Sätze in den Tabellen table_locks, object_locks, layer_locks, state_locks mehr gibt

Eine Ursache für offene Versionen könnte  z.B. aufgrund von offenen Fortführungssimulationen bei 3A Projekten vorliegen. Bei diesen Projekten müsste ein "Commit -> Unterbrochenen Auftrag fortsetzen" oder "Rollback -> Entsperren und Auftrag zurücksetzen"  erfolgen. Alternativ kann das "Commit" bzw. "Rollback" auch im 3A Server ADMIN über die Auftragsbearbeitung erfolgen.

Problemanalyse, falls Compress nicht läuft bzw. nicht vollständig (state_id =1)

Prüfen, ob ggf. noch abgeleitete temporäre Versionen existieren

• ArcCatalog -> Geodatabase verwalten -> Versionen oder
• unter Anmelden als jeweiliger Geodatabase-Benutzers (Schema-Owner)
• sqlplus alkisdhk/alkisdhk@serv3a (Benutzerschema- Geodatabase BS-GDB)
• sqlplus sde/sde@alkisdhk (Pluggable Database MTA PDB)

SQL> select name, owner from versions;

-> falls außer der DEFAULT Version temporäre Versionen existieren (z.B. aus Ff-Simulation -> <projektname>_T1)  ist state_id = 1 nicht möglich !

Prüfen, ob laufende Prozesse oder Sperren existieren:

• alle abhängigen angemeldeten Dienste beenden (z.B. 3A Server, ArcGIS for Server)
• explizit alle Verbindungen beenden oder trennen über ArcCatalog -> Geodatabase verwalten -> Verbindungen
• Prüfen, wer ist ggf. sonst noch angemeldet

SQL> select sde_id, server_id, owner, direct_connect from process_information;

Beispiel:

    SDE_ID  SERVER_ID OWNER                          D
---------- ---------- ------------------------------ -
       115       3976 ALKISDHK                       Y

• Prüfen, ob es noch Sperren gibt
  • SQL> select count(*) from state_locks;
  • SQL> select count(*) from table_locks;
  • SQL> select count(*) from object_locks;
  • SQL> select count(*) from layer_locks;

• Wenn es keine gültigen Verbindungen mehr gibt, dann darf es auch keine Sperren mehr geben. Wenn es also dann noch entsprechende Einträge gibt, kann man diese mit DELETE löschen.
  • SQL> delete from process_information where sde_id = 115;
  • SQL> delete from state_locks;
  • SQL> delete from table_locks;
  • SQL> delete from objekt_locks;
  • SQL> delete from layer_locks;
  • SQL> commit work;

Jetzt erneut Komprimieren und abhängige Dienste wieder starten.