Analyse von Oracle Initialisierungsparametern & deren automatisierte Bewertung

Das Ziel dieses Artikels ist die Vorstellung des ORDIX-Parameter-Tools. Mit diesem Tool wird die Analyse und Bewertung von Oracle-Initialisierungsparametern sehr leicht und mit wenig Aufwand automatisiert. Dabei erkennt das Tool Unstimmigkeiten und Verbesserungspotentiale in den Datenbankkonfigurationen und meldet diese.

Der Remote Support der ORDIX AG betreut täglich viele Kunden beim Betrieb verschiedener Datenbanken und unterstützt auf administrativer Ebene. Vor allem bei neuen Kunden, aber auch bei Bestandskunden ist zu beobachten, dass die Datenbanken oft nicht optimal konfiguriert sind oder Verbesserungspotential aufweisen. Das heißt, die Initialisierungsparameter der Datenbanken können besser gesetzt werden, um beispielsweise die Performance der Datenbank zu erhöhen. Damit das auch bei vielen Datenbanken schnell und effizient möglich ist, wurde das ORDIX Parameter-Tool entwickelt. Dabei wurde großen Wert auf einen modularen und flexiblen Aufbau gelegt. Dies ermöglicht, neue Checks einfach zu definieren und auszuführen.

Healthcheck

Das Parameter-Tool ist eine Erweiterung des ORDIX-Health Checks für Oracle Datenbanken. Der Health Check wird vom Bereich Remote Service der ORDIX AG für unterschiedlichste Datenbanken verschiedener Support-Kunden erstellt. Die für die Durchführung benötigten Metadaten der Umgebung und Datenbanken werden auf den Kundensystemen gesammelt. Auf Basis dieser Daten werden eine Reihe von automatisierten Checks durchgeführt, welche den aktuellen „Gesundheitszustand" der Datenbank überprüfen.

Die Ergebnisse werden in einem Report dokumentiert und daraufhin durch einen erfahrenen DBA bewertet und mit Ratschlägen und Verbesserungspotential für den Kunden ergänzt.

Weboberfläche - Reportansicht

Das Frontend des Parameter-Tools  ist vollständig in Oracle APEX umgesetzt und in den Health Check integriert. In der Konfigurationsansicht besteht die Möglichkeit, einzelne Checks des Parameter-Tools zu definieren und anzupassen. In der Reportansicht wird das Ergebnis der Checks in einem eigenen Kapitel innerhalb des Health Checks, ausgegeben.

Die Abbildung 1 zeigt die Reportansicht des Parameter-Tools in unserem Health Check. Dort befindet sich das Kapitel "Parameter-Tool" mit einem Report, welcher den Namen des Parameter-Tool-Checks, einen Kommentar und die Information, ob der Check bestanden wurde oder nicht, anzeigt. Beim Anlegen des Checks legt der Benutzer jeweils für das Bestehen oder Nichtbestehen eines Checks den zugehörigen Kommentar fest. Dieser Kommentar wird dann in Abhängigkeit vom Ergebnis des Checks im Report angezeigt.

Speicherung als Baumstruktur

Alle Parameter-Tool-Checks sind als Baumstruktur in Tabellen einer Datenbank abgespeichert. Dabei gibt es pro Parameter-Tool-Check einen optionalen Baum, welcher die Bedingung des Checks abspeichert und einen obligatorischen Baum, welcher die eigentliche Prüfung des Checks beinhaltet.

In den Abbildungen 2 und 3 sind jeweils eine Bedingung und eine Prüfung als Baumstruktur zu sehen. In diesem Beispiel wird die Prüfung des Checks nur ausgeführt, wenn die Bedingung (MEMORY_TARGET != 0) erfüllt ist.

Ein Baum besteht generell aus einer endlichen Anzahl von Knoten und Kanten, wobei die Kanten die Knoten miteinander verbinden. Bei den Knoten gibt es spezielle Bezeichnungen. Der oberste Knoten nennt sich Wurzelknoten und die Knoten ohne Nachfolger nennen sich Endknoten.

Die Speicherung eines Baumes erfolgt in mehreren Tabellen. Die wichtigste Tabelle ist jedoch diejenige, welche die Vergleiche eines Parameter-Tool-Checks abspeichert. Diese Tabelle ist als Baumstruktur angelegt und referenziert auf sich selbst. Jeder Datensatz stellt einen Knoten dar. Die Spalten OPERAND1, OPERATOR und OPERAND2 bilden zusammen einen Vergleich.

Zusätzlich gibt es die Spalten OPERAND1_ID und OPERAND2_ID, welche die Kanten widerspiegeln. In einem Datensatz wird pro Operanden entweder der Operand selbst in der entsprechenden Spalte angegeben oder eine ID als Referenz in der anderen Spalte. Die ID verweist auf einen weiteren Datensatz, welcher als Unterknoten fungiert.

In der Tabelle werden die Bäume aus Abbildung 2 und 3 folgendermaßen abgespeichert:

Weboberfläche – Konfigurationsansicht

Neben der anfangs genannten Reportansicht gibt auch es die Konfigurationsansicht. Dort werden Checks angelegt und verwaltet. Mit einem Klick auf einen Check gelangt der Benutzer in die Konfigurationsansicht. Diese zeigt den gewählten Check als Baumstruktur an. In der Abbildung 5 ist ein solcher Baum zu sehen. Die einzelnen Knoten lassen sich anklicken und anschließend bearbeiten. Außerdem besteht die Möglichkeit, neue Knoten anzulegen oder vorhandene Knoten zu löschen. In diesem Beispiel geht der Baum bis in die fünfte Ebene und zählt damit zu den etwas ausführlicheren Checks.
Das Tool bietet unten rechts verschiedene Buttons, mit denen der Baum ein- und ausgeklappt und Teilbäume oder der gesamte Baum gelöscht werden können.

Wenn der Benutzer auf einen Knoten des Baumes klickt, wird dieser in den „Knoten bearbeiten"-Bereich geladen, welcher in Abbildung 6 zu sehen ist. Die Operanden und der Operator des Knotens sind dann automatisch in den entsprechenden Feldern zu sehen. Nun lassen sich Änderungen am Knoten vornehmen und über den Button „Aktualisieren" abspeichern. Mit Klick auf den Button „Als Teilbaum hinzufügen" ist es auch möglich, weitere Unterknoten hinzuzufügen.

Die Initialisierungsparameter finden sich in dieser Ansicht als Operanden wieder. Um einen Parameter dem Knoten hinzuzufügen, muss er lediglich in der entsprechenden Select-Liste ausgewählt werden. Dabei zeigt die Select-Liste ausschließlich Parameter an, welche miteinander verglichen bzw. verrechnet werden können. Das heißt, die Liste zeigt nur Parameter an, welche dem Datentyp der gewählten Operators entsprechen. Somit wird beispielsweise schon in der Eingabemaske der Fehler, einen numerischen mit einem booleschen Parameter zu vergleichen, verhindert.

Interpretieren der Baumstruktur (Backend)

Die Engine bzw. Logik des Parameter-Tools ist vollständig in PL/SQL implementiert. Mit einer eindeutigen Datenbank-ID und dem zu betrachtenden Zeitraum als Parameter wird die Engine gestartet. Mit diesen Informationen sucht sie sich die passenden Parameterwerte aus den Metadaten der gewählten Datenbank heraus. Unabhängig von den Eingabeparametern lädt sie sich außerdem die formulierten Checks (In Abbildung 7 als Regeln dargestellt) dazu.

Bei der Ausführung durchläuft die Engine den gesamten Baum und wertet diesen aus. Für Knoten, welche Unterknoten besitzen, ist das Ergebnis des Knotens von dem des Unterknotens abhängig. Die jeweiligen Unterknoten müssen erst aufgelöst werden. Dazu beginnt die Engine mit den Endknoten und arbeitet sich bis zur Wurzel durch den Baum.

Dabei wird jeweils der Vergleich des aktuell betrachteten Knotens aufgelöst und das Ergebnis in den Vorgängerknoten übertragen. Beim Auflösen eines Ausdrucks vergleicht oder verrechnet die Engine beide Operanden anhand des jeweiligen Operators miteinander. Der Wert eines Operanden ist dynamisch oder statisch. Dynamische Operanden hängen von den Eingabeparametern des Checks ab. Die Engine sucht in einem solchen Fall den aktuellsten Parameterwert der angegeben Datenbank aus dem vorgegebenen Zeitraum heraus und bestimmt anschließend das Ergebnis des Vergleichs. Statische Operanden sind immer gleich und hängen nicht von der Datenbank oder dem Zeitraum ab.

Ist die Engine am Wurzelknoten angelangt und hat dessen Ergebnis bestimmt, ist der Check abgeschlossen. Die Engine gibt dann entweder 0 (nicht bestanden) oder 1 (bestanden) als Rückgabewert aus.

formale Sprache (DSL)

Um das bisher Gelesene über die Baumstruktur und den einzelnen Knoten tiefergehend zu verstehen, ist es notwendig einen Blick auf die formale Sprache der hier verwendeten Baumstruktur zu werfen. Einer der ersten Schritte in diesem Projekt war die Entwicklung einer solchen formalen Sprache bzw. einer domänenspezifischen Sprache (DSL). Erst aus dem Entwurf dieser Sprache hat sich die Baumstruktur als geeignete Variante zur Speicherung der Checks ergeben. 

DSL sind Sprachen mit einem sehr hohen Abstraktionsniveau und exakt auf ein bestimmtes Problemfeld in einem Fachgebiet bzw. auf die Domäne angepasst. Als Grundlage für eine DSL dient ein definiertes Alphabet und eine formulierte Grammatik. Aus diesen beiden Elementen werden dann Terme gebildet.

Zum Aufstellen der Grammatik und des Alphabets, sind Fallbeispiele aus der Praxis gesammelt und auf Gemeinsamkeiten untersucht worden. Die daraus entwickelte Grammatik ist in Abbildung 8 dargestellt.

Das in der Grammatik verwendete Alphabet definiert sich durch Variablen und Terminale.
Variablen sind wahrscheinlich den meisten Lesern bekannt. Wie der Name schon sagt, haben sie einen variablen Inhalt und können mit Hilfe der Grammatik in einen anderen Zustand überführt werden. Terminale hingegen sind immer konstant und können durch die Grammatik nicht mehr verändert werden.
Das Alphabet des Parameter-Tools besteht aus den folgenden Variablen (V) und Terminalen (T):

V = {S, P, V, A_N, A_T, A_B, O_N, O_T, O_B, O_R}
T = {w (wenn), p (prüfe), ∨, ∧, p_N, p_T, p_B, !=, =, >, <, >=, <=, regexp, +, -, *, /}

Wie bereits erwähnt werden mit Hilfe der Grammatik nun Variablen in einen anderen Zustand überführt. Dabei werden sie durch Terminale und/oder weiteren Variablen ersetzt. Um diese Ersetzung nicht willkürlich durchzuführen, gibt es die Produktionsregeln, welche auf der rechten Seite in Abbildung 8 zu finden sind. Die Produktionsregeln geben an, in welcher Form Variablen durch weitere Variablen und Terminale ersetzbar sind. Es gibt immer eine spezielle Produktionsregel für die allererste Umformung. Diese Produktionsregel wird auch Startregel genannt. Die Startvariable S wird dabei in den Anfangsterm überführt.

Das im Abschnitt "Speicherung als Baumstruktur" bereits verwendete Beispiel eines Parameter-Tool-Checks sieht formlos aufgeschrieben folgendermaßen aus:
Wenn MEMORY_TARGET != 0
Prüfe SGA_TARGET >= 2GB UND SGA_TARGET >= MEMORY_TARGET * 0,5

Aus diesem Beispiel erschließt sich mit dem Anwenden der Grammatik folgender Term: wp_N!=p_Npp_N>=p_N∧p_N>=p_N*p_N

Dieser Term hat nun den Vorteil, dass der Check nicht mehr formlos aufgeschrieben ist, sondern dem Muster der Grammatik entspricht. Dadurch kann er problemlos in der entsprechenden Tabelle (Abbildung 4) abgespeichert und von der Engine interpretiert werden.

Fazit

Das Parameter-Tool ist mittlerweile erfolgreich in die Produktivumgebung des Health Checks integriert. Um das Tool zu nutzen und eigene Checks zu definieren, benötigt es etwas Zeit für die Einarbeitung. Danach ist es jedoch sehr vielseitig einsetzbar.
Durch die Modularität des Tools ist es nicht nur ausschließlich für die Analyse von Initialisierungsparametern nutzbar, sondern auch sehr hilfreich bei der Analyse von allen möglichen Daten, welche in einer Datenbank abfragbar sind.

Für die Kunden der ORDIX AG bietet es durch die Erweiterung des Health Checks einen direkten Vorteil. Durch die definierten Checks fallen mögliche Fehlkonfigurationen bzw. Verbesserungspotentiale direkt bei der Erstellung eines Health Checks auf. Ein erfahrener DBA des ORDIX DB Supports baut darauf im folgenden Schritt Ratschläge für den Kunden auf und dokumentiert diese im Health Check.