Verschiedene Konfigurationsparameter wirken sich auf die Auswahl des Zugriffsplans durch den SQL-Compiler aus. Viele von ihnen gelten für eine Datenbank mit Einzelpartition, während einige nur für eine partitionierte Datenbank gelten. Wenn Sie Konfigurationsparameter in einer partitionierten Datenbank ändern, empfiehlt es sich, in allen Partitionen gleiche Werte für die jeweiligen Parameter zu verwenden.
Wenn bei der Arbeit in einem System zusammengeschlossener Datenbanken die Mehrzahl der Abfragen auf Kurznamen zugreift, sollten Sie die Art der Abfrage, die Sie senden, berücksichtigen, bevor Sie Ihre Umgebung ändern. Zum Beispiel speichert der Pufferpool keine Seiten aus Datenquellen im Cache. Durch die Erhöhung des Werts für den Parameter buffpage allein wird also nicht sichergestellt, daß das Optimierungsprogramm weitere Alternativen bei der Erstellung eines Zugriffsplans für Abfragen, die Kurznamen enthalten, in Betracht zieht. (Als Datenquellen werden Datenbankverwaltungssysteme (DBMSs) und Daten innerhalb eines Systems zusammengeschlossener Datenbanken bezeichnet.) Zudem kann das Optimierungsprogramm feststellen, daß die lokale Anlage von Datenquellentabellen der Weg mit dem geringsten Aufwand oder ein erforderlicher Schritt für eine Sortieroperation ist. In diesem Fall kann die Vergrößerung der für DB2 Universal Database verfügbaren Ressourcen die Geschwindigkeit erhöhen. Weitere Informationen finden Sie in den Abschnitten Server-Optionen mit Auswirkung auf Abfragen für zusammengeschlossene Datenbanken und Gemeinsam benutzter Speicher der Datenbank.
Es folgt eine Liste von Konfigurationsparametern, die Einfluß auf die Auswahl des Zugriffsplan durch den SQL-Compiler haben:
Bei der Auswahl des Zugriffsplans bezieht das Optimierungsprogramm den Ein-/Ausgabeaufwand für das Laden von Seiten von der Platte in den Pufferpool in die Kalkulation mit ein. In den Berechnungen schätzt das Optimierungsprogramm die Anzahl der E/A-Operationen ab, die zur Erfüllung einer Abfrage erforderlich sind. Diese Schätzung schließt eine Voraussage über den Bedarf an Pufferpool mit ein, da zum Lesen von Zeilen einer Seite, die sich bereits im Pufferpool befindet, keine weiteren physischen E/A-Operationen anfallen. Das Optimierungsprogramm berücksichtigt den Wert der Spalte npages in den Systemkatalogtabellen BUFFERPOOLS bei der Abschätzung, ob eine Seite im Pufferpool gefunden wird.
Der Ein-/Ausgabeaufwand für das Lesen der Tabellen kann sich auf folgende Bereiche auswirken:
Sie können über mehr als einen Pufferpool in einer Datenbank verfügen. Ebenso können Sie mehr als einen Pufferpool in einer partitionierten Datenbank haben. Ein neuer Pufferpool kann selektiv jeder der Partitionen in der Datenbank oder allen Partitionen hinzugefügt werden. Die Spalten npages in den Systemkatalogtabellen BUFFERPOOLS und BUFFERPOOLSNODE werden zur Abschätzung in einer partitionierten Datenbank verwendet.
Der Konfigurationsparameter dft_degree gibt den Standardwert für das Sonderregister CURRENT DEGREE und Bindeoption DEGREE an. Ein Wert von eins (1) bedeutet keine partitionsinterne Parallelität. Ein Wert von minus eins (-1) bedeutet, daß das Optimierungsprogramm den Grad der partitionsinternen Parallelität anhand der Anzahl von Prozessoren und der Art der Abfrage bestimmt.
Beim Kompilieren von SQL-Abfragen können Sie die Abfrageoptimierungsklasse definieren, um das Optimierungsprogramm anzuweisen, verschiedene Grade der Optimierung zu verwenden. Weitere Informationen zur Auswahl einer geeigneten Abfrageoptimierungsklasse finden Sie in Anpassen der Optimierungsklasse.
Mit Hilfe des Parameters avg_appls versucht das SQL-Optimierungsprogramm zu ermitteln, wieviel vom Pufferpool zur Laufzeit für den ausgewählten Zugriffsplan verfügbar ist. Höhere Werte für diesen Parameter können sich so auswirken, daß das Optimierungsprogramm einen Zugriffsplan für Abfragen auswählt, der mit dem Pufferpool etwas sparsamer umgeht. Ist der Wert für diesen Parameter 1, behandelt das Optimierungsprogramm den gesamten Pufferpool als für die Anwendung verfügbar.
Eine Sortierung wird als "über eine Pipe geleitet (piped)" betrachtet, wenn sie keine temporäre Tabelle zur Speicherung der endgültigen, sortierten Liste von Daten erforderlich macht. Das heißt, daß die Ergebnisse der Sortierung in einem einzigen sequentiellen Zugriff gelesen werden können. Über eine Pipe geleitete Sortierungen führen zu einer besseren Leistung als nicht über eine Pipe geleitete und werden daher, wenn möglich, verwendet. (Eine Definition von Sortierungen ohne Pipe im Vergleich zu Sortierungen mit Pipe finden Sie in Einfluß des Sortierens auf das Optimierungsprogramm.)
Bei der Auswahl eines Zugriffsplans schätzt das Optimierungsprogramm den Aufwand der Sortieroperationen, einschließlich der Möglichkeiten, eine Sortierung über eine Pipe zu leiten, folgendermaßen ab:
Wenn die Isolationsstufe (siehe Gemeinsamer Zugriff) RR (Wiederholtes Lesen) verwendet wird, berücksichtigt das Optimierungsprogramm die Werte der Parameter locklist und maxlocks, um zu bestimmen, ob es wahrscheinlich ist, daß Sperren auf Zeilenebene durch Sperreneskalation in eine Sperre auf Tabellenebene umgewandelt werden. Wenn das Optimierungsprogramm eine Sperreneskalation für einen Tabellenzugriff voraussagt, wählt es für den Zugriffsplan eine Sperre auf Tabellenebene und vermeidet den Systemaufwand, der mit einer Sperreneskalation während der Ausführung der Abfrage verbunden wäre.
Der Parameter für die CPU-Geschwindigkeit wird vom SQL-Optimierungsprogramm zur Abschätzung des Aufwands für bestimmte Operationen verwendet. Das Optimierungsprogramm verwendet diese Schätzungen zum CPU-Aufwand in Verbindung mit verschiedenen Schätzungen zum Ein-/Ausgabeaufwand, um den besten Zugriffsplan für eine Abfrage auszuwählen.
Die CPU-Geschwindigkeit eines Systems kann die Auswahl des Zugriffsplans wesentlich beeinflussen. Dieser Konfigurationsparameter wird bei der Installation oder Migration der Datenbank automatisch auf einen geeigneten Wert gesetzt. Sie sollten diesen Parameter nur anpassen, wenn Sie eine Produktionsumgebung auf einem Testsystem modellieren oder die Auswirkungen einer Änderung der Hardware testen möchten. Wenn dieser Parameter zur Modellierung einer anderen Hardwareumgebung verwendet wird, können Sie beobachten, welcher Zugriffsplan für diese andere Umgebung ausgewählt würde.
Die Größe des Anweisungszwischenspeichers hat keinen Einfluß darauf, welchen Zugriffspfad das Optimierungsprogramm auswählt. Sie kann sich jedoch auf den Grad der Optimierung, der für komplexe SQL-Anweisungen ausgeführt wird, auswirken.
Wenn der Wert für den Parameter stmtheap nicht groß genug ist, empfangen Sie eventuell eine SQL-Warnung, die angibt, daß nicht genügend Speicher zur Verarbeitung der Anweisung zur Verfügung steht. Zum Beispiel kann der SQLCODE +437 (SQLSTATE 01602) angeben, daß der Optimierungsgrad, der zur Kompilierung einer Anweisung verwendet wurde, geringer war als der Grad, den Sie durch die Angabe der Optimierungsklasse angefordert haben. (Der Abschnitt Anpassen der Optimierungsklasse enthält weitere Informationen.)
Wenn dieser Parameter den Wert "ANY" hat, wählt das Optimierungsprogramm den Grad der Parallelität für die Anwendung aus. Ist ein anderer Wert als "ANY" definiert, wird der vom Benutzer angegebene Wert verwendet, um den Grad der Parallelität für die Anwendung festzulegen.
Die Übertragungsbandbreite wird vom Optimierungsprogramm verwendet, um den Zugriffsplan zu bestimmen. Das Optimierungsprogramm verwendet den Wert dieses Parameters, um den Aufwand für bestimmte Operationen zwischen den Datenbankpartitions-Servern einer partitionierten Datenbank abzuschätzen.
Weitere Informationen enthält der Abschnitt Optimieren der Konfigurationsparameter.