Die Zielvorgabe für den DB2-Einsatz ist klar: Bereitstellung der richtigen Information für die richtigen Leute zur richtigen Zeit. Aber das ist leichter gesagt als getan, denn DB2 stellt das DV-Management vor gewaltige Aufgaben.
Vollständige Indexbäume sind das Hauptwerkzeug von DB2, wenn es darum geht, die Abfrageleistung in Benutzertabellen zu verbessern. Mit Hilfe eines Indexes und relativ wenigen IOs kann DB2 exakt die Row ermitteln, die eine Abfrage beantwortet. Zumindest wird die Gruppe von Table Space Pages eingegrenzt die zur Herleitung der Antwortmenge untersucht werden müssen. In bestimmten Fällen hat DB2 die Möglichkeit, die Abfrage auch direkt aus dem Index, ohne Rückgriff auf den Table Space, zu beantworten.
Eine weitere wichtige Aufgabe der Indizes besteht darin, Eindeutigkeit zu akzeptablen Kosten zu gewährleisten. Die Struktur eines Indexes schreibt vor, daß es einen "richtigen" Platz für einen zu speichernden Schlüssel geben muß. Wenn sich an diesem Platz bereits ein identischer Datensatz befindet, wird das Duplikat schnell und effizient erkannt (die Duplikatsprüfung ohne Indizes wäre zwar logisch einfach, aber sehr aufwendig). Alle vorhandenen Table Rows müßten überprüft werden, um festzustellen, ob eine der Index-Columns denselben Wert wie die eingefügte Row besitzt.
Man muß den Aufbau von lndexbäumen kennen
Die Leistung von DB2 verschlechtert sich, wenn mehrere Indexstufen hinzugefügt werden. Für jede weitere Stufe sind zusätzliche I0s nötig, um Indexwerte abzurufen. Dadurch verlängert sich die Antwortzeit. Da das System die Stufen automatisch einrichtet, sollte der Programmierer die entsprechenden Situationen kennen. Dazu wiederum muß man den Aufbau von Indexbäumen kennen.
DB2 kennt drei Typen von Index Pages: Leaf, Non-Leaf und Root (siehe Abbildung 1). Leaf Pages zeigen auf Daten-Rows und entsprechen der Folgestufe der KSDS (Key-Sequenced Data Set) von BSAM. Non-Leaf und Root Pages entsprechen der Indexstufe. Schlüssel für Leaf Pages sind über Non-Leaf Pages mit der Root Page verkettet.
Die Root Page ist physisch die dritte Page eines DB2-Indexes. Ganz zu Anfang stehen zwei Control Pages - eine Physical Header Page und eine Logical Header Page (erste Space-Map-Page) - die technische Deskriptoren, die Wertebereiche der Schlüssel, Angaben zur Freiplatzverwaltung und sonstige allgemeine Daten zur Indexverwaltung enthalten.
Zum besseren Verständnis des folgenden muß auf eine Grundvoraussetzung hingewiesen werden: Das System arbeitet mit eindeutigen Schlüsseln und einer einzigen Subpage (optional können Index Leaf Pages in Subpages unterteilt werden, mit dem Ziel, einen höheren Grad an Parallelität zu erreichen). Wenn der Index um einen ersten Schlüssel erweitert wird, erfolgt die Integration der Root in Page 2; diese ist auch die dritte Page des Indexes. Die Daten in den Index-Pages bestehen einfach aus dem Schlüssel und einem 4-Byte-Pointer zur entsprechenden Row in der Datentabelle. Andere Pages des Index-Datensets sind nicht betroffen. An diesem Punkt ist die Root Page auch wirklich eine Leaf Page. Der zweite und jeder weitere Schlüssel werden der Root Page auf dieselbe Art und Weise hinzugefügt, bis sie von ist. Nun kommt es zu einem fundamentalen Ereignis - die Root Page teilt sich (siehe Abbildung 2).
Die erste Hälfte der Schlüssel der Root Page wird auf Page 3, die andere Hälfte auf Page 4 verteilt. Für eine effizientere Suche und für die spätere Teilung auf Leaf-Level sind die Schlüssel vorwärts und rückwärtsverkettet.
Der bisherige Inhalt der Root Page (Page 2) wird gelöscht - all ihre Daten befinden sich jetzt auf Page 3 und 4. Statt dessen erhält sie zwei neue Einträge, die auf die Pages 3 und 4 verweisen. Jeder Eintrag setzt sich zusammen aus dem höchsten Schlüssel, der in der entsprechenden Page auf dem nächstniedrigeren Level vorkommt, und der 3 Byte großen PageNummer.
Schließlich wird der Schlüssel, der die Teilung der Root verursacht hat, eingetragen. Abhängig von seinem Wert wird Page 3 oder 4 gewählt. Ist der neue Schlüssel kleiner als der höchste von Page 3 (das ist nur möglich, wenn die Eintragungen nach dem Zufallsprinzip erfolgen), wird Page 3 gewählt; im anderen Fall Page 4. Ist der neue Schlüssel größer als der höchste von Page 4 (vermerkt in der Root Page), wird die Root Page mit diesem Schlüssel aktualisiert.
An diesem Punkt besteht der Index zusätzlich zu den Control Pages von DB2, aus drei Pages. Page 2 bleibt dabei die einzige Root Page des DB2-Index. Die Leaf Pages 3 und 4 sind etwa halb von. Aus einem einstufigen Index wurde ein zweistufiger. Immer wenn die Root Page "überläuft" und geteilt werden muß, kommt eine zusätzliche Indexstufe hinzu.
Wenn weitere Einträge in den Index erfolgen, wird schließlich eine der Leaf Pages voll. Angenommen, dies sei Page 4 (was bei sequentieller Eingabe der Fall ist). In diesem Fall teilt sich die Leaf Page 4 auf genau die gleiche Weise wie die Root Page (siehe Abbildung 2). Etwa die Hälfte der Daten wird auf Page 5 verlagert, der Rest verbleibt in Page 4. Die Pages 4 und 5 sind vorwärts und rückwärts miteinander verkettet. Ein Eintrag für den höchsten Schlüssel von Page 5 erfolgt in der Root Page. Der Eintrag in der Root Page für den höchsten Schlüssel von Page 4 wird aktualisiert, so daß er die Umsetzung der Hälfte der Daten in Page 5 widerspiegelt.
Zum Schluß wird dann der Schlüssel hinzugefügt, der zur Teilung von Page 4 geführt hat. Abhängig vom Wert dieses Schlüssels kommen Page 4 oder 5 zum Zuge. Ist er kleiner als der höchste Schlüssel von Page 4 (was bei Eintragungen nach dem Zufallsprinzip der Fall ist), wird Page 4 gewählt.
Nun besteht der Index - neben den beiden Control Pages - aus vier Pages mit Daten. Page 2 bleibt die Root Page, Page 3, 4 und 5 sind die Leaf Pages, die letzten beiden etwa halb voll. Der Index hat jedoch weiterhin zwei Stufen, weil die Root Page ja nicht geteilt wurde.
Bei weiterem Dateneingang in die Leaf Pages füllen sich diese und teilen sich. Jede Teilung erzeugt eine neue Leaf Page und einen Eintrag mit deren Beschreibung in die Root Page. Schließlich ist in der Root Page kein Platz mehr. Sie teilt sich ein zweites Mal und erzeugt dabei die ersten Non-Leaf Pages, so wie bei der ersten Teilung die zwei Leaf Pages entstanden sind. Der Index hat dann drei Stufen, die Non-Leaf Pages weisen das gleiche Format wie die Root Page auf.
Anzahl der Stufen theoretisch unbegrenzt
Theoretisch ist die Anzahl der Stufen unbegrenzt. Zwischen der Root Page und den Leaf Pages können sich unterschiedlich viele Non-Leaf-Stufen befinden. Die Anzahl der Stufen hängt von einigen Faktoren ab:
- Länge des Schlüssels,
- Anzahl der indizierten Datensätze,
- Zugangsfolge,
- Freespace pro Subpage (PCTFREE),
Folgende Faktoren tragen dazu bei, die Anzahl der Stufen zu erhöhen:
- lange, aus mehreren Columns zusammengesetzte Schlüssel oder Einbeziehung von VARCHAR-Columns,
- Tables mit vielen Rows,
- sortierte Zugänge, die nach dem Laden dazu führen, daß sich die zuletzt angelegte Leaf Page kurz darauf teilt,
- zuviel Freespace pro Subpage, mit der Folge, daß beim Laden zu viele Stufen angelegt werden und anschließend wenig Teilungen erfolgen.
Wenn zu viele Stufen aus der Zugangsfolge oder einem ungeeigneten Wert für PCTFREE resultieren, läßt sich eine Stufe durch Reorganisation des Index-Space, gegebenenfalls nach Einstellung von PCTFREE, beseitigen. Die Überwachung von NCLEVELS aus SYSIBM. SYSINDEXE reicht nicht aus, weil DB2 im laufenden Betrieb diese Werte nicht pflegt.
Wem an optimaler Performance gelegen ist, der sollte die Anschaffung spezieller Tools zur Indexüberwachung und -pflege (etwa Candles DB2-Spaceman) ins Auge fassen.