Zugriffe auf DB2-Datenbanken

Transkript

1 Zugriffe auf DB2-Datenbanken S.K. Consulting GmbH, München DB2_SQL_PERF - 1 -

2 Inhaltsverzeichnis I. Der Zugriffspfad bei DB2 1.1 Query Typen 1.2 Ermittlung des Zugriffspfads Faktoren der Entscheidung für den Optimizer Die Optimierung Prädikate und Prädikatkategorien Filter und Filterfaktoren(FF) S.K. Consulting GmbH, München DB2_SQL_PERF - 2 -

3 1.1 Query Typen Die Query-Verarbeitung erfordert CPU-Zeit und Datenzugriffszeit(I/O s). Entsprechend kann man Queries typisieren in: - CPU-Bound Queries = CPU-intensive Queries Die Queries verbrauchen den überwiegenden Teil ihrer Laufzeit mit dem Filtern der Daten, mit komplexen Funktionsbearbeitungen bzw. mit Darstellungsoptionen z.b. durch GROUP BY, ORDER BY, DISTINCT... - I/O-Bound Queries = I/O-intensive Queries Die Queries verbrauchen den überwiegenden Teil ihrer Laufzeit mit dem Ein- und Auslagern von Pages. Diese Queries verfügen über wenige aufwendige Funktionen und Selektionsanforderungen. S.K. Consulting GmbH, München DB2_SQL_PERF - 3 -

4 1.2 Ermittlung des Zugriffspfads Faktoren der Entscheidung für den Optimizer Der DB2 Optimierer hat zur Aufgabe, den optimalen Zugriffsweg zu den gewünschten Daten auf der Datenbank zu bestimmen. Dazu analysiert er die SQL-Statements, verwendet Statistik-Informationen aus dem Katalog und ermittelt die I/O-Zugriffstypen zu den Daten für das spezielle SQL-Statement. Der Optimizer wickelt seine Aufgabe in vier Schritten ab: - Parsing syntaktische und semantische Prüfung, Analyse und Gliederung des SQL-Statements - Optimization Identifizieren der Zugriffspfadmöglichkeiten, Kostenermittlung pro Zugriffspfad und Auswahl des kostengünstigsten Pfades - Code Generierung Erzeugen des ausführbaren Maschinencodes zum Ablauf im Zugriffsplan - Ausführung Aufbau der Package bzw. des Plans und - Ausführung (bei Dynamic BIND) - Speicherung im Katalog und im Directory (bei Static BIND) S.K. Consulting GmbH, München DB2_SQL_PERF - 4 -

5 1.2.2 Die Optimierung Der DB2 Optimierer verfeinert und ergänzt den im Parsing erstellten parsetree. Es werden Views durch Tabellen ersetzt, Subquery-Anforderungen weiter aufgelöst, ja sogar Modifikationen vorgenommen, z.b. Subqueries durch Joins ersetzt oder andere Prädikate optimiert: Beispiel: WHERE anzahl = 1 OR anzahl = 6 OR anzahl = 10 wird ge ndert in: WHERE anzahl IN (1, 6, 10) S.K. Consulting GmbH, München DB2_SQL_PERF - 5 -

6 1.2.3 Prädikate und Prädikatkategorien Gemeinhin werden die Suchbedingungen von Queries als Prädikat(e) bezeichnet. Sie stehen in der WHERE-Klausel eines SQL-Statements: SELECT * FROM TAB WHERE C1 = 5 AND C4 > 100 AND C2 BETWEEN 01 AND 11 Dafür existieren folgende Prädikatskatekorien: - Simple oder Compound ein mit AND bzw. OR verknüpftes Prädikat ist compound ansonsten ist es simple - Operationstypen ein simple Prädikat definiert sich durch seinen Operationstyp: - Subquery: anzahl IN (SELECT zahl FROM...) - Equal: anzahl = 5; abt_nr IS NULL; - IN-Liste: anzahl IN (1, 5, 10, 13) - Range: anzahl > 3; anzahl BETWEEN 1 AND 15; name LIKE D% - NOT: anzahl <> 0; anzahl NOT BETWEEN 3 AND 6 - ON: ON ma.abt_nr = abt.abt.nr S.K. Consulting GmbH, München DB2_SQL_PERF - 6 -

7 1.2.3 Prädikate und Prädikatkategorien(Forts.) 3. Local oder Join ein Prädikat, das mehr als eine Tabelle referenziert, oder eine Korrelation beinhaltet ist als JOIN-Prädikat definiert. Alles andere sind LOKALE Prädikate 4. Indexable oder Non-Indexable ein Prädikat, das direkt beim Einlesen der Daten geprüft werden kann ist STAGE1, ansonsten STAGE2 5. Boolean Term(BT) ein BT ist ein simple oder compound Prädikat. Wenn ein BT für eine bestimmte Zeile als unwahr oder falsch erkannt wird, sind alle diese Zeile betreffenden Bedingungen als falsch zu qualifizieren:...where C1 = 3 AND ( C4 > 5 OR C2 = 7) In One-IX-Search-Prozessen werden nur BT-Pr dikate f r Matching Scans verwendet. Der Optimizer versucht ggf. eine IX -N utz ung ber einen Multi-IX Access S.K. Consulting GmbH, München DB2_SQL_PERF - 7 -

8 1.2.4 Filter und Filterfaktoren(FF) Die Sicht auf Daten kann sich auf alle oder eine definierte Untermenge von Daten beziehen. Soll eine Datenauswahl erfolgen, so muss aus der Gesamtmenge diese Teilmenge herausgefiltert werden. Eine Filterung unterstützt DB2 über: - Direktzugriff über eine ROWID auf eine Zeile = Zugriff auf eine physische Satzadresse - Indexnutzung aufgrund der vorgegebenen WHERE-Klausel werden Index-Einträge untersucht und dann bei Bedarf ein datenzugriff durchgeführt - Filterung auf Datenebene aufgrund der vorgegebenen WHERE-Klausel werden Dateninhalte untersucht Bei Einsatz eines IX spielt die Datenmenge ebenso eine Rolle, wie die inhaltliche Unterschiedlichkeit der Datenwerte, z. B. in FIRSTKEYCARDF im DB2-Katalog. Aus ihr resultiert die Verteilung der Datenwerte. - gleichmässige Verteilung ( uniform distribution ) die Datenwerte sind gleichmässig über den gesamten Datenbestand verteilt - ungleichmässige Verteilung ( NON-uniform distribution ) die Datenwerte sind nicht gleichmässig über den gesamten Datenbestand verteilt: - Daten innerhalb eines PTS werden aufgrund des partitioned IX verteilt - Datenkonstellationen mit unterschiedlicher Häufigkeit(Kunden mit häufigen und seltenen Wünschen, unterschiedlich grosse Filialen... ) S.K. Consulting GmbH, München DB2_SQL_PERF - 8 -

9 1.2.4 Filter und Filterfaktoren(FF) Filterfaktoren(FF) kalkulieren die Anzahl Zeilen, die in die Ergebnisbearbeitung einbezogen werden. Der Filterfaktor eines Prädikats wird dargestellt als eine Zahl zwischen 0 und 1 (keine Wahrscheinlichkeits-zahl ). Je kleiner der FF ist, umso weniger Zeilen werden als Ergebnis erwartet. FF haben eine sehr hohe Performance-Auswirkung, da sie statistisch die Anzahl der zu verarbeitenden Zeilen bewerten. Sie werden bei I/O-Kostenund bei der Prozess-Kostenermittlung herangezogen. Dazu benötigt der Optimizer statistische Informationen über die relevanten Daten vor allem übere die inhaltliche Vorkommenhäufigkeit (Cardinality) Tabellen Spalten Default-Wert Beschreibung Name Name SYSTABLES CARDF Gesamtzahl Zeilen pro Tabelle NPAGES CEILING(1+CARDF/20) Anzahl pages im TS, die Zeilen der Tabelle enthalten Default f r einen segmented TS SYSTABLESPACE NACTIVE CEILING(1+CARDF/20) Anzahl Pages bis zur h chsten formatierten Page Default f r einen non-segmented TS SYSCOLUMNS COLCARDF 25 Anzahl unterschiedlicher werte in dieser Spalte HIGH2KEY Zweith chster Wert in dieser Spalte LOW2KEY Zweitniedrigster Wert in dieser Spalte SYSINDEXES FULLKEYCARDF 25 Anzahl unterschiedlicher Werte aller Key-Spalten des IX FIRSTKEYCARDF 25 Anzahl unterschiedlicher Werte der ersten Key-Spalte des IX NLEAF CARDF/20 Anzahl Leaf-Pages im Index(=COLCARDF f. IX-Spalte) NLEVELS 2 Anzahl IX-Level CLUSTERRATIO 0 %-Satz der Tabellenzeilen, die in IX-Folge gespeichert sind S.K. Consulting GmbH, München DB2_SQL_PERF - 9 -

10 1.2.4 Filter und Filterfaktoren(FF) Sind keine Statistiken existent, werden Default Werte genutzt (COLCARDF = -1) Bei einer Uniform Distribution werden Standardwerte eingesetzt (COLCARDF ungleich 1 und keine zusätzlichen Statistiken in SYSCOLDIST) und Interpolationsformeln verwendet. Werden Hostvariable verwendet, sind Default-FF definiert. Zusätzliche Verteilungs-FF können in der Tabelle SYSCOLDIST hinterlegt werden, z.b.: Arbeitsort: München Häufigkeit: 445 FF: 4,45% oder 0,0445 Bei Index-Nutzung wird anstelle von COLCARDF mit FULLKEYCARDF oder FIRSTKEYCARDF kalkuliert Sind bestimmte Ausprägungen vom Optimizer nicht erkennbar, werden andere FF eingesetzt, z.b.: abt_nr = :abt-nr... Die gilt auch bei Spezialregistern! Eine HV in Verbindung mit den Prädikattypen = und IN erfährt keine Unterscheidung zu konstanten Werten und wird normal kalkuliert Diese Formeln finden keine Anwendung, wenn vor Ausführung des BIND-Parameters REOPT(VARS) die Inhalte der HV berücksichtigt werden und aufgrund der tatsächlichen Inhalte der optimale Zugriffspfad gefunden wird. Generell ist ein niedriger FF,der nur eine kleine prozentuale Auswahl aus dem Gesamtvolumen ausweist, kosteng nstiger als ein hoher FF S.K. Consulting GmbH, München DB2_SQL_PERF