Abfrageleistung für allgemeine SQL-Anweisungen

Die Verarbeitungsgeschwindigkeit bei vielen Abfragen wurde durch verschiedene Leistungsverbesserungen erhöht. Diese Verbesserungen werden automatisch genutzt. Es sind keine speziellen Konfigurationseinstellungen oder Änderungen an den SQL-Anweisungen dafür erforderlich.

Partial early distinct (PED)

Zum partiellen Entfernen von Duplikaten wird jetzt eine effiziente Hashfunktion in einer frühen Verarbeitungsphase der Abfrage verwendet. Dadurch werden möglicherweise nicht alle Duplikate entfernt, es wird jedoch das Volumen der Daten verringert, die später bei der Abfrageauswertung verarbeitet werden müssen. Das Entfernen der anfänglich vorhandenen doppelten Zeilen beschleunigt die Abfrage und verringert die Wahrscheinlichkeit, dass der Sortierspeicher knapp wird. Dadurch wird die Verwendung von relativ langsamem Plattenspeicher für eine temporäre Speicherung in diesen Fällen vermieden. Diese Verbesserung wird im Englischen als "Partial Early Distinct" (PED) bezeichnet.

Sie können feststellen, ob diese Verbesserung für eine bestimmte Abfrage verwendet wird, indem Sie die EXPLAIN-Funktion aktivieren und die Abfrage ausführen. Ein neuer Wert in der Tabelle EXPLAIN_ARGUMENT zeigt an, dass diese neue Funktionalität auf eine Abfrage angewendet wurde:
  • ARGUMENT_TYPE column = UNIQUE
  • Die Spalte ARGUMENT_VALUE kann jetzt auch den folgenden Wert haben: HASHED PARTIAL. Dieser Wert gibt an, dass die neue Funktion verwendet wurde.
Auch das Tool db2exfmt zeigt den Wert HASHED PARTIAL in der zugehörigen Ausgabe an, wie im folgenden Beispiel ersichtlich:
6) UNIQUE: (Unique)
      Cumulative Total Cost: 		132.519
      Cumulative CPU Cost: 		1.98997e+06
      ...
      ...
      Arguments:
      ---------
      JN INPUT: (Join input leg)
            INNER
      UNIQKEY : (Unique Key columns)
            1: Q1.C22
      UNIQKEY : (Unique Key columns)
            2: Q1.C21
      pUNIQUE  : (Uniqueness required flag)
            HASHED PARTIAL

Partial early aggregation (PEA)

Ähnlich wie Partial Early Distinct (PED) ist auch Partial Early Aggregation (PEA) ein Versuch, eine partielle Spaltenberechnung (Aggregation) von Daten in einem frühen Stadium der Abfrageverarbeitung durchzuführen. Obwohl es unwahrscheinlich ist, dass die gesamte Spaltenberechnung an diesem Punkt erfolgen kann, kann dieses Verfahren jedoch zumindest das Volumen der Daten verringern, die später bei der Abfrageauswertung verarbeitet werden müssen.

Stellen Sie fest, ob Partial Early Aggregation für eine bestimmte Abfrage verwendet wird, indem Sie die EXPLAIN-Funktion aktivieren und die Abfrage ausführen. Ein neuer Wert in der Tabelle EXPLAIN_ARGUMENT zeigt an, dass diese neue Funktionalität auf eine Abfrage angewendet wurde:
  • Spalte ARGUMENT_TYPE = AGGMODE
  • Die Spalte ARGUMENT_VALUE kann jetzt auch den folgenden Wert haben: HASHED PARTIAL. Dieser Wert gibt an, dass die neue Funktion verwendet wurde.
Auch das Tool db2exfmt zeigt den Wert HASHED PARTIAL in der Ausgabe für GRPBY-Abschnitte zusammen mit einem pGRPBY in der Baumstruktursicht an, wenn diese neue Funktionalität in diesem Teil der Abfrage angewendet wurde.

Hash-Join wird jetzt vom Abfrageoptimierungsprogramm für eine größere Auswahl an SQL-Abfragen ausgewählt.

Das Abfrageoptimierungsprogramm wählt unter drei grundlegenden Joinstrategien aus, wenn es ermittelt, wie eine SQL-Abfrage auszuführen ist, die einen Join enthält. In vielen Fällen ist ein Hash-Join die effizienteste Methode. In diesem Release kann diese Methode in einer größeren Anzahl von Situationen verwendet werden.
Nicht übereinstimmende Datentypen
Ein Hash-Join wird jetzt in Betracht gezogen, selbst wenn die beiden Spalten im Join nicht denselben Datentyp haben. Dies ist bis auf wenige Ausnahmen der Fall.
Im Joinvergleichselement verwendete Ausdrücke
Joinvergleichselemente, die einen Ausdruck enthalten, schränken die Joinmethode nicht mehr auf einen Join mit Verschachtelungsschleife (Nested Loop Join) ein. In diesem Release wird ein Hash-Join in solchen Fällen in Betracht gezogen, in denen die WHERE-Klausel einen Ausdruck wie den folgenden enthält: WHERE T1.C1 = UPPER(T1.C3)
In diesen Fällen wird der Hash-Join automatisch in Betracht gezogen. Es besteht keine Notwendigkeit, vorhandene SQL-Abfragen zu ändern, um diese verbesserte Funktionalität zu nutzen. Beachten Sie, dass Hash-Joins den Sortierspeicher verwenden.

Verbesserte Aufwandsschätzungen für den durch eine Abfrage generierten Netzkommunikationsdatenverkehr

Das Abfrageoptimierungsprogramm ist bei der Auswahl eines möglichst effizienten Zugriffsplans von einer Reihe von Informationen abhängig. Die Schätzung des Kommunikationsaufwands von Abfragen wurde jetzt verbessert, sodass das Optimierungsprogramm alle CPU-, E/A- und Kommunikationsaufwände genauer prüfen und vergleichen kann. In vielen Fällen führt dies zu einer schnelleren Abfrageleistung.

Die geschätzten, auf die Knotenbasis bezogenen Kommunikationsaufwände einer Abfrage, wie sie von den EXPLAIN-Membern COMM_COST und FIRST_COMM_COST zurückgegeben werden, wurden verbessert. Sie sind jetzt konsistenter mit den vorhandenen CPU- und E/A-Aufwandsberechnungen für jeden Knoten. Dadurch kann das Abfrageoptimierungsprogramm diese drei Aufwandsschätzungen bei der Bewertung verschiedener Zugriffspläne effektiv gegeneinander abwägen. Dies unterstützt auch eine Erhöhung der Parallelität, sofern möglich, indem die Netzübertragungen gleichmäßiger auf mehrere Netzadapter verteilt werden können. Im Einzelnen gilt:
  • Wenn mehrere Netzadapter beteiligt sind, wird der kumulative Kommunikationsaufwand für den Adapter mit dem höchsten Wert zurückgegeben. In früheren Releases wurde die Gesamtzahl der im gesamten Netz übertragenen Rahmen (Frames) zurückgegeben.
  • Die Werte enthalten nur den Aufwand für Netzübertragungen zwischen physischen Maschinen. Sie enthalten keine virtuellen Kommunikationsaufwände zwischen Knotenpartitionen auf derselben physischen Maschine in einer Umgebung mit partitionierten Datenbanken.