Lade...
 

Datenbank prüfen

Datenbank/Segmente prüfen/reorganisieren

Beschreibung

Mit diesem Modul kann die Datenbank komplett oder in Teilen technisch geprüft werden. Neben den Verbindungen der Objekte untereinander werden hierbei auch die Collections überprüft (Aufruf der ObjectStore utility osverifydb).

Werden keine Fehler festgestellt, können in einem zweiten Schritt gelöschte Objekte dauerhaft aus der Datenbank entfernt (reorganisiert) werden. Hierzu sind zunächst 6 vorbereitende Schritte zu unternehmen, bevor die Datenbank mittels der ObjectStore utility oscompact intern reorganisiert und anschließend mit der ObjectStore utility oscopy als neue Kopie erstellt wird.

Wird aus einer ClassiX Anwendung heraus ein persistentes Objekt gelöscht, wird es zunächst nur logisch gelöscht, d.h. es wird eine Löschkennung vergeben und das Objekt wird in einer gesonderten Liste registriert (garbage collection). Um ein persistentes Objekt dauerhaft aus einer Objekt orientierten Datenbank zu entfernen muss sicher gestellt sein, dass kein anderes Objekt dieses gelöschte Objekt referenziert. Diese Überprüfung findet mittels der ObjectStore utility osgc statt, die alle "unerreichbaren" Objekte als löschbar markiert und so zum Entfernen freigibt. Als "unerreichbar" gilt ein Objekt genau dann, wenn es in der Datenbank von keinem anderen Objekt oder einer Liste referenziert wird.

Um also die durch eine ClassiX Anwendung zunächst nur logisch gelöschten Objekte "unerreichbar" zu machen, müssen folgende 6 Schritte ausgeführt werden:

  1. Da logisch gelöschte Objekte auch andere logisch gelöschte Objekte referenzieren können, werden die Verbindungen zwischen diesen Objekten gekappt. Verbindungen zu nicht gelöschten Objekten bleiben dagegen erhalten. Hierzu werden alle logisch gelöschten Objekte aus ihrer Registrierungsliste (garbage collection) durchlaufen. Als "gelöscht" gelten die Objekte, die entweder eine Löschkennung besitzen oder in der Löschungs-Registrierungsliste (garbage collection) enthalten sind.

    Die Adressen der Objekte, aus denen Verbindungen gekappt wurden - d.h. die verändert wurden - werden in einer Datei gesichert.
     
  2. Alle logisch gelöschten Objekte werden aus ihrer Registrierungsliste (garbage collection) entfernt, die Adressen dieser Objekte werden in eine Datei geschrieben.
     
  3. Aufruf der ObjectStore utility osgc mit Ausgabe der Adressen der "unerreichbaren" Objekte in eine Datei, d.h. dieser Lauf entfernt noch KEINE Objekte aus der Datenbank.
     
  4. Aus den Adressen aus Schritt 2 und 3 kann nun eine Liste der Objekt Adressen ermittelt werden, die - obwohl gelöscht - nicht aus der Datenbank entfernt werden würden: Hierzu werden aus den Adressen aller logisch gelöschten Objekte (Schritt 2) die Adressen entfernt, die als "unerreichbar" gelten (Schritt 3). Die so entstehende Liste enthält nur noch die Adressen an logisch gelöschten Objekten, die aus der Datenbank NICHT entfernt werden dürfen und würden, d.h. die von anderen Objekten der Datenbank noch "aktiv" referenziert werden.

    Diese Adressen Liste an in der Datenbank verbleibenden, logisch gelöschten Objekten wird mit den Adressen der Liste aus Schritt 1 verglichen: Kommen Adressen in beiden Listen vor, wurden Verbindungen gekappt, die bestehen bleiben müssen, da ansonsten eine vollständige Navigation aus "aktiven" Objekten heraus nicht mehr möglich wäre. Diese Objekte müssen näher untersucht werden: entweder wird die Löschung rückgängig gemacht oder die Verbindung in den "aktiven" Datenbank Raum wird gekappt oder diese Objekte werden im Schritt 1 ausgelassen.

    Kommen solche Objekte vor, kann mit der Reorganisation der Datenbank nicht direkt weiter verfahren werden. Nach Prüfung der Sachlage und entsprechender Reaktion muss mit  Schritt 1 wieder erneut begonnen werden. Kommen solche Objekte nicht vor, kann mit der eigentlichen Entfernung der Objekte aus der Datenbank mit Schritt 5 fort gesetzt werden.

     
  5. Erneuter Aufruf der ObjectStore utility osgc, dieses Mal allerdings MIT Entfernung "unerreichbarer" Objekte aus der Datenbank.
     
  6. Mittels der Adressen Liste aus Schritt 2 werden die noch in der Datenbank verbliebenen, logisch gelöschten Objekte wieder registriert, d.h. in die garbage collection eingetragen. Werden alle diese Schritte in Einem aufgerufen wird überprüft, ob die neu erstellte garbage collection mit der Liste der verbliebenen Objekte aus Schritt 4 übereinstimmt.

    Auch für diese noch verbliebenen Objekte sollte geprüft werden, warum Referenzen aus "aktiven" Objekten noch bestehen.

Bis hierher wurden Objekte aus der Datenbank zunächst nur gelöscht, eine Neuordnung der Daten in der Datenbank und damit eine eventuelle Reduzierung der Größe der Datenbank wird nur durch das aufeinander nachfolgende Aufrufen der ObjectStore utilities oscompact und oscopy erreicht.

 

Achtung

Dictionaries müssen nach dem Lauf neu aufgebaut werden

 

[ CX_OBJECT_DICTIONARY CX_OBJECT_DICTIONARY_CI CX_OBJECT_DICTIONARY_ML CX_OBJECT_DICTIONARY_ML_CI ] iterate { FindAll(STACK) iterate { Call(RebuildDictionary) } }

Funktionalität

Prüfungsfenster

Menü
Menüpunkt Beschreibung
Bearbeiten -
: Datenbank/Segmente prüfen -
: : Datenbank/Segmente wählen

Aufruf des Selektionsfensters zur Auswahl der zu überprüfenden Segmente

: : Datenbank/Segmente prüfen Die ausgewählten - oder alle - Segmente werden mittels des Datenbank Dienstprogramms osverifydb überprüft
: Datenbank/Segmente reorganisieren (schrittweise) -
: : Neue garbage collection "geps" erstellen Die immer in einer Datenbank bestehende garbage collection mit dem Namen "geps" wird umbenannt in "garbage" plus einer laufenden Nummer (also z.B. in "garbage6") und es wird anschliessend eine neue garbage collection "geps" in die Datenbank geschrieben
: : Objektadressen aus allen garbage REPs exportieren Aus allen "garbagexx" collections werden die Objektadressen in getrennte Dateien im Unterverzeichnis "GarbageREPExport" des CX_SYSTEM_OUT Verzeichnisses geschrieben
: : Verbindungen aus garbage REP Objekten zu anderen logisch gelöschten Objekten trennen Alle Verbindungen logisch gelöschter Objekte untereinander werden entfernt
: : Garbage REPs leeren Es werden alle Objekte aus den garbage REPs entfernt
: : Batch Dateien erstellen und aufrufen um unerreichte Objekte in Datenbank(en) zu markieren und entfernen Mittels des ObjectStore Datenbank Dienstprogramms osgc werden alle die Objekte als zu löschen markiert und entfernt, deren Adresse von keinem anderen Objekt referenziert wird.

Diese Prozedur des Markieren und Entfernen wird voreingestellt 7mal hintereinander durchlaufen
: : Logisch gelöschte Restobjekte in garbage REP wieder einfügen Die vorher (siehe Schritt 2) exportierten Adressen werden nach Ihrer Auffindbarkeit in der Datenbank überprüft und bei Vorhandensein in die garbage REP collections wieder eingesetzt
: : Batch Dateien erstellen und aufrufen um Datenbank(en) zu kompakten Mittels des ObjectStore Datenbank Dienstprogramms oscompact wird/werden die Datenbanken in Bezug auf freie Speicherplätze reorganisiert.

Die Adressen der Objekte können sich durch diesen Lauf verändern
: : Batch Dateien erstellen und aufrufen um Datenbank(en) zu kopieren Mittels des ObjectStore Datenbank Dienstprogramms oscopy wird/werden die oben reorganisierten Datenbanken so kopiert, dass nicht mehr genutzter Speicherplatz freigegeben wird und sich die Datenbank(en) dabei verkleinern
: :  Dictionaries neu aufbauen Die Dictionaries müssen neu aufgebaut werden
: Datenbank/Segmente reorganisieren (in einem) Alle obigen Schritte ("Datenbank/Segmente reorganisieren (schrittweise)") werden in einem Durchlauf nacheinander automatisch aufgerufen
   
: Logbücher auswerten Wertet die Logbücher aus, die durch eine Prüfung erstellt wurden. Die Fehler werden in der Liste angezeigt.
: Auswertung speichern Speichert die Fehlerliste in einer Datei.

 

Felder
Feld Beschreibung
Liste Liste der Fehler

 

Selektionsfenster

Dieses Fenster dient der Auswahl der zu überprüfenden Segmente. Ebenso muss das Verzeichnis gewählt werden, in dem die Logbücher abgelegt werden sollen. Mit "Start" beginnt die Prüfung.

Felder
Feld Beschreibung
Liste Liste der zu überprüfenden Segmente
Logbücher speichern in: Anzeige des Pfades zum ausgewählten Speicherort

 

Knöpfe
Knopf Beschreibung
... Dialogfenster zur Auswahl des Speicherortes für die Logbücher aufrufen
Alle wählen Alle Segmente werden zur Überprüfung selektiert
Start Start der Überprüfung
Schließen Das Fenster wird geschlossen.

 

Verwandte Themen

 


Technische Dokumentation

ClassiX® prüft die Segmente nicht selbst, sondern ruft für jedes Segment die Batchdatei verifydb.bat auf, die sich im Projekt-Verzeichnis befindet. Diese delegiert die Arbeit weiter an osverifydb, einer ObjectStore-Utitlity.

Datenbank Prüfmodul

Modulname

verifydb.mod

Klassen

-

Security

Neben der Beschränkung der Zugriffsrechte über die Klasse und deren Datenfelder kann das Modul über einige der empfangenen Messages in seiner Nutzung beschränkt werden.

Empfangene Messages
Message Parameter Funktion Security
       
       
       

 

Gesendete Messages
Message Parameter Funktion Empfangs-Modul
       

Operativer Betrieb