In diesem Abschnitt werden die zusätzlichen Phasen der Abfrageverarbeitung in einem System zusammengeschlossener Datenbanken beschrieben. Es enthält darüber hinaus Empfehlungen für die Verbesserung der Leistung von Abfragen für zusammengeschlossene Datenbanken. Zu den Hauptthemen gehören:
Die Pushdown-Analyse gibt dem DB2-Optimierungsprogramm darüber Auskunft, ob eine Operation an einer fernen Datenquelle durchgeführt werden kann. Bei dieser Operation kann es sich um eine Funktion, wie zum Beispiel einen relationalen Operator, eine System- oder Benutzerfunktion oder einen SQL-Operator (GROUP BY, ORDER BY usw.) handeln.
Funktionen, die nicht zur Ausführung an die Datenquelle verschoben (Pushdown) werden können, können die Abfrageleistung erheblich beeinträchtigen. Betrachten Sie die Konsequenzen für den Fall, daß ein selektives Vergleichselement lokal anstatt an der Datenquelle ausgewertet werden muß. Dieses Verfahren würde DB2 zwingen, die gesamte Tabelle von der fernen Datenquelle abzurufen und anschließend lokal über das Vergleichselement zu filtern. Wenn die Netzwerkkapazitäten begrenzt sind und die Tabelle groß ist, könnte die Leistung beeinträchtigt werden.
Operatoren, die nicht an die Datenquelle verschoben werden, können die Abfrageleistung ebenfalls erheblich beeinträchtigen. Wenn zum Beispiel ein Operator GROUP BY für ferne Daten lokal ausgeführt wird, muß DB2 auch in diesem Fall die gesamte Tabelle von der fernen Datenquelle abrufen.
Nehmen Sie zum Beispiel an, daß der Kurzname N1 auf die Tabelle EMPLOYEE in einer Datenquelle unter DB2 für OS/390 verweist. Nehmen Sie weiter an, daß die Tabelle 10.000 Zeilen besitzt, wobei eine der Spalten die Familiennamen (Lastname) und eine andere die Gehälter (Salary) enthält. Es sei folgende Anweisung gegeben:
SELECT LASTNAME, COUNT(*) FROM N1 WHERE LASTNAME > 'B' AND SALARY > 50000 GROUP BY LASTNAME;
Für diese Abfrage kommen mehrere Möglichkeiten in Betracht:
Im allgemeinen besteht das Ziel darin, sicherzustellen, daß Funktionen und Operatoren für die Auswertung auf Datenquellen vom Optimierungsprogramm in Betracht gezogen werden können. Zahlreiche Faktoren können die Entscheidung beeinflussen, ob eine Funktion oder ein SQL-Operator an der fernen Datenquelle ausgewertet wird. Die Hauptfaktoren werden in drei Gruppen behandelt: Server-Merkmale, Kurznamenmerkmale und Abfragemerkmale.
In den folgenden Abschnitten werden datenquellenspezifische Faktoren behandelt, die Auswirkung auf die Pushdown-Möglichkeiten haben. Diese Faktoren gibt es im allgemeinen deswegen, weil DB2 die Verwendung einer variantenreichen SQL-Version zur Übergabe von Abfragen ermöglicht. Diese SQL-Version bietet u. U. mehr Funktionalität als die SQL-Version, die von einem Server unterstützt wird, auf den während einer DB2-Abfrage zugegriffen wird. DB2 kann diesen Funktionsmangel auf dem Daten-Server kompensieren, allerdings kann dies dazu führen, daß die Operation in DB2 lokal ausgeführt werden muß.
Jede Datenquelle unterstützt eine Variante der SQL-Version und verschiedene Funktionalitätsebenen. Betrachten Sie zum Beispiel die GROUP BY-Liste. Die meisten Datenquellen unterstützen den Operator GROUP BY. Aber einige haben Einschränkungen hinsichtlich der Anzahl von Elementen in der GROUP BY-Liste oder Einschränkungen hinsichtlich der Zulässigkeit bestimmter Ausdrücke in der GROUP BY-Liste. Wenn es eine Einschränkung an der fernen Datenquelle gibt, muß DB2 die Operation GROUP BY eventuell lokal ausführen.
Jede Datenquelle kann unterschiedliche SQL-Einschränkungen haben. Zum Beispiel fordern einige Datenquellen, daß Parametermarken Werte für ferne SQL-Anweisungen einbinden. Daher müssen die Einschränkungen für Parametermarken überprüft werden, um sicherzustellen, daß jede Datenquelle solche Bindeverfahren unterstützen können. Wenn DB2 keine gute Methode zum Einbinden eines Werts für eine Funktion finden kann, muß diese Funktion lokal ausgewertet werden.
DB2 läßt vielleicht die Verwendung größerer ganzer Zahlen (Integer) als die fernen Datenquellen zu. Allerdings können Werte, die das Maximum überschreiten, nicht in Anweisungen eingebettet werden, die an Datenquellen gesendet werden. Daher muß eine Funktion oder ein Operator, die bzw. der mit einer solchen Konstanten operiert, lokal ausgewertet werden.
In diese Kategorie fallen verschiedene Faktoren. Ein Beispiel ist die Sortierung von NULL-Werten (höchste oder niedrigste Position bzw. abhängig von der angeforderten Reihenfolge). Wenn zum Beispiel der NULL-Wert an der Datenquelle anders sortiert wird als von DB2, können Operationen ORDER BY für einen Ausdruck mit wahlfreier Dateneingabe nicht fern ausgewertet werden.
Die Konfiguration einer zusammengeschlossenen Datenbank zur Verwendung derselben Sortierfolge, die von einer Datenquelle verwendet wird, und das Setzen der Server-Option collating_sequence auf den Wert 'Y' ermöglicht dem Optimierungsprogramm, ein Verschieben (Pushdown) von Vergleichselementen zum Vergleich von Zeichenbereichen an die Datenquelle in Betracht zu ziehen.
Wenn eine Abfrage aus einem Server für zusammengeschlossene Datenbanken eine Sortierung erfordert, ist die Auswahl der Stelle, an der die Sortierung verarbeitet wird, von verschiedenen Faktoren abhängig. Wenn die Sortierfolge der zusammengeschlossenen Datenbank mit der der Datenquelle übereinstimmt, auf der die abgefragten Daten gespeichert sind, kann die Sortierung an der Datenquelle erfolgen. Bei gleichen Sortierfolgen kann das Optimierungsprogramm entscheiden, ob eine lokale Sortierung oder eine Sortierung an der Datenquelle der effizienteste Weg zur Durchführung der Abfrage ist. In ähnlicher Weise kann ein Vergleich von Zeichendaten, wenn die Abfrage einen solchen erforderlich macht, ebenfalls an der Datenquelle durchgeführt werden.
Numerische Vergleiche können im allgemeinen an beiden Stellen stattfinden, selbst wenn die Sortierfolgen unterschiedlich sind. Unerwartete Ergebnisse kommen eventuell dann zustande, wenn die Wertigkeit von Nullzeichen zwischen der zusammengeschlossenen Datenbank und der Datenquelle unterschiedlich ist. Analog gilt auch für Vergleichsanweisungen, daß Vorsicht geboten ist, wenn Anweisungen an eine Datenquelle übergeben werden, an der die Groß- und Kleinschreibung nicht unterschieden wird. Die Wertigkeiten der Zeichen "I" und "i" sind bei einer Datenquelle ohne Unterscheidung der Groß-/Kleinschreibung identisch. DB2 beachtet standardmäßig die Groß-/Kleinschreibung und weist den Zeichen unterschiedliche Wertigkeiten zu.
Wenn die Sortierfolgen der zusammengeschlossenen Datenbank und der Datenquelle voneinander abweichen, ruft DB2 die Daten auf die zusammengeschlossene Datenbank ab, so daß die Sortierung und der Vergleich lokal durchgeführt werden können. Dies geschieht, weil Benutzer die Abfrageergebnisse nach der für den Server der zusammengeschlossenen Datenbank definierten Sortierfolge geordnet erwarten. Durch das lokale Durchführen der Datensortierung, stellt der Server der zusammengeschlossenen Datenbank sicher, daß diese Erwartung erfüllt wird.
Das Abrufen von Daten für lokale Sortierungen und Vergleiche setzt in der Regel den Durchsatz herab. Daher sollte in Erwägung gezogen werden, die zusammengeschlossene Datenbank so zu konfigurieren, daß sie dieselbe Sortierfolge wie die Datenquellen verwendet. So läßt sich der Durchsatz vielleicht erhöhen, weil der Server der zusammengeschlossenen Datenbank die Durchführung von Sortierungen und Vergleichsoperationen an den Datenquellen zulassen kann. Zum Beispiel werden in DB2 UDB für OS/390 Sortierungen, die durch Klauseln ORDER BY definiert werden, mit Hilfe einer Sortierfolge implementiert, die auf einer EBCDIC-Codepage (Extended Binary-Coded Decimal Interchange Code) basiert. Wenn Sie den Server der zusammengeschlossenen Datenbank zum Abrufen von Daten einer Datenquelle unter DB2 für OS/390 verwenden wollen und die Daten mit Hilfe von Klauseln ORDER BY sortiert werden sollen, ist es empfehlenswert, die zusammengeschlossene Datenbank so zu konfigurieren, daß sie eine vordefinierte, auf der EBCDIC-Codepage basierende Sortierfolge verwendet.
Wenn die Sortierfolgen der zusammengeschlossenen Datenbank und der Datenquelle verschieden sind und Sie die Daten nach der Reihenfolge der Sortierfolge der Datenquelle geordnet abrufen müssen, können Sie die Abfrage im Durchgangsmodus übergeben oder die Abfrage in einer Datenquellensicht definieren.
Im Handbuch Systemverwaltung: Konzept finden Sie weitere Informationen zu Sortierfolgen und deren Konfiguration. Tabelle 43 enthält weitere Informationen zur Server-Option collating_sequence.
Verschiedene Server-Optionen können die Pushdown-Möglichkeiten beeinflussen. Prüfen Sie insbesondere Ihre Einstellungen für die Server-Optionen collating_sequence, varchar_no_trailing_blanks und pushdown. Im Abschnitt "Server-Optionen mit Auswirkung auf Abfragen für zusammengeschlossene Datenbanken" finden Sie Informationen zur Einstellung dieser Optionen.
Die Standardzuordnungen von lokalen Datentypen, die von DB2 bereitgestellt werden (Informationen zu Datentyptabellen finden Sie im Handbuch Application Development Guide) sind so ausgelegt, daß ausreichend Pufferspeicher für jeden Datentyp der Datenquelle reserviert wird (um Datenverlust zu vermeiden). Ein Benutzer hat die Möglichkeit, die Typzuordnung für eine bestimmte Datenquelle an die Anforderungen bestimmter Anwendungen anzupassen. Wenn Sie zum Beispiel auf eine Spalte des Datentyps DATE einer Oracle-Datenquelle (die standardmäßig dem DB2-Datentyp TIMESTAMP zugeordnet wird) zugreifen, können Sie den lokalen Datentyp in den DB2-Datentyp DATE ändern.
DB2 kann Funktionen, die von einer Datenquelle nicht unterstützt werden, kompensieren. Diese Funktionskompensation tritt in drei Fällen auf:
In den folgenden Abschnitten werden kurznamenspezifische Faktoren behandelt, die Auswirkung auf die Pushdown-Möglichkeiten haben.
Stellen Sie sicher, daß der lokale Datentyp einer Spalte nicht verhindert, daß ein Vergleichselement an der Datenquelle ausgewertet werden kann. Wie bereits früher erwähnt, stehen die Standarddatentypzuordnungen bereit, um jeden möglichen Überlauf zu vermeiden. Jedoch wird ein verknüpfendes Vergleichselement zwischen zwei Spalten unterschiedlicher Längen eventuell nicht an der Datenquelle ausgewertet, deren Verknüpfungsspalte kürzer ist, je nachdem, wie DB2 die längere Spalte einbindet. Dieser Umstand kann sich auf die Anzahl der Möglichkeiten in einer Verknüpfungssequenz auswirken, die vom DB2-Optimierungsprogramm ausgewertet werden. Zum Beispiel erhalten Spalten einer Oracle-Datenquelle, die mit dem Datentyp INTEGER bzw. INT erstellt wurden, den Typ NUMBER(38). Eine Kurznamenspalte für diesen Oracle-Datentyp erhält den lokalen Datentyp FLOAT, weil die Werte einer ganzen Zahl in DB2 den Bereich von 2**31 bis (-2**31)-1 umfassen, was grob dem Typ NUMBER(9) entspricht. In diesem Fall können Verknüpfungen zwischen einer DB2-Spalte des Typs Integer und einer Oracle-Spalte des Typs Integer nicht an der DB2-Datenquelle stattfinden (kürzere Verknüpfungsspalte). Wenn jedoch der Wertebereich dieser Oracle-Spalte des Typs Integer in dem DB2-Datentyp INTEGER untergebracht werden kann, ändern Sie den lokalen Datentyp der Spalte mit der Anweisung ALTER NICKNAME, so daß die Verknüpfung an der DB2-Datenquelle stattfinden kann.
Die SQL-Anweisung ALTER NICKNAME kann zum Hinzufügen oder Ändern von Spaltenoptionen für Kurznamen verwendet werden.
Eine dieser Optionen ist varchar_no_trailing_blanks. Mit ihrer Hilfe kann eine Spalte angegeben werden, die keine folgenden Leerzeichen enthält. Der Pushdown-Analyseschritt des Compilers berücksichtigt diese Information bei der Prüfung aller Operationen für Spalten, die so markiert sind. Aufgrund dieser Angabe kann DB2 eine andere, aber äquivalente Form eines Vergleichselements generieren, das in einer fernen, an eine Datenquelle gesendete SQL-Anweisung verwendet werden soll. Ein Benutzer bemerkt vielleicht, daß an der Datenquelle ein anderes Vergleichselement ausgewertet wird, das Nettoergebnis sollte jedoch äquivalent sein.
Eine weitere Spaltenoption ist numeric_string. Diese Option dient zur Angabe, ob die Werte in der betreffenden Spalte immer Ziffern ohne folgende Leerzeichen sind.
Tabelle 50 enthält die möglichen Werte und die Standardwerte für
Spaltenoptionen.
Tabelle 50. Spaltenoptionen und zugehörige Einstellungen
Eine Abfrage kann auf einen SQL-Operator verweisen, der Kurznamen aus verschiedenen Datenquellen mit einbezieht. Wenn DB2 die Ergebnisse aus zwei angegebenen Datenquellen mit Hilfe eines Operators, wie zum Beispiel eines Gruppenoperators (z. B. UNION) kombinieren muß, muß die Operation in DB2 stattfinden. Der Operator kann nicht direkt an der fernen Datenquelle ausgewertet werden.
Das Umschreiben von SQL-Anweisungen kann zusätzliche Pushdown-Möglichkeiten für die DB2-Abfrageverarbeitung bereitstellen. Dieser Abschnitt enthält eine Einführung in Programme, mit denen festgestellt werden kann, wo eine Abfrage ausgewertet wird, führt allgemeine Fragen (und zur Untersuchung empfohlene Bereiche) auf, die sich auf die Abfrageanalyse beziehen, und schließt mit einem kurzen Abschnitt zum Thema Erweitern von Datenquellen.
DB2 wird mit zwei Dienstprogrammen geliefert, die zeigen, wo Abfragen ausgewertet werden:
Wenn eine Abfrage vollständig an eine Datenquelle verschoben wird (Pushdown), sollten Sie über einem Operator RQUERY einen Operator RETURN sehen. Der Operator RETURN ist ein Standardoperator von DB2. Der Operator RQUERY ist hingegen für Operationen für zusammengeschlossene Datenbanken spezifisch. RQUERY sendet eine SQL-Anweisung SELECT an eine Datenquelle, um das Abfrageergebnis abzurufen. Die SELECT-Anweisung wird mit Hilfe der von der Datenquelle unterstützten SQL-Version generiert. Sie kann jede für diese Datenquelle gültige Abfrage enthalten.
Dieser Abschnitt führt typische Fragen zur Plananalyse und Untersuchungsbereiche auf, die die Pushdown-Möglichkeiten erhöhen. Zu den wichtigsten Fragen gehören die folgenden:
Diese Frage erhebt sich, wenn ein Vergleichselement sehr selektiv ist und daher zum Filtern von Zeilen herangezogen werden und den Netzwerkverkehr verringern könnte. Die ferne Auswertung von Vergleichselementen wirkt sich auch darauf aus, ob eine Verknüpfung zwischen zwei Tabellen derselben Datenquelle fern ausgewertet werden kann.
Zu untersuchende Bereiche sind:
Es gibt verschiedene Bereiche, die überprüft werden können:
Es gibt verschiedene Bereiche, die überprüft werden können:
Betrachten Sie folgendes:
Obwohl der SQL-Compiler von DB2 über zahlreiche Informationen zur SQL-Unterstützung der Datenquelle verfügt, müssen diese Daten eventuell mit der Zeit angepaßt werden, weil Datenquellen erweitert und/oder angepaßt werden können. In solchen Fällen müssen Erweiterungen DB2 durch Ändern der lokalen Kataloginformationen bekannt gemacht werden. Verwenden Sie DDL-Anweisungen von DB2 (z. B. CREATE FUNCTION MAPPING und ALTER SERVER), um den Katalog zu aktualisieren. Weitere Informationen finden Sie im Handbuch SQL Reference.
Diese Phase hilft bei der Herstellung einer global optimalen Zugriffsstrategie zur Auswertung einer Abfrage. Für eine Abfrage einer zusammengeschlossenen Datenbank kann die Zugriffsstrategie vorsehen, die Originalabfrage in eine Gruppe ferner Abfrageeinheiten zu zerlegen und anschließend die Ergebnisse zu kombinieren.
Das Optimierungsprogramm verwendet die Ausgabe der Pushdown-Analyse als Empfehlung und entscheidet, ob eine Operation lokal in DB2 oder fern an einer Datenquelle ausgewertet wird. Die Entscheidung stützt sich auf die Ausgabe des Aufwandsmodells, das nicht nur den Aufwand für die Auswertung der Operation, sondern auch den Aufwand für die Übertragung der Daten oder Nachrichten zwischen DB2 und den Datenquellen berücksichtigt.
Das Ziel ist die Erstellung einer optimierten Abfrage. Die Ausgabe aus der globalen Optimierung und somit auch die Leistung der Abfrage wird jedoch von zahlreichen Faktoren beeinflußt. Die Schlüsselfaktoren werden im folgenden in zwei Gruppen behandelt: Server-Merkmale und Kurznamenmerkmale.
Zu den Server-Faktoren einer Datenquelle, die sich auf die globale Optimierung auswirken können, gehören folgende:
Geben Sie mit Hilfe der Server-Option cpu_ratio an, um wieviel schneller oder langsamer die CPU-Geschwindigkeit der Datenquelle im Verhältnis zur CPU von DB2 ist. Ein niedriger Wert bedeutet, daß die CPU der Workstation der Datenquelle schneller als die CPU der DB2-Workstation ist. Bei niedrigen Verhältniswerten zieht das DB2-Optimierungsprogramm mit größerer Wahrscheinlichkeit in Betracht, CPU-intensive Operationen an die Datenquelle zu verschieben (Pushdown). Weitere Informationen zu dieser Geschwindigkeitsangabe finden Sie in Server-Optionen mit Auswirkung auf Abfragen für zusammengeschlossene Datenbanken.
Geben Sie mit Hilfe der Server-Option io_ratio an, um wieviel schneller oder langsamer die E/A-Geschwindigkeit des Datenquellensystems im Verhältnis zum DB2-System ist. Ein niedriger Wert bedeutet, daß die E/A-Geschwindigkeit der Workstation der Datenquelle schneller als die E/A-Geschwindigkeit der DB2-Workstation ist. Bei niedrigen Verhältniswerten zieht das DB2-Optimierungsprogramm mit größerer Wahrscheinlichkeit in Betracht, E/A-intensive Operationen an die Datenquelle zu verschieben (Pushdown). Weitere Informationen zu dieser Geschwindigkeitsangabe finden Sie in Server-Optionen mit Auswirkung auf Abfragen für zusammengeschlossene Datenbanken.
Geben Sie mit Hilfe der Server-Option comm_rate die Netzwerkkapazität an. Langsame Geschwindigkeiten (die eine langsame Kommunikation zwischen DB2 und der Datenquelle bedeuten) veranlassen das DB2-Optimierungsprogramm, die Anzahl der Nachrichten zu reduzieren, die zwischen DB2 und dieser Datenquelle gesendet werden. Wenn die Geschwindigkeit auf den Wert 0 gesetzt wird, erstellt das Optimierungsprogramm eine Abfrage mit minimalen Anforderungen an das Netzwerk. Weitere Informationen zu dieser Geschwindigkeitsangabe finden Sie in Server-Optionen mit Auswirkung auf Abfragen für zusammengeschlossene Datenbanken.
Geben Sie mit Hilfe der Server-Option collating_sequence an, ob die Sortierfolge einer Datenquelle mit der lokalen DB2-Sortierfolge übereinstimmt. Wenn die Option nicht auf den Wert 'Y' gesetzt ist, betrachtet das Optimierungsprogramm die von dieser Datenquelle abgerufenen Daten als unsortiert. Im Abschnitt Sortierfolge finden Sie weitere Informationen zur Leistungsrelevanz der Sortierfolge.
Geben Sie mit Hilfe der Server-Option plan_hints an, ob an einer Datenquelle Planhinweise unterstützt werden. Planhinweise sind Anweisungsfragmente, die zusätzliche Informationen für Optimierungsprogramme von Datenquellen bereitstellen. Diese Informationen können bei einigen Abfragearten die Abfrageleistung verbessern. Die Planhinweise können das Optimierungsprogramm der Datenquelle bei der Entscheidung unterstützen, ob ein Index, und wenn ja, welcher, zu verwenden ist oder nach welcher Reihenfolge bei der Verknüpfung von Tabellen vorzugehen ist.
Wenn Planhinweise aktiviert sind, enthält die Abfrage, die an die Datenquelle gesendet wird, zusätzliche Informationen. Zum Beispiel könnte eine Anweisung, die an ein Oracle-Optimierungsprogramm mit Planhinweisen gesendet wird, folgendermaßen aussehen:
SELECT /*+ INDEX (table1, t1index)*/ col1 FROM table1
Der Planhinweis ist hier die Zeichenfolge /*+ INDEX (table1, t1index)*/.
DB2 besitzt eine Wissensbasis für das Optimierungsprogramm, die Daten über spezifische Datenquellen enthält. Das DB2-Optimierungsprogramm generiert keine fernen Zugriffspläne, die nicht von spezifischen Datenbankverwaltungssystemen (DBMSs) generiert werden können. In anderen Worten, DB2 vermeidet die Generierung von Plänen, die von Optimierungsprogrammen an fernen Datenquellen nicht verstanden bzw. akzeptiert werden.
In den folgenden Abschnitten werden kurznamenspezifische Faktoren behandelt, die Auswirkung auf die globale Optimierung haben.
DB2 kann Informationen über Indizes an Datenquellen zur Optimierung von Abfragen heranziehen. Daher ist es wichtig, daß die für DB2 verfügbaren Indexinformationen aktuell sind. Die Indexinformationen für Kurznamen werden zuerst bei der Erstellung des Kurznamens empfangen. Indexinformationen werden für Sichtkurznamen nicht gesammelt.
Es kann eine Indexspezifikation für einen Kurznamen erstellt werden. Indexspezifikationen bilden eine Indexdefinition (keinen tatsächlichen Index) im Katalog, die vom DB2-Optimierungsprogramm verwendet werden kann. Indexspezifikationen werden mit der Anweisung CREATE INDEX SPECIFICATION ONLY erstellt. Die Syntax für die Erstellung einer Indexspezifikation für einen Kurznamen ist der Syntax zur Erstellung eines Index für eine lokale Tabelle ähnlich. Weitere Informationen finden Sie im Handbuch Systemverwaltung: Konzept.
Die Erstellung von Indexspezifikationen kommt unter folgenden Bedingungen in Betracht:
Kalkulieren Sie Ihre Anforderungen, bevor Sie Anweisungen CREATE INDEX für einen Kurznamen einer Sicht ausführen. In einem Fall, wenn die Sicht eine einfache SELECT-Abfrage auf eine Tabelle mit einem Index ist, kann die Erstellung von Indizes für den Kurznamen (lokal), die mit den Indizes für die Tabelle an der Datenquelle übereinstimmen, die Abfrageleistung erheblich erhöhen. Wenn aber Indizes lokal über Sichten erstellt werden, die keine einfachen SELECT-Anweisungen sind (z. B. eine Sicht, die durch Verknüpfen zweier Tabellen erstellt wird), kann die Abfrageleistung sinken. Wenn zum Beispiel ein Index über eine Sicht erstellt wird, die auf der Verknüpfung zweier Tabellen basiert, kann das Optimierungsprogramm diese Sicht möglicherweise als inneres Element in einer Verknüpfung über Verschachtelungsschleife (Nested Loop Join) festlegen. Die Abfrage wird eine geringe Leistung erzielen, weil in diesem Fall die Verknüpfung mehrere Male ausgewertet wird. Eine Alternative wäre, Kurznamen für jede der Tabellen, auf die in der Sicht der Datenquelle verwiesen wird, zu erstellen und eine lokale Sicht unter DB2 zu definieren, die auf beide Kurznamen verweist.
Katalogstatistiken beschreiben die allgemeine Größe von Kurznamen und den Wertebereich in den zugehörigen Spalten. Sie werden vom Optimierungsprogramm bei der Berechnung des Pfads mit dem günstigsten Aufwand zur Verarbeitung von Abfragen verwendet, die Kurznamen enthalten. Die statistischen Daten über Kurznamen werden in den gleichen Katalogsichten wie Tabellenstatistiken gespeichert. In Kapitel 24, Systemkatalogstatistiken, und im Abschnitt Regeln zur Aktualisierung von Kurznamenstatistiken finden Sie weitere Informationen zu Statistikarten und dazu, wie sie lokal aktualisiert werden.
Obwohl DB2 die an einer Datenquelle befindlichen statistischen Daten abrufen kann, kann DB2 Aktualisierungen an vorhandenen Statistikdaten an Datenquellen nicht automatisch erkennen. Zudem verfügt DB2 über keine Methode zur Behandlung von Definitions- oder Strukturänderungen (z. B. Hinzufügen einer Spalte) an Objekten der Datenquelle. Wenn die Statistik- bzw. Strukturdaten für ein Objekt geändert wurden, haben Sie zwei Möglichkeiten:
Dieser Abschnitt enthält eine Einführung in Programme zur Analyse der Abfrageoptimierung und stellt allgemeine Fragen (und zur Untersuchung empfohlene Bereiche) im Zusammenhang mit der Abfrageoptimierung vor.
DB2 stellt zwei Dienstprogramme zur Verfügung, die globale Zugriffspläne zeigen:
Dieser Abschnitt enthält eine Liste von Fragen zur Optimierung und Schlüsselbereiche, die zur Verbesserung der Leistung untersucht werden können. Zu den wichtigsten Fragen gehören die folgenden:
Zu untersuchende Bereiche sind:
Zu untersuchende Bereiche sind:
Das DB2-Optimierungsprogramm führt eine aufwandsorientierte Optimierung durch. Auch wenn die Pushdown-Analyse ergibt, daß jeder Operator an der fernen Datenquelle ausgewertet werden kann, stützt sich das Optimierungsprogramm bei der Generierung eines global optimalen Plans auf die Aufwandsschätzung. Es gibt eine Vielzahl von Faktoren, die in diesen Plan einfließen können. Es ist beispielsweise möglich, daß eine ferne Datenquelle zwar jede einzelne Operation in der ursprünglichen Abfrage ausführen kann, aber die CPU-Geschwindigkeit der Datenquelle wesentlich langsamer ist als die des DB2-Systems, so daß es vorteilhafter ist, die Operationen in DB2 lokal auszuführen. Wenn die Ergebnisse nicht zufriedenstellend sind, überprüfen Sie die Server-Statistikdaten in SYSCAT.SERVEROPTIONS.
Zu untersuchende Bereiche sind:
Prüfen Sie darüber hinaus auf Ersetzungen von Vergleichselementen. Ein gutes Abfrageoptimierungsprogramm sollte nicht von der Ersetzung äquivalenter Vergleichselemente abhängig sein. Leider sind nicht alle DBMS-Optimierungsprogramme identisch, so daß das Optimierungsprogramm der fernen Datenquelle vielleicht aufgrund des Vergleichselements in der Eingabe einen anderen Plan generiert. Zum Beispiel können einige Optimierungsprogramme keine Anweisungen für Vergleichselemente unter Verwendung der Transitivität generieren.