Zielstellung

Die richtige Implementierung des Anwendungsschemas ist eine wesentliche Voraussetzung für den zuverlässigen Betrieb der Anwendung sowie für akzeptable und stabile Antwortzeiten; je enger die Anwendung an die Funktionalitäten der Datenbank gebunden ist, desto kritischer ist dies.

Das Produkt kVASy unseres Mutterhauses SIV.AG nutzt die Oracle-Datenbank sehr intensiv – die Erfahrungen aus dem Support der Anwendung spiegeln sich (auch) im Modul Schema-Wartung des quasiDBA wieder:

Die hier betrachteten Fehler im Anwendungsschema können die unterschiedlichsten Ursachen haben – oft ist ein fehlgeschlagenes Upgrade die Ursache.

Im Folgenden werde ich die einzelnen Funktionen und insbesondere die Auswirkungen der jeweils adressierten Fehler auf den Betrieb der Anwendung beschreiben.

Grundsätzlich stellen die betreffenden Views die Schema-Objekte der ausgewählten Schemata dar – siehe oben im Navigationsbereich; ein Filter kann ein oder mehrere Oracle-Schemata umfassen und wird in „Einstellungen“ konfiguriert. Die fehlerhaften Objekte werden angezeigt und der Anwendungsadministrator markiert sie für die Korrektur, die dann in der Regel mit einem Maus-Klick repariert werden.

Im Statusbericht

werden die in den einzelnen Views anzuzeigenden Fehler zusammengefasst, so dass der Administrator für einen Überblick nicht jede einzelne Funktion öffnen muss; ein Mausklick auf die Fehleranzeige öffnet die entsprechende Funktion zur näheren Untersuchung und Korrektur.

Optimizer-Statistiken

Für die Performance der Anwendung gibt es wohl nichts Wichtigeres als korrekte Statistiken für den Cost Based Optimizer, da dieser auf der Grundlage der Statistiken den optimalen Ausführungsplan berechnen soll. Neben den Statistiken für die Schema-Objekte sind auch die Statistiken des Data Dictionary und des Systems relevant – auch sie können hier aktualisiert werden.

Im Grunde müssen die Schema-Statistiken nicht permanent neu berechnet werden, wenn das System hinreichend lange und unverändert gelaufen ist. Die Größenverhältnisse zwischen den einzelnen Tabellen sowie die Werteverteilungen sind dann hinreichend stabil, so dass im Prinzip auch mit alten Statistiken korrekte Ausführungspläne berechnet werden können. Zumindest im kVASy ist jedoch zu viel Dynamik hinsichtlich der Anwendung bzw. Nutzung der Anwendung, so dass dieser Zustand nicht eintritt.

Die Funktion stellt nun alle Tabellen des Anwendungsschemas (bzw. aller im Filter ausgewählten Schemata) mit

  • Zeitstempel der letzten Analyse
  • Anzahl der Datensätze (ALL_TABLES.NUM_ROWS)
  • Anzahl der Veränderungen (ALL_TAB_MODIFICATIONS)
  • Relation Datensätze zu Veränderungen

dar; die Tabellen, für welche die Statistiken aktualisiert werden sollen, werden markiert und mittels der Schaltfläche „Statistik berechnen“ via DBMS_STATS mit den instanzweit eingestellten Parametern neu berechnet.

Statistik-Rücksicherung

Die Oracle-Datenbank sichert vor einer Änderung der Optimizer-Statistiken die aktuellen Werte – hier kann (zum Beispiel nach einem Abbruch der Schema-Analyse) auf dieses Backup zurückgesetzt und damit der Tagesbetrieb sichergestellt werden.

Ungültige Objekte

Ungültige Objekte – also Schema-Objekte, die vor ihrer nächsten Benutzung durch die Datenbank kompiliert (PL/SQL Stored Procedes und Trigger) bzw. geprüft (Views) werden müssen, können im Betrieb zu Fehlern führen. Sei es, dass das kompilieren fehl schlägt und die entsprechende Funktion der Anwendung dann einen Fehler ausgibt oder dass durch das automatische kompilieren Wartezustände (lock waits) in der Anwendung auftreten, die sich durch die Abhängigkeiten unter den Schema-Objekten bis zum Stillstand der Instanz „aufschaukeln“ können.

Die quasiDBA-Funktion zeigt die als „invalid“ markierten Schema-Objekte an; nachdem sie zur Korrektur ausgewählt wurden, betätigt der Administrator die Schaltfläche „Kompilieren“ und es wird ein „alter…compile…“ ausgeführt. Schlägt dieses fehl, so wird der Fehler dargestellt, so dass der Administrator dem Hersteller-Support eine qualifizierte Fehlermeldung liefern kann.

Deaktivierte Constraints

Inaktive Primärschlüssel- und Unique-Constraints verursachen zumindest Laufzeitprobleme, da die entsprechenden Indizes nicht (mehr) existieren. Inaktive Fremdschlüssel-Constraints führen zu Inkonsistenzen der Anwendungsdaten, da referenzierte Datensätze gelöscht werden können (zumindest wenn die Anwendung nicht teuer dedizierte Logik dafür implementiert).

Die inaktiven Constraints (mit Ausnahme der view-relevanten, welche immer inaktiv sind) werden hier zur Ein-Klick-Reparatur angezeigt.

Deaktivierte Trigger

Nicht aktive Datenbanktrigger führen zu Fehlern in der Anwendung, da diese voraussetzt, dass bestimmte Operationen durch die Trigger ausgelöst/realisiert werden. Analog zur Funktion „Ungültige Objekte“ werden hier die betreffenden Objekte angezeigt, repariert und ggf. die Fehlermeldung aus der Korrektur ausgegeben.

Indexlose Fremdschlüssel-Constraints

Fremdschlüssel-Constraints, zu denen kein korrelierender (passender) Index existiert, können zu Lock-Waits und gar (Self-) Dead Locks führen. Das heißt, wenn kein Index existiert, den die Datenbank zum Validieren eines eingefügten/geänderten Detail-Datensatzes nutzen könnte, wird die gesamte (Master-) Tabelle gesperrt und andere Transaktionen müssen warten. Handelt es sich gar um einen Fremdschlüssel-Constraint, der die gleiche Tabelle referenziert (Bsp.: Relation Kunde ist Sammelkunde), können auch Dead Locks auftreten.

Die relevanten Constraints werden hier angezeigt und das Auswählen der Schaltfläche „Index erzeugen“ erzeugt einen entsprechenden Index.

Ungültige Indizes

Indizes, die als „unusable“ gekennzeichnet sind (z.B. nach einer Reorganisation der Tabelle mittels MOVE), können nicht für den Zugriff auf die Tabelle verwendet werden – in der Folge mit schlechten Antwortzeiten.

Die betreffenden Indizes werden hier angezeigt und ggf. mittels „alter index… rebuild“ repariert.

Nicht eindeutige PK-Indizes

Im Normalfall wird beim Definieren eines Unique Constraints automatisch ein korrespondierender Unique Index durch die Datenbank erzeugt. Unter bestimmten Bedingungen kann es jedoch sein, dass dieser Index als non-unique erstellt wird. Da diese durch Optimizer mit einer geringeren Selektivität bewertet werden, können die resultierenden Ausführungspläne und somit die Antwortzeit ungünstig sein. Die betreffenden Constraints werden hier angezeigt – die Reparatur löscht den vorhanden Index, um dann einen eindeutigen zu erzeugen.

Tabellenfragmentierung

Datensätze, die in mehr als einem Datenblock gespeichert werden (chained rows) können zu Performance-Problemen führen. In den aktuellen Datenbankversionen ist dieses Problem bei weitem nicht mehr so gravierend, aber immer noch vorhanden.

Die Analyse einer Tabelle hinsichtlich solcher Datensätze ist leider nicht trivial, da nur mit dem „analyze table…“ Statement möglich. Die dabei entstehenden Optimizer-Statistiken sind jedoch nicht mit den durch DBMS_STATS üblicherweise berechneten kompatibel, so dass hier folgendes Vorgehen implementiert wurde:

  • Backup der aktuellen Statistiken in eine dedizierte Tabelle
  • Analyse mittels „analyze table“
  • Übertragen der Ergebnisse aus dem Data Dictionary in eine weitere Tabelle für die Anzeige im quasiDBA
  • Zurücksichern der ursprünglichen Statistiken

Die ist also keine Funktion, die im Tagesbetrieb genutzt werden sollte; ebenso die Reparatur, welche die ausgewählte Tabelle mittels „alter table… move“ reorganisiert und danach alle Indizes der Tabelle neu erstellt.

Zusammenfassung

Der Administrator kann das Anwendungsschema hier also nicht verändern oder erweitern, sondern lediglich bekannte Fehler-Szenarien bereinigen – dies mit minimalem Aufwand. Diese Szenarien sind aus den Support-Erfahrungen für kVASy abgeleitet – ebenso die Korrektur.

Weitere Informationen zum quasiDBA sind auf unserer Homepage http://www.arch-tech.de/index.php/de/portfolio/quasidba zu finden.

Teile diesen Artikel:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *