Kosten-Nutzen-Analyse der Datenbankpflege

Stefan Dorendorf ist Leiter der Studienrichtung Wirtschaftsinformatik an der Berufsakademie Gera.

Die Betreiber grösserer, Datenbank-gestützter Anwendungssysteme sehen sich mit ständig steigenden Datenmengen, Benutzerzahlen und Transaktionsvolumina sowie hohen Verfügbarkeitsanforderungen konfrontiert.

So steigt beispielsweise im Bankenbereich nicht zuletzt aufgrund von E-Banking und Bankomaten die Zahl der anfallenden Buchungen stetig an. Ein weiteres Beispiel sind Logistikunternehmen. Diese betreiben vermehrt Systeme zur Sendungsverfolgung, was entsprechende Datenmengen generiert. Und auch im Bereich der mobilen Kommunikation ist die Zahl der Nutzer und der Anwendungsmöglichkeiten stark gestiegen.

Mit steigender Nutzerzahl und der dadurch generierten Zunahme der Transaktionsvolumina steigt in der Regel auch der Wartungsbedarf für die Datenbanken. Einfüge-, Lösch- und Änderungsoperationen führen zu Degenerierungen in den internen Speicherstrukturen. Es entstehen Freispeicherlücken, erwünschte Sortierreihenfolgen gehen nach und nach verloren, zusammengehörige Datenmengen werden in mehreren Fragmenten über grössere Bereiche der Datenträger verteilt gespeichert.

Solche Degenerierungen führen zu einer Erhöhung des Speicher- und Verarbeitungsaufwands und damit zu höheren Kosten. Um diesen Kostenzuwachs relativ zur zu speichernden Datenmenge zu reduzieren, müssen physische Speicherstrukturen in gewissen Abständen neu aufgebaut beziehungsweise bereinigt werden. Mit anderen Worten: Die Datenbank muss regelmässig reorganisiert werden.

Die Durchführung einer solchen Datenbankreorganisation ist allerdings auch mit gewissen Herausforderungen verbunden. Einerseits verursacht der Reorganisationsaufwand selbst ebenfalls Kosten. Andererseits muss mit Einschränkungen im normalen Datenbankbetrieb gerechnet werden. Diese reichen von der Verzögerung von Benutzertransaktionen durch Sperrkonflikte bei Online--Reorganisationsverfahren bis zu Verfügbarkeitsausfällen jener Datenbankteile, welche sich aktuell in Reorganisation befinden. Solche Offline-Reorganisationen können daher im Regelfall nur innerhalb sogenannter Wartungsfenster durchgeführt werden - was in direktem Widerspruch zu den oftmals hohen Verfügbarkeitsanforderungen steht.

Es ist somit wünschenswert, bereits vor der Durchführung einer Reorganisation die dadurch entstehenden Kosten und den damit erzielbaren Nutzen möglichst genau quantifizieren zu können. Der Nutzen bezüglich des Verarbeitungsaufwands ist insbesondere vom Workload abhängig, also von den gegen die Datenbankobjekte gerichteten Anweisungen und deren Ausführungshäufigkeiten.

Im Rahmen der Forschungsaktivitäten am Lehrstuhl für Datenbanken und Informationssysteme der Friedrich-Schiller-Universität Jena wurde eine Methode zur
Abschätzung der Auswirkungen von Datenbankreorganisationen auf den zur Workload-Abarbeitung notwendigen I/O-Aufwand entwickelt. Dieser I/O-Aufwand lässt sich unter gewissen Umständen. wesentlich beeinflussen und stellt damit den hauptsächlichen Nutzen dar.

Für gängige Reorganisationsmethoden wurden Vorgehensweisen zur Kostenabschätzung vorgeschlagen. Mit Hilfe eines aus der mathematischen Optimierung bekannten Branch-and-Bound-Verfahrens ist es möglich, durch eine gezielte Auswahl der zu reorganisierenden Datenbankteile den bezüglich des I/O-Aufwands erreichbaren Nutzen einer Reorganisation bei -einer gegebenen Kostenobergrenze zu maximieren. Angestellte Untersuchungen stimmen optimistisch, dass die entwickelte Methode bis zur «Produktreife» entwickelt werden kann.

Die Ermittlung des Nutzens von Datenbankreorganisationen erfolgt bei dieser Methode in mehreren Schritten.

1. Das Workload-Protokoll: Erster Schritt und zugleich wichtigster Unterschied zu anderen, derzeit am Markt verfügbaren Produkten für die Analyse des Regenerationsbedarfs von Datenbanken, ist die Berücksichtigung des Workload. Diese ist aber zur Ermittlung des Nutzens einer Datenbankreorganisation bezüglich des Verarbeitungsaufwands notwendig. Ein weiterer Vorteil der vorgeschlagenen Methode ist dabei, dass benötigte Eingabegrössen auf den jeweiligen Produktionssystemen unter realistischen Bedingungen ermittelt werden, für welche die Analysen durchgeführt werden sollen.

Die Erzeugung des Workload-Protokolls kann durch die Protokollierung der gegen die Datenbank gerichteten Anweisungen durch die Anfrageverarbeitungskomponenten in einem repräsentativen Zeitraum auf dem jeweiligen Produktionssystem geschehen. Eine manuelle Erstellung wäre im Normalfall mit kaum vertretbarem Aufwand verbunden.

2. Aktualisierung der Statistikdaten: Aus Aufwandsgründen werden die von Datenbank-Management-Systemen (DBMS) geführten Statistikdaten, welche Informationen über den Zustand der internen Speicherstrukturen enthalten, oft nicht automatisch aktualisiert. Deshalb muss dies oft manuell initiiert werden.

3. Ermittlung der Ausführungspläne: Aus den einzelnen SQL-Anweisungen des Anweisungsprotokolls kann nicht direkt darauf geschlossen werden, wie diese Anweisungen vom DBMS intern realisiert werden. Im dritten Schritt werden daher die Anweisungen des Workload-Protokolls an den Anfrageoptimierer übergeben. Dieser ermittelt, unter Berücksichtigung vorhandener Statistikdaten, sogenannte Ausführungspläne, also Folgen einfacher Grundoperationen (Planoperatoren), mit denen gegebene SQL-Anweisungen in der konkreten Systemumgebung auf kostengünstige Weise ausgeführt werden können.

4. Ermittlung der entstehenden I/O-Kosten: Anhand des jeweiligen Ausführungsplans kann mit den vorgestellten Kostenfunktionen berechnet werden, welche I/O-Kosten die Anwendung der jeweiligen Planoperatoren verursacht. Dabei muss natürlich stets die Anzahl der Ausführungen des Planoperators berücksichtigt werden.

5. Zusammenfassung zum Gesamtplan: Im Rahmen der Ausführung verschiedener SQL-Anweisungen kommen die unterschiedlichen Planoperatoren je Datenbankobjekt in mehreren Ausführungsplänen vor. Zur -Begrenzung des Aufwands in den Folgeschritten werden Planoperatoren gleichen Typs, welche auf die gleichen Datenbankobjekte angewendet werden, in einem Gesamtplan kostenmässig zusammengefasst.

6. I/O-Kosten vor der Reorganisation: Durch Summierung der Kostenwerte für die im Gesamtplan vorkommenden Planoperatoren kann nun der vor einer geplanten Reorganisation anfallende I/O-Aufwand für die Abarbeitung der Workload berechnet werden.

7. Mehraufwand aufgrund von Degeneration: Unter Nutzung der bereits ermittelten aktuellen Statistikdaten kann im nächsten Schritt für alle zur Reorganisation vorgesehenen Datenbankobjekte berechnet werden, wie hoch (prozentual) der durch vorhandene Degenerierungen verursachte Mehraufwand für jeden auf das jeweilige Datenbankobjekt angewendete Planoperator ist.

8. I/O-Kosten nach der Reorganisation: Zur Abschätzung der I/O-Kosten nach einer erfolgten Reorganisation müssen vor der Summierung noch die Kostenwerte jener Planoperatoren, welche auf zu reorganisierende Datenbankobjekte angewendet werden, um den in Schritt 7 errechneten Mehraufwand verringert werden.

9. Berechnung des Nutzens: Nun werden die Kostenberechnungen für den I/O-Aufwand vor und nach der Reorganisation miteinander verglichen und so der Nutzen der Datenbankreorganisation bestimmt.

Die Ermittlung der Kosten für die Durchführung von Datenbankreorganisationen erfolgt mit Kostenmodellen, welche auf die jeweiligen Implementierungen der Reorganisationsmethoden zugeschnitten sind. Hier ergeben sich grössere Systemabhängigkeiten als bei der Nutzenermittlung, die aber kaum vermeidbar sind. Die berechneten Kosten können dann dem zu erwartenden Nutzen gegenübergestellt werden und es kann eine gezielte Auswahl der zu reorganisierenden Datenbankbereiche erfolgen.