Der SQL-Compiler führt mehrere Schritte aus, bevor ein Zugriffsplan erstellt wird, den Sie ausführen können. Eine Darstellung dieser Schritte finden Sie in Abbildung 78.
Abbildung 78. Schritte des SQL-Compilers
Wie in der Abbildung zu erkennen ist, stellt das Abfragediagrammodell eine Schlüsselkomponente des SQL-Compilers dar. Das Abfragediagrammodell ist eine interne, im Speicher befindliche Datenbank, die zur Darstellung der Abfrage durch den gesamten Prozeß der Abfragekompilierung hindurch verwendet wird, wie im folgenden näher erläutert wird:
Die erste Aufgabe des SQL-Compilers besteht darin, die SQL-Abfrage zu analysieren, um die Syntax auf Gültigkeit zu überprüfen. Wenn Syntaxfehler festgestellt werden, beendet der SQL-Compiler die Verarbeitung und die entsprechende SQL-Fehlernachricht wird an die Anwendung, die versuchte, die SQL-Anweisung zu kompilieren, zurückgemeldet. Wenn die Analyse abgeschlossen ist, wird eine interne Darstellung der Abfrage erstellt.
Die zweite Aufgabe des Compiler ist es sicherzustellen, daß es keine Inkonsistenzen zwischen Teilen der Anweisung gibt. Eine einfaches Beispiel für diese Semantikprüfung ist die Überprüfung, ob die Spalte für die Skalarfunktion YEAR mit dem Datentyp DATETIME (Datum/Uhrzeit) definiert wurde. Während dieser zweiten Phase fügt der Compiler auch die Bedingungssemantik in das Abfragediagrammodell ein, zu der die Auswirkungen der referentiellen Integritätsbedingungen, der Prüfungen auf Integritätsbedingungen in Tabellen, der Auslöser und der Sichten gehören.
Das Abfragediagrammodell enthält die gesamte Semantik von Abfragen, einschließlich der Abfrageblöcke, Unterabfragen, Korrelationen, abgeleiteten Tabellen, Ausdrücken, Datentypen, Datentypumsetzungen, Umwandlungen der Codepages und der Partitionierungsschlüssel.
In der dritten Phase verwendet der SQL-Compiler die vom Abfragediagrammodell zur Verfügung gestellte globale Semantik, um die Abfrage in eine Form umzusetzen, die leichter optimiert werden kann. Zum Beispiel kann der Compiler ein Vergleichselement verschieben und somit die Ebene ändern, auf der es angewandt wird, um dadurch potentiell die Abfrageleistung zu erhöhen. Diese Art der Verschiebung einer Operation wird als allgemeine Vergleichselementverschiebung (General Predicate Pushdown) bezeichnet. Weitere Informationen finden Sie in Umschreiben der Abfrage durch den SQL-Compiler.
In einer Umgebung mit partitionierten Datenbanken sind einige Abfrageoperationen für das System aufwendiger, wenn zum Beispiel folgende Funktionen zu verarbeiten sind:
Eine korrelierte Unterabfrage ist eine Unterabfrage, die einen Verweis auf eine Spalte einer Tabelle enthält, die sich außerhalb der Unterabfrage befindet.
In der partitionierten Umgebung kann bei einigen Abfragen eine Dekorrelation im Zusammenhang mit dem Umschreiben der Abfrage erfolgen.
Die übertragene Abfrage wird im 'Abfragediagrammodell' gespeichert.
Die Hauptfunktion dieses Schrittes ist, dem DB2-Optimierungsprogramm eine Empfehlung zu liefern, ob eine Operation an eine Datenquelle verschoben und fern ausgewertet werden kann, was als "Pushdown" bezeichnet wird. Diese Art von Pushdown-Aktivität ist für Datenquellenabfragen spezifisch und bildet eine Erweiterung zu den allgemeinen Operationen der Vergleichselementverschiebung.
Dieser Schritt wird nur ausgeführt, wenn Abfragen für zusammengeschlossene Datenbanken ausgeführt werden. Weitere Informationen finden Sie in Pushdown-Analyse.
Das SQL-Optimierungsprogramm des SQL-Compilers verwendet das Abfragediagrammodell als Eingabe und generiert viele alternative Ausführungspläne zur Erfüllung der Benutzeranforderung. Das Programm schätzt den Ausführungsaufwand mit Hilfe der Statistiken für Tabellen, Indizes, Spalten und Funktionen für jeden der verschiedenen Pläne ab, und wählt den Plan mit dem geringsten geschätzten Ausführungsaufwand aus. Das Optimierungsprogramm verwendet das Abfragediagrammodel, um die Abfragesemantik zu analysieren und Informationen zu einer Vielzahl von Faktoren, einschließlich Indizes, Basistabellen, abgeleitete Tabellen, Unterabfragen, Korrelationen und Rekursion, zu erhalten.
Das Optimierungsprogramm kann außerdem eine dritte Art von Verschiebeoperation (Pushdown) in Betracht ziehen, nämlich für Spaltenberechnungen und Sortierungen. Die Leistung kann erhöht werden, wenn die Auswertung dieser Operationen an die Komponente der Datenverwaltungsservices (Data Management Services) verschoben werden kann. Weitere Informationen finden Sie in Pushdown-Operatoren für Spaltenberechnungen und Sortierungen.
Das Optimierungsprogramm berücksichtigt auch, ob es Pufferpools verschiedener Größen gibt, wenn es die Auswahl der Seitengröße festlegt. Der Faktor, daß die Umgebung eine partitionierte Datenbank enthält, wird ebenso berücksichtigt wie die Möglichkeit, den auswählten Plan für eine potentielle abfrageinterne Parallelität in einer symmetrischen Mehrprozessorumgebung (SMP-Umgebung) auszulegen. Diese Informationen werden vom Optimierungsprogramm zur Auswahl des am besten geeigneten Zugriffsplans für die Abfrage verwendet. Weitere Informationen finden Sie in Datenzugriffskonzepte und Optimierung.
Die Ausgabe dieses Schritts des SQL-Compilers ist ein "Zugriffsplan". Dieser Zugriffsplan ist die Grundlage für die Informationen, die in den EXPLAIN-Tabellen erfaßt werden. Die Informationen, die zur Generierung des Zugriffsplans dienten, können mit einer Momentaufnahme der EXPLAIN-Einrichtung erfaßt werden. (In Kapitel 26, Die SQL-EXPLAIN-Einrichtung finden Sie weitere Informationen zu EXPLAIN.)
Der endgültige Plan, der vom DB2-Optimierungsprogramm gewählt wird, kann aus einer Reihe von Schritten bestehen, die eventuell an einer fernen Datenquelle ausgeführt werden. Für die Operationen, die an der jeweiligen Datenquelle ausgeführt werden, erstellt der Schritt der Generierung von fernem SQL eine effiziente SQL-Anweisung, die auf der SQL-Version der Datenquelle beruht.
Dieser Schritt wird nur eingeschoben, wenn Abfragen für zusammengeschlossene Datenbanken ausgeführt werden. Weitere Informationen finden Sie in Generierung von fernem SQL und globale Optimierung.
Im letzten Schritt des SQL-Compilers werden der Zugriffsplan und das Abfragediagrammodell verwendet, um einen ausführbaren Zugriffsplan oder Abschnitt für die Abfrage zu erstellen. Bei dieser Generierung des Codes werden Informationen des Abfragediagrammodells verwendet, um eine Wiederholung der Ausführung von Ausdrücken zu vermeiden, die für eine Abfrage nur einmal berechnet werden müssen. Diese Art der Optimierung ist beispielsweise für Umwandlungen von Codepages und die Verwendung von Host-Variablen möglich.
Informationen über die Zugriffspläne für statisches SQL werden in den Systemkatalogtabellen gespeichert. Wenn das Paket ausgeführt wird, verwendet der Datenbankmanager die in den Systemkatalogtabellen gespeicherten Informationen, um festzulegen, wie auf die Daten zugegriffen werden soll und die Ergebnisse für eine Abfrage zu erstellen sind. Eben diese Informationen werden vom Programm db2expln verwendet. (In Kapitel 26, Die SQL-EXPLAIN-Einrichtung finden Sie weitere Informationen zu EXPLAIN.)
Es ist empfehlenswert, den Befehl RUNSTATS in regelmäßigen Abständen für Tabellen auszuführen, die in Abfragen verwendet werden und für die eine gute Leistung erwünscht ist. Das Optimierungsprogramm ist in diesem Fall besser mit relevanten statistischen Informationen über die Art der Daten ausgerüstet. Wenn der Befehl RUNSTATS nicht ausgeführt wurde (oder das Optimierungsprogramm annimmt, daß RUNSTATS für leere oder fast leere Tabellen ausgeführt wurde), kann das Optimierungsprogramm entweder Standardwerte verwenden oder versuchen, bestimmte Statistikdaten mit Hilfe der Anzahl der Dateiseiten (FPAGES), die zum Speichern der Tabelle auf Platte verwendet werden, abzuleiten.