Db2 (LUW) Ausführungsplan-Operationen

Eine kurze Referenz der wichtigsten Operationen, die in einem Db2 Ausführungsplan häufig aufscheinen. Die vollständige Liste gibt es in der IBM-Dokumentation.

Index- und Tabellenzugriffe

IXSCAN

Der IXSCAN durchwandert den Indexbaum und folgt an­schlie­ßend der Blattknoten-Liste, um alle Treffer zu finden. Siehe Kapitel 1, „Anatomie eines SQL Indexes“.

Die sogenannten Index-Filterprädikate („SARG“ im Ausführungsplan) sind ein häufiges Perfor­mance­problem beim IXSCAN. Der nächste Abschnitt erklärt, wie man sie erkennt. Diese Operation ist den INDEX ... SCAN-Operationen der Oracle-Datenbank ähnlich.

Wenn es weder START noch STOP-Prädikate zu einem IXSCAN gibt, bedeutet das, dass der komplette Index gelesen wird. Er wird also nur wie eine kleinere Version der Tabelle benutzt.

Die last_explained-View zeigt einen in Klammer an, ob der Index in abfallender Richtung gelesen wird (IXSCAN (REVERSE)).

FETCH

Lädt eine Tabellenzeile anhand der RID aus einer vorangegangenen Index-Operation. Siehe Kapitel 1, „Anatomie eines SQL Indexes“. Ähnlich einem TABLE ACCESS BY ... ROWID der Oracle-Datenbank.

TBSCAN

Auch bekannt als Full-Table-Scan (FTS). Liest die ganze Tabelle – alle Zeilen – wie gespeichert, das heißt, in „zufälliger“ Reihenfolge. Obwohl die Blöcke nicht einzeln, sondern mehrere auf einmal gelesen werden, gehört TBSCAN zu den teuersten Operationen überhaupt. Neben der Last am Speichersystem ist ein Full-Table-Scan auch sehr CPU-intensiv, da alle Tabellenzeilen gegen die where-Klausel geprüft werden müssen. Siehe auch „Full-Table-Scan“.

Ähnlich einem TABLE ACCESS FULL in der Oracle-Datenbank.

RIDSCN

Diese Operation wird bei Index-Merge verwendet und – vermutlich häufiger – in Kombination mit SORT um die Datenseiten nach einem IXSCAN effizient zu laden (prefetch).

Join-Operationen

Join-Operationen verbinden grundsätzlich nur zwei Tabellen auf einmal. Falls mehrere Join-Operationen in einer Abfrage vorkommen, werden sie schrittweise durchgeführt; zuerst zwei Tabellen, dann das Zwischen­er­geb­nis mit der nächsten. Insofern kann der Begriff „Tabelle“ im Folgenden auch ein Zwischenergebnis bezeichnen.

NLJOIN

Verbindet zwei Tabellen, indem es für jede Zeile aus der ersten Tabelle eine Abfrage auf die zweite macht. Siehe „Nested Loops – verschachtelte Schleifen“.

HSJOIN

Ein Hash-Join lädt die möglicherweise passenden Zeilen aus der einen Tabelle in ein assoziatives Array (Hash-Table), das dann für jede Zeile der zweiten Tabelle abgefragt wird. Siehe „Hash-Join“.

MSJOIN

Der Merge-Join verbindet zwei Tabellen wie ein Reißverschluss. Beide Tabellen müssen vorsortiert sein. Siehe „Sort-Merge“.

ZZJOIN

Ein Mehrtabellen-Join (mehr als zwei) speziell für Datawarehouse-Datenbanken im Stern-Schema.

Sortieren und Gruppieren

SORT

Sortiert das Ergebnis entsprechend der order by-Klausel. Diese Operation benötigt Speicher zum Materialisieren des Zwischen­er­geb­nis (keine Ausführung „am Fließband“). Diese Operation wird auch verwendet, um die benötigte Reihenfolge für einen darauffolgende MSJOIN- oder GRPBY-Operation herzustellen. Darüber hinaus wird SORT auch verwendet, um Duplikate aufgrund einer distinct-Operation zu entfernen. Siehe „ORDER BY indizieren“.

Der View last_explained zeigt in Klammern an, ob eine de-duplizierung stattfindet (SORT (UNIQUE)) oder eine Top-N-Optimierung vorgenommen wird (z.B. bei fetch first ... rows only).

UNIQUE

De-dupliziert die Zeilen einer vorsortierten Menge. Wird bei distinct verwendet, wenn die nötige Reihenfolge ohne SORT-Operation besteht (z.B. wenn ein IXSCAN die Zeilen bereits in der benötigten Reihenfolge liefert). Andern falls wird die de-duplizierung im Rahmen der SORT-Operation vorgenommen.

GRPBY

Führt eine Gruppierung entsprechende der group by-Klausel aus. Dabei kommt entweder ein Sort/Group-Algorithmus, oder seit Version 10.1 ein Hash-Algorithmus zum Einsatz. Siehe „GROUP BY indizieren“.

Der View last_explained zeigt den Algorithmus in Klammern an (z.B. GRPBY (HASH COMPLETE)).

Top-N-Abfragen

Die Db2-Datenbank hat keine Ausführungsplan-Operationen, die direkt auf eine Top-N-Klausel wie zum Beispiel fetch first ... rows only hinweisen. Falls dafür jedoch eine SORT-Operation benötigt wird, zeigt der last_explained-View die Top-N-Optimierung in Klammern an (SORT (TOP-N)).

Falls keine SORT-Operation benötigt wird, hinterlässt eine Top-N-Klausel keine sichtbaren Spuren im Ausführungsplan. Hinweise können dann sein, dass der Cost-Wert oder die Zeilenschätzungen unvermittelt kleiner werden, ohne dass es durch ein Prädikat zu erklären wäre.