Web-Anwendungen, komplexe administrative Systeme und Data Warehouses sprengen die bislang im Datenbankumfeld gewohnten Grenzen. Für die Systemverwaltung bedeutet das, nicht nur die Zahl der eingesetzten Datenbanken steigt ständig, auch die der Benutzer geht in die Tausende, die der gespeicherten Tabellen in die Zehntausende, und das Volumen großer Datenbanken erreicht den Bereich von Terabytes.

Dementsprechend wachsen auch die Betriebskosten für Datenbanken, deren weitaus größten Anteil die Personalaufwendungen ausmachen - nach Veröffentlichungen von IBM und der Aberdeen Group liegen sie bei über 80 Prozent der Gesamtkosten. Erfahrene Datenbankspezialisten sind zudem rar, und ein Zuwachs an Spezialisten, der den steigenden Anforderungen gerecht würde, ist nicht zu erwarten. Hinzu kommt, dass sich Firmen mit kleinen IT-Abteilungen keine reinen DB-Experten leisten können. Sie beschäftigen in der Regel ein oder zwei Fachkräfte, die Betriebssysteme, Web- und Applikations-Server sowie Datenbanken zugleich betreuen. Hier ist eher ein breites Know-how als eine tiefer gehende Spezialisierung gefragt. Schließlich muss unbedingt noch der Aspekt menschlichen Versagens in Betracht gezogen werden, denn laut Gartner-Analysen gehen etwa 40 Prozent der Ausfälle großer Online-Systeme auf die Fehler des Betreuungspersonals zurück.

Unter diesen Umständen liegt es nahe, dem Computer die Administrations- und Optimierungsarbeiten selbst zu übertragen. Dieser Ansatz verspricht geringere Kosten und die schnellere Lösung noch komplexerer Aufgaben. Unter dem Schlagwort Autonomic Computing arbeiten führende Hersteller von Datenbank-Management-Systemen daran, Funktionen, die bislang vom Betreuungspersonal übernommen wurden, als Software in die Systeme zu integrieren. Neben der Entlastung der Administration von Routine-Aufgaben hat dieses Vorgehen noch ein anderes Ziel: Hersteller werden durch die Integration von Erfahrungen, die sie mit dem Einsatz ihrer Produkte und Komponenten gesammelt haben, vom jeweiligen Know-how des betreuenden Datenbankpersonals unabhängig.

Keine klare Nomenklatur

Obwohl Anbieter wie IBM oder Oracle in dieser Hinsicht dieselben Ziele verfolgen und fast gleiche Wege gehen, klassifizieren sie ihre Werkzeuge unterschiedlich. Die implementierten neuen Funktionen verbergen sich hinter einer Reihe von Schlagworten, die bedauerlicherweise Marketing-geprägt sind. Es ist daher verständlich, das bei Anwendern eher Begriffsverwirrung als Klarheit über den realen Funktionsumfang entsteht. Außerdem legen die Hersteller den Begriff "autonomic" großzügig aus und fassen auch Werkzeuge darunter, die durchaus noch manuelle Vor- oder Nacharbeiten benötigen.

Die neuen Autonomic-Werkzeuge lassen sich grob in Kategorien einteilen wie

• selbstüberwachend,

• selbstkonfigurierend,

• selbstoptimierend und

• selbstwartend.

Im Folgenden werden die aktuellen Lösungsansätze am Beispiel von IBMs DB2 Universal Database V8.2 vorgestellt.

Das Health Center

Eine wesentliche Entlastung von Routinetätigkeiten wird dadurch erreicht, dass ein Datenbanksystem sich selbst überwacht und beim Überschreiten voreingestellter Schwellwerte eine gezielte Meldung absetzt. Das "Health Center" (in der deutschsprachigen Version: Diagnosezentrale) dient einer solchen Überwachung des laufenden DB2-Betriebs. Mit entsprechender Voreinstellung lassen sich die Meldungen gezielt als E-Mail an einen Benutzer oder eine Gruppe versenden. Zu den Alarmhinweisen sind Erläuterungen und Empfehlungen zur Problemlösung abrufbar.

Der Configuration Advisor

In Anbetracht der Fülle von Konfigurationsparametern moderner, leistungsfähiger Datenbanken und der Abhängigkeiten zwischen diesen ist die optimale Systemkonfiguration eine Arbeit für erfahrene Spezialisten. Deshalb ist ein Werkzeug, das die Konfiguration unterstützt, eine große Erleichterung für jeden Administrator und zugleich ein absolutes Muss, wenn es um die Präsenz der Datenbank in Firmen ohne große IT-Abteilung geht.

Der DB2 Configuration Advisor macht Vorschläge zum Optimieren der Konfigurationsparameter von DB2-Instanzen und einer Datenbank. Der Administrator gibt dafür einige sehr einfache Eckdaten vor: Er begrenzt zunächst den zur Verfügung stehenden Hauptspeicher des Servers. Das Lastprofil wird durch eine von drei möglichen Angaben (Abfragen, Transaktionen, beides gemischt) charakterisiert. Dabei reichen zum Beispiel einige grobe Informationen zum Umfang der Transaktionen (mehr oder weniger als zehn SQL-Befehle) sowie eine Schätzung der Anzahl solcher Transaktionen pro Minute.

Als nächstes kann der Administrator vorgeben, ob ihm eine höhere Transaktionsleistung oder eine schnellere Wiederherstellung wichtiger ist oder ob er auf beide Aspekte den gleichen Wert legt. Der Configuration Advisor will dann wissen, ob die Datenbank mit Daten gefüllt ist. Das schließt auch die Frage ein, ob die Katalogstatistiken aktuell sind, da die Größenangaben in die Berechnungen des Advisor eingehen.

Die Eingaben

Eine weitere Angabe betrifft wieder das Lastprofil, nämlich die durchschnittliche Anzahl lokaler und entfernter Benutzerverbindungen. Schließlich muss noch die überwiegende Art der Isolationsstufe (Benutzertrennung) vorgegeben werden, damit der Configuration Advisor den für die Sperren benötigten Speicherbereich abschätzen kann.

Nun kann der Datenbankadministrator wählen, ob der Configuration Advisor ihm nur die Vorschläge anzeigt oder die Parameter gleich selbst ändert. Der Konfigurationsassistent geht bei seinen Berechnungen von der Annahme aus, dass auf dem Server eine Instanz mit einer Datenbank eingesetzt wird. Nicht berücksichtigt werden von ihm die leider wachsende Anzahl von DB2-Umgebungsvariablen, die ebenfalls Einfluss auf die Performance haben.

Neben dem Configuration Advisor gibt es noch eine andere, von diesem unabhängige selbstkonfigurierende Funktion. Es ist in DB2 möglich, für die zu nutzenden Hauptspeicherbereiche eine Obergrenze vorzugeben. DB2 nimmt dann die Aufteilung des Hauptspeichers auf die einzelnen Bereiche (heaps) vor.

Der Design Advisor

Die Optimierung bestehender Anwendungen durch Strukturänderungen der Datenbank ist deshalb heikel, weil die Verbesserungen eines Zugriffs zum Beispiel durch zusätzliche Indizes an anderer Stelle zu Nachteilen führen können, denn mehr Indizes bedeuten einen zusätzlichen Aufwand bei Änderungen. Ein Werkzeug, das nicht nur Verbesserungsvorschläge unterbreitet, sondern auch deren Nebeneffekte analysiert, ist also ein wesentlicher Fortschritt für solche Optimierungsarbeiten.

Der Design Advisor dient der Verbesserung der bestehenden Datenbankstrukturen in Bezug auf eine definierte Last (Workload). Entscheidend für den erfolgreichen Einsatz ist die Vorgabe der korrekten, realen Last. Quellen für den Workload können einzelne SQL-Befehle sein, die über die Befehlszeile eingegeben werden, in Dateien oder Tabellen stehen, aus dem Cache des dynamischen SQL oder dem Query Patroller übernommen werden. Im Gegensatz zu Oracle mit seinem Automatic Workload Repository (AWR) besitzt DB2 keine zentrale Ablage, in der regelmäßig Informationen über den Workload gesammelt werden.

Der Design Advisor bedient sich intern des erweiterten Optimizer, der die Last für verschiedene Konfigurationsvarianten durchrechnet. Der Datenbankadministrator wählt dazu die Strukturen aus, die der Design Advisor bewerten soll: Indizes, gespeicherte Abfragetabellen (MQTs = materialisierte Sichten) und/oder MDC-Tabellen (mehrdimensionale Cluster-Tabelle). Die Verbesserungen werden nicht automatisch vorgenommen, sondern erst als Vorschlag zur Begutachtung angezeigt. Dabei werden auch nicht genutzte Strukturen aufgelistet. Der Administrator kann dann entscheiden, ob er diese löschen will.

Zum Beispiel mag ein Primärschlüssel-Index nicht für Zugriffe genutzt, aber auch nicht gelöscht werden, weil er für die Definition des Primärschlüssels und der damit verbundenen Eindeutigkeitsprüfung benötigt wird.

Der Learning Optimizer

Bei der Übersetzung von SQL-Befehlen wählt der Optimizer aufgrund der Katalogstatistiken die Zugriffspfade aus, die er als optimal errechnet. Dennoch können die ausgeführten Zugriffe weit hinter den erwarteten Ergebnissen zurückbleiben. Bislang ist dann eine aufwändige Analyse durch den Spezialisten nötig, um den Grund dafür herauszufinden. Nun übernimmt die Software wenigstens in einigen Teilen diese Aufgabe.

Der Lernende Optimizer, abgekürzt Leo, vergleicht die Annahmen, die er bei der Übersetzung eines SQL-Befehls und der Auswahl der passenden Zugriffspfade getroffen hat, mit den Ergebnissen der Ausführung des SQL-Befehls. Bei größeren Abweichungen sind eine Überprüfung der Annahmen und ihre Korrektur notwendig. Leo erkennt eine Reihe möglicher Ursachen für solche Abweichungen und versucht diese durch genauere Statistiken zu justieren. Dazu werden dem Dienstprogramm RUNSTATS entsprechende Parameter mitgegeben. Mit den verbesserten Statistikdaten kann der SQL-Befehl dann erneut übersetzt werden. Bisher haben IBM-Forscher diesen Ansatz nur als Konzept für DB2 vorgestellt. Eine erste Umsetzung ist in DB2 UDB V8.2 als automatisierte Statistikerstellung (Automatic Statistics Collection) implementiert worden.

Leo umfasst vier Komponenten. Die erste sichert die benötigten Informationen über den Zugriffsplan nach der Optimierung von Leo in einer speziellen Datei. Die zweite Komponente überwacht die Ausführung der Zugriffe und sammelt deren Daten in einer zweiten Datei. Der Overhead für dieses Monitoring wird von IBM mit weniger als fünf Prozent angegeben. Die dritte Komponente ist ein eigenständiger Hintergrundprozess, der die Unterschiede zwischen Plan und Ausführung analysiert und ergänzende Korrekturen im DB2-Katalog einträgt. Die Originalstatistiken werden dabei nicht überschrieben. Die vierte Komponente überarbeitet wiederholt den Zugriffsplan aufgrund der Katalogkorrekturen.

Das Tool erkennt eine Reihe möglicher Ursachen für solche Abweichungen. Diese können in einer mangelnden Aktualität der Katalogstatistiken ebenso begründet sein wie in Modellierungsfehlern.

Eine der häufigsten Abweichungen resultiert daraus, dass Abhängigkeiten zwischen Attributen nicht korrekt und vollständig modelliert wurden. Zum Beispiel sind in einer Automobiltabelle die Spalten "MARKE" und "MODELL" nicht unabhängig voneinander, denn bestimmte Modellbezeichnungen sind nur für eine Marke möglich, so etwa Vectra für Opel und Golf für VW.

Abhängigkeiten erkennen

Für eine Abfrage nach MARKE und MODELL würde der Optimizer zunächst die Selektivität der Abfrage als Produkt der Selektivität beider Spalten errechnen und den Zugriffspfad entsprechend bestimmen. In Wirklichkeit jedoch darf nur die größere der Spaltenselektivitäten vom Optimizer benutzt werden.

Hier ein Beispiel zur Optimizer-Berechnung bei voneinander abhängigen Spalten:

20 Marken => Selektivität = 1/20 = 0,05

100 Modelle => Selektivität = 1/100 = 0,01

SELECT * FROM AUTOS

WHERE MARKE = ‘Porsche’ AND MODELL = ‘911’;

Vermutete Selektivität der Abfrage:

0,05 * 0,01 = 0,0005

Da aber die Modellbezeichnung "911" nur bei Porsche vorkommt, ist die reale Selektivität 0,01. Der lernende Optimizer kann solche Abhängigkeiten nun erkennen und durch eine Korrektur der Katalogstatistiken justieren.

Statistiken automatisiert

Wie bereits erwähnt, verbirgt sich die Implementierung des Leo-Konzepts in DB2 V8.2 hinter der automatischen Statistikerfassung. Wird diese Funktion als Teil der automatischen Verwaltung gewählt, sammelt DB2 im Hintergrund selbständig Katalogstatistiken. Dabei werden die RUNSTATS-Läufe so ausgeführt, dass sie den normalen Betrieb möglichst wenig stören. In erster Linie werden Tabellen mit hoher Pflegeaktivität (Update, Delete, Insert = UDI) betrachtet. Für große Tabellen (über 4000 Pages) wird über Stichproben geprüft, ob die Statistiken der jeweiligen Tabelle durch die Pflegeaktivitäten beeinflusst werden.

Statistikprofile helfen, für die einzelne Tabelle optimierte Statistiken zu sammeln. Solche Profile können vom Datenbankadministrator explizit angelegt oder automatisch erstellt werden. Grundlage für die automatische Erstellung der Profile ist das Sammeln der Datenbankaktivitäten in einem Query-Feedback-Warehouse (QFW).

Intern überwacht ein Activity Monitor die UDI-Aktivitäten und speichert die Informationen in den zugehörigen Tabellendeskriptoren. Diese Informationen werden vom Activity Analyzer ausgewertet. Ein Plan Monitor und ein Runtime Monitor sammeln die Zugriffspläne und die Ausführungsergebnisse von Abfragen im QFW. Der Query Feedback Analyzer wertet diese Informationen aus und erstellt Änderungen für Statistikprofile. Ein Scheduler startet RUNSTATS aufgrund der Ergebnisse von Activity Analyzer und Query Feedback Analyzer. Automatisch erstellte Statistikprofile werden derzeit in SMP- und MPP-Umgebungen noch nicht unterstützt.

IBM empfiehlt die automatische Statistikerstellung mit Profilen und dem Query-FeedbackWarehouse besonders für Datenbankanwendungen mit komplexen Abfragen, weniger für transaktionsorientierte Anwendungen mit meist recht einfachen Abfragen.

Autonomic Object Maintenance

Zur ungeliebten Routine eines Datenbankadministrators gehören die regelmäßigen Sicherungen und Reorganisationen mit ihren Folgearbeiten wie dem Sammeln aktueller Statistiken oder dem "REBIND" betroffener Packages. Entlastung verschaffen hier schon seit längerem Werkzeuge verschiedener Anbieter, die diese Maßnahmen abhängig von diversen Parametern automatisch ausführen.

Unter dem Schlagwort Autonomic Object Maintenance (automatische Verwaltung) werden nun Funktionen zur automatisierten Administration einer Datenbank zusammengefasst. Dazu gehören die Sicherung der Datenbank, die Reorganisation von Tabellen und das Sammeln von Katalogstatistiken. Der Administrator kann individuelle Rahmenbedingen wie die Zeit eines Wartungsfensters oder die Notwendigkeit zu reinen Online-Operationen vorgeben. (ue)