Hans Leker ist Senior System Engineer bei der Standard Elektrik Lorenz AG, Software Devision.
Die Vorteile von DB2 sind bestens bekannt und hinreichend publiziert worden. Weniger bekannt ist jedoch, wie schwer sich auch erfahrene DBMS-Anwender damit tun, eine akzeptable Performance in dieser IBM-Datenbank zu erreichen. Eine besondere Rolle spielen dabei die in diesem Artikel erläuterten Indizes und Pages.
Wer annimmt, mit dem Kauf einer Version von DB2 hätte er alle Vorteile des Produktes auch in seinem System zur Verfügung, begeht einen folgenschweren Irrtum. Sehr schnell wird ihm klar, daß er viel Zeit vergeblich aufgewendet hat.
Richtig verstanden und betrieben, bietet DB2 bemerkenswerte Vorteile. Um es optimal nutzen zu können, ist ein Zusammenwirken von System- und Anwendungsprogrammierern, DBAs und Endbenutzern sowie konsequentes Reinstallieren von wesentlicher Bedeutung. Probleme ergeben sich, wenn unterschiedliche Interessen zu Konflikten während der operationalen Phase führen.
Hierzu ein Beispiel aus einem typischen Problembereich: DBAs verwalten Datenbanken nach physikalischen Regeln; somit sind die Designüberlegungen für sie in den meisten Fällen auf physikalische Aspekte ausgerichtet. Festlegung und Entwurf der logischen Zusammenhänge geschehen im Rahmen der Anwendungsprogrammierung. Hier werden häufig Zugriffe auf DB2-Tabellen programmiert, ohne daß bekannt ist, welche Auswirkungen sich dabei auf DB2 und die Performance der Anwendung ergeben. Ein wenig Licht in das Dunkel dieses Teils der DBMS-Welt soll folgender Abschnitt bringen.
DB2-Indizes können neue Anwender erheblich verwirren. Bei der Vielzahl von Parametern, die bei einem CREATE-INDEX-Statement angegeben werden können, geschieht es sehr schnell, daß eine falsche Entscheidung gefällt wird. Will man also das Richtige tun, ist es erforderlich, einige grundsätzliche Zusammenhänge der Struktur eines DB2-Indexes zu kennen.
Ein DB2-Index ist eine VSAM-Datei, die sich in zwei Kategorien von Pages einteilen läßt.
Kategorie 1: Pages, die Informationen über die VSAM-Datei enthalten; zwei Arten von Pages gehören in diese Kategorie: Header- und Space-Map-Pages. Beide enthalten einige interne Kontrollinformationen, wie die Gesamtzahl der Pages und die zuletzt benutzte Page der Datei. Kategorie 2: Pages, die Informationen über die Index-Datei enthalten; diese können Root-, Leaf- und Non-Leaf-Pages sein. Die Struktur eines DB2-Indexes ist sehr Tree-ähnlich; daher die Namen Root, Non-Leaf und Leaf.
Jeder Index enthält immer eine Root-Page. Er kann über eine beliebige Anzahl von Non-Leaf und Leaf-Pages verfügen. Der einfachste Weg, die Verbindungen dieser Pages zu verstehen, ist, den Aufbau des Index zu untersuchen. Angenommen, man beginnt mit einem leeren Index und benutzt "unique keys". Jetzt soll ein Index-Entry mit einem Key von 20 hinzugefügt werden. DB2 bildet eine Root-Page und macht einen Eintrag in dieser Page: den Key (20) und einen 4-Byte-Pointer der auf die Zeile in der Tabelle verweist, die diesen als RID bekannten Key enthält (siehe Abbildung 1 ). Da die Root-Page eine feste Größe hat (4K), wird sie irgendwann gefüllt sein. Wenn ein Root-Page voll ist, führt DB2 ein Page-Split durch.
Ein Page-Split bewirkt drei Dinge:
- Zwei neue Leaf-Pages werden dem Index hinzugefügt. DB2 überträgt jeweils die Hälfte der Root-Page in die neuen Leaf-Pages.
- Die Root-Page-Einträge werden gelöscht. Dafür entstehen zwei neue Einträge. Sie enthalten den höchsten Key, der auf jeder der beiden Pages auf dem nächst niedrigeren Level gespeichert ist und einen Pointer, der auf diese Pages verweist.
- Der Index-Eintrag, der das Splitten der Root-Page verursacht hat, wird der entsprechenden Leaf-Page hinzugefügt.
Bild 2 zeigt den entsprechenden Index. Dieser Index ist als "Two-Level-Index" bekannt.
Es ist zu beachten, daß nur die Leaf-Pages Pointer auf die Tabelle enthalten. Alle anderen Pages dienen nur dazu, den Weg (Route/Chain) zur richtigen Leaf-Page zu zeigen. Neue Einträge in diesem Index werden in der entsprechenden Leaf-Page vorgenommen. Ist eine Leaf-Page voll, wird auch für sie ein Page-Split durchgeführt. Eine neue Leaf-Page wird erzeugt und die Hälfte der Einträge dorthin übertragen. Außerdem wird ein neuer Eintrag in der Root-Page für diese Leaf-Page vorgenommen.
In einem DB2-Index sind die Leaf-Pages immer auf demselben Level. Jetzt liegt die Frage nahe, was passiert, wenn die Root-Page keine weiteren Leaf-Page-Pointer mehr aufnehmen kann. Die Root-Page wird wieder gesplittet, und es entstehen zwei "intermediate pages". Diese Pages sind die Non-Leaf-Pages und enthalten Keys mit Pointern auf die zugehörigen Leaf-Pages.
Der Index enthält jetzt drei Ebenen (Levels). Ein DB2-Index kann aus beliebig vielen Ebenen bestehen. Jede neue Ebene ist ein weiterer Satz von Non-Leaf-Pages zwischen den Root- und Leaf-Pages. Sie hat einen negativen Einfluß auf die allgemeine Performance des Index und somit auch auf jede Anwendung, die diesen Index benutzt.
Vier Hauptfaktoren bestimmen die Anzahl der Ebenen eines Indexes:
1. Die Anzahl der indizierten Zeilen (Rows): je mehr Index. Einträge bestehen, um so größer muß der "Index-Tree" sein, um diese aufnehmen zu können.
2. Die Länge des Index-Keys: Lange Keys bedeuten, daß jede Page im Index weniger Einträge aufnehmen kann.
3. Die Art des Einfügens: Angenommene Daten werden nach Key sortiert, bevor sie eingefügt werden. Da jeder Eintrag dem Index hinzugefügt wird, ist die Wahrscheinlichkeit hoch, daß er in der zuletzt erzeugten Leaf-Page eingefügt wird. Das führt zu häufigen Splits der Leaf-Pages und erhöht die Anzahl der Index-Ebenen.
4. Der Pctfree-Wert für diesen Index: Für jeden Index kann ein Prozentsatz angegeben werden, der als Free-space-Bereich einer Page gilt je höher der Pctfree-Wert, desto schneller werden die Pages als "von" betrachtet. Ein wichtiger Punkt bezüglich Pctfree sollte nicht vergessen werden: Dieser Wert wird nur benutzt, wenn der Index reorganisiert wird oder an einer DB2-Loadoperation beteiligt ist. Stehen SQL-Inserts an, ist die Pctfree-Angabe ohne Bedeutung.
In dieser Diskussion über DB2-Index-Strukturen wurde die interne Struktur vereinfacht dargestellt, um die Problematik zu verdeutlichen.
Als nächstes geht es um das Konzept der Subpages (oder der Frage, wann ein Leaf nicht gleich eine Leaf-Page ist).
Das größte Problem einer Leaf-Page besteht in dem gleichzeitigen Zugriff mehrerer Benutzer auf sie. Fordert ein Programm ein LOCK für einen Table-Space, so fordert es möglicherweise auch LOCKs für bestimmte Index-Pages. Diese LOCKs gelten für die gesamte Page des Indexes. Wenn andere Benutzer zur gleichen Zeit Informationen in der Tabelle ändern wollen und dabei denselben Index benutzen, werden sie ausgeschlossen, weil sie eine Zeile (ROW) benutzen, die einen Index-Eintrag in derselben Page hat, die durch das Programm gesperrt wurde, je kleiner die Spalten des Indexes, um so größer ist das Problem, da mehr Index-Einträge auf eine Page passen,
IBM bietet eine Lösung: Subpages-Parameter. Es können mehrere Leaf-Pages in Subpages aufgeteilt werden. Jede Subpage verhält sich genauso wie eine Leaf-Page; sie stellt natürlich auch Platz für neue Einträge bereit. Wenn eine Leaf-Page Subpages enthält, wird von DB2 ein LOCK nur auf die Subpage durchgeführt. Somit sind alle anderen Entries der Leaf-Page im freien Zugriff. Mehr Subpages heißt, es sind mehr konkurrierende Zugriffe auf indizierte Tabellen möglich.
Subpages haben Ihren Preis
Wenn ein Index erzeugt wird (CREATE INDEX), ist der Subpage-Parameter einzusetzen. Leaf-Pages können in eins, zwei, vier, acht oder 16 Subpages aufgeteilt werden. Ein so erzeugter Index kann in einem DB2-System kleiner als 2,1 nicht mittels ALTER geändert werden. Subpages sollten nur im Zusammenhang mit LOCKING erwogen werden, ebenso die Möglichkeit daß "multiple Subpages" die "Konkurrenz" fördern.
Subpages in einem Index haben ihren Preis:
1. Sie bedeuten eine Erhöhung des Verarbeitungsaufwandes, wenn mit dem Index gearbeitet wird. Dieser Aufwand ist bedingt durch die Extrazeit, die für das Verwalten der Subpage-Struktur benötigt wird, somit abhängig von der Häufigkeit der Index-Änderungen.
2. Sie haben Auswirkungen auf den Speicher- und Plattenplatz-Bedarf. Es besteht ein fixer Storage-Overhead für Subpages. Daher: je mehr Subpages, desto größer der Index.
Jetzt seien noch zwei einfache Regeln erwähnt, einen angemessenen Subpage-Parameter auszuwählen.
1. Wenn konkurrierende Zugriffe erforderlich sind, sollte Subpage genutzt werden. Beispiel: Wenn ein Index für eine Tabelle besteht, die "private" oder "read only" ist, läßt sich das Thema Konkurrenz vernachlässigen. Der Preis für Subpage wäre zu hoch.
2. Wenn mit "clustered Index" gearbeitet wird, sollte der Wert für Subpage wie folgt definiert werden: Anzahl der Index-Einträge/Subpage = Anzahl der Zeilen der Daten-Page.
Warum? Wenn DB2 ein LOCK für eine Daten-Page ausführt, werden alle diese Zeilen gesperrt. Wenn die Index-Einträge für diese Daten-Page auf einer Subpage zusammengefaßt werden, ergibt sich eine Eins-zu-eins-Beziehung von Index-Page-LOCK zu Daten-Page-LOCK.
Natürlich kann es schwierig sein, einen passenden Wert zu wählen, wenn es um VAR-CHAR-Spalten, non-unique-Indizes etc. geht, zumal der Wert nur eins, zwei, vier, acht oder 16 sein darf. So komplex auch der Einsatz von Index-Subpages erscheinen mag, bei Berücksichtigung der oben genannten Überlegungen wird ein "tunen" der Indizes auch auf der Anwendungsseite möglich sein.
Werden die bis jetzt angeführten Überlegungen gemeinsam von DBA, System- und Anwendungsprogrammierern erörtert und während der Planung rechtzeitig berücksichtigt, kann die Performance des Systems von vornherein richtig beurteilt werden. Die durch den DB2-Optimizer vorgenommenen Optimierungen sind durch "richtige" SQL zu steuern. Außerdem ist es bei Kenntnis dieser Dinge ein Leichtes, mit entsprechenden Hilfsmitteln weitreichende Analysen, Korrekturen und letztlich eine Anwendungsoptimierung über die DB2-Optimizer-Möglichkeiten hinaus, vorzunehmen.
Besonders wichtig ist, in diesem Rahmen Pfadanalysen über die von DB2 gewählten Pfade anzustellen. Dies kann manuell oder automatisch (ProAlter/Plus) erfolgen. entscheidend ist, daß nicht oder falsch genutzte Indizes erkannt werden und so eine Optimierung der Anwendung erfolgen kann.
Werden DB2-Systeme in allen ihren Komponenten beobachtet und Veränderungen von System und Anwendungen erkannt, ist es kein Problem, eine gute Performance zu erhalten (vorausgesetzt, es ist eine Verbesserung grundsätzlich Möglich). Kein System zeigt seine Lebendigkeit so intensiv und deutlich wie DB2. Daher reicht es nicht aus, nur System-Tuning zu favorisieren. Anwendungen und System bilden eine Einheit, die vielen Einflüssen unterworfen ist. Diese müssen bei Entwicklung, Systemtechnik sowie Administration bekannt sein, damit ein optimaler Einsatz der DB2-Vorteile Möglich wird.
Das "RDBMS"-Label ziert Mogelpackungen
"Es war immer schon alles relativ relational." Dieser Satz realisiert, daß die Anbieter "relationaler" DBMS-Produkte ausnahmslos zuviel versprechen. "Adabas" in unsere Marktübersicht aufzunehmen, ist sicher fragwürdig; wir haben dem Wunsch des Anbieters dennoch entsprochen (siehe oben). Hingegen fehlt an dieser Stelle das vergleichsweise "relationalere" DB2: Ein Nachtrag in der nächsten CW wird auch zu diesem Produkt die Angaben bringen. Diese Übersicht erhebt keinen Anspruch auf Vollständigkeit.