DB2 Universal Database - Systemverwaltung


Abfragecompilerphasen für zusammengeschlossene Datenbanken

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:

Pushdown-Analyse

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.

Server-Merkmale mit Auswirkung auf die Pushdown-Möglichkeiten

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ß.

SQL-Leistungsspektrum

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.

SQL-Einschränkungen

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.

SQL-Grenzwerte

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.

Server-spezifische Faktoren

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.

Sortierfolge

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.

Server-Optionen

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.

Faktoren der DB2-Typzuordnung und DB2-Funktionszuordnung

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:

Kurznamenmerkmale mit Auswirkung auf die Pushdown-Möglichkeiten

In den folgenden Abschnitten werden kurznamenspezifische Faktoren behandelt, die Auswirkung auf die Pushdown-Möglichkeiten haben.

Lokaler Datentyp einer Kurznamenspalte

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.

Spaltenoptionen

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
Option Gültige Einstellungen Standardeinstellung
numeric_string

'Y'
Der Wert 'Y' (Yes) gibt an, daß diese Spalte nur Zeichenfolgen mit numerischen Daten enthält. WICHTIG: Wenn diese Spalte nur numerische Zeichenfolgen mit folgenden Leerzeichen enthält, ist die Angabe von 'Y' nicht zu empfehlen.

'N'
Der Wert 'N' (No) gibt an, daß diese Spalte nicht auf Zeichenfolgen mit numerischen Daten beschränkt ist.

Durch Einstellen der Spaltenoption numeric_string auf den Wert 'Y' teilen Sie dem Optimierungsprogramm mit, daß diese Spalte keine Leerzeichen enthält, die einen störenden Einfluß auf das Sortieren der Daten dieser Spalte haben könnten. Diese Option ist in solchen Fällen nützlich, in denen die Sortierfolge einer Datenquelle von der Sortierfolge in DB2 abweicht. Mit dieser Option markierte Spalten werden nicht von der lokalen Bewertung (an der Datenquelle) aufgrund unterschiedlicher Sortierfolgen ausgeschlossen.

'N'
varchar_no_trailing_blanks Gibt an, ob folgende Leerzeichen in einer bestimmten Spalte des Typs VARCHAR nicht vorkommen:

'Y'
Der Wert 'Y' gibt an, daß folgende Leerzeichen in dieser VARCHAR-Spalte nicht vorkommen.

'N'
Der Wert 'N' gibt an, daß folgende Leerzeichen in dieser VARCHAR-Spalte vorkommen.

Wenn VARCHAR-Spalten einer Datenquellen keine aufgefüllten Leerzeichen enthalten, ist die Strategie des Optimierungsprogramms für den Zugriff auf sie teilweise davon abhängig, ob die Spalten folgende Leerzeichen enthalten. Standardmäßig nimmt das Optimierungsprogramm an, daß sie tatsächlich folgende Leerzeichen enthalten. Von dieser Annahme ausgehend entwickelt es eine Zugriffsstrategie, die das Ändern von Abfragen vorsieht, so daß die aus diesen Spalten zurückgegebenen Werte auch den Erwartungen des Benutzers entsprechen. Falls eine VARCHAR-Spalte jedoch keine folgenden Leerzeichen besitzt und Sie dies dem Optimierungsprogramm mitteilen, kann das Optimierungsprogramm eine effizientere Zugriffsstrategie entwickeln. Geben Sie eine bestimmte Spalte in der Anweisung ALTER NICKNAME (zur Syntax siehe SQL Reference) an, um dem Optimierungsprogramm mitzuteilen, daß diese Spalte keine folgenden Leerzeichen besitzt.

'N'

Abfragemerkmale mit Auswirkung auf Pushdown-Möglichkeiten

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.

Analysieren und Verstehen der Pushdown-Analyseergebnisse

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.

Analysieren, wo eine Abfrage ausgewertet wird

DB2 wird mit zwei Dienstprogrammen geliefert, die zeigen, wo Abfragen ausgewertet werden:

Verstehen, warum eine Abfrage an einer Datenquelle oder in DB2 ausgewertet wird

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:

Erweitern und Anpassen von Datenquellen

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.

Generierung von fernem SQL und globale Optimierung

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.

Server-Merkmale/-Optionen mit Auswirkung auf die globale Optimierung

Zu den Server-Faktoren einer Datenquelle, die sich auf die globale Optimierung auswirken können, gehören folgende:

Kurznamenmerkmale mit Auswirkung auf die globale Optimierung

In den folgenden Abschnitten werden kurznamenspezifische Faktoren behandelt, die Auswirkung auf die globale Optimierung haben.

Überlegungen zu Indizes

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.

Erstellen von Indexspezifikationen für Kurznamen

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.

Überlegungen zu Systemkatalogstatistiken

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:

Analysieren und Verstehen der Entscheidungen der globalen Optimierung

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.

Analysieren der Abfrageoptimierung

DB2 stellt zwei Dienstprogramme zur Verfügung, die globale Zugriffspläne zeigen:

Verstehen der Entscheidungen der DB2-Optimierung

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:


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]