SQL-Optimizer und Optimierung bei DB2 S.K. Consulting GmbH, München DB2_SQL_PERF - 1 -
Inhaltsverzeichnis 1. Optimierung bei DB2 1.1 Einflussfaktoren auf die Entscheidung des Optimizers 1.2 Übersicht über die Prädikate 1.3 Filterung und Filterfaktoren 1.3.1 Verteilung von Datenwerten 1.3.2 Filterfaktoren für die Prädikattypen 1.3.3 Interpolationsformeln für "uniform distribution" 1.3.4 Ermittlung der FF - Beispiele S.K. Consulting GmbH, München DB2_SQL_PERF - 2 -
Nach einer Zugriffspfadanalyse entscheidet sich der Optimizer von DB2 für einen Plan, der die Daten dem User möglichst effizient zur Verfügung stellen soll. 1.1 Einflussfaktoren auf die Entscheidung des Optimizers Der Optimizer versucht bei der Pfadanalyse die Zugriffskostenn zu errechnen und zu bewerten. Dabei helfen ihm folgende Faktoren: I/O und CPU-Nutzung! Wahl des Bufferpools! CPU-Modell Status der Tabellen/statistische Daten! Anzahl Zeilen(CARD)! Anzahl bei Pages (NPAGES)! Prozent genutzte Pages(PCTPAGES) Verfügbare Indizes und Index-Aufbau! Unique! Clustered(CLUSTERRATIO)! Index Keys (single, compound)! "multiple index" - Access SQL-Query-Formulierung! Typ(einfach, komplex)! SELECT-Auswahlliste! Prädikate und Verarbeitungsebenen! Klauseln (GROUP BY, ORDER BY) S.K. Consulting GmbH, München DB2_SQL_PERF - 3 -
1.2 Übersicht über die Prädikate Die Qualität und Art der Prädikate bei SQL sind in hohem Masse entscheidend für die Effizienz des Zugriffs auf die erforderliche Datenmenge. Prädikate können in folgende Kategorien eingeteilt werden: "simple" oder "compound"-prädikate ein Prädikat, das mit AND bzw. OR verknüpft ist ist "COMPOUND", ansonsten wird es als "SIMPLE" eingestuft. Desweiteren qualifiziert man Prädikate nach Operationstyp. "SIMPLE" Prädikate weren durch folgende Operationstypen definiert: subquery PERSNR IN ( SELECT ABTLTNR FROM... ) equal PERSNR = '12345' oder DAUER IS NULL IN-List PERSNR IN ( '12345', '34598', '78954' ) range EINSTELLUNGSDATUM > '1.1.1999' oder EINSTELLUNGDATUM BETWEEN '1.01.1999' AND '30.6.1999' NOT EINSTELLUNGSDATUM <> '1.1.1999' oder EINSTELLUNGDATUM NOT BETWEEN '1.01.1999' AND '30.6.1999' ON ON MITARBEIER.PERSNR = ABTEILUNG.ABTLTNR Local oder JOIN Ein Prädikat, das mehr als eine Tabelle umfasst, oder eine Korrelation enthältheisst JOIN-Prädikat. Alle anderen Prädikate werden als LOKALE Prädikate bezeichnet. indexable oder non-indexable Ein Prädikat, für das über die Index-Hierarchien ein oder mehr Index-Einträge gefunden werden ist INDEXABLE. S.K. Consulting GmbH, München DB2_SQL_PERF - 4 -
STAGE1 oder STAGE2 Ein Prädikat, für das die WHERE-Klausel die Beschränkung der Daten beim Lesen übernimmt ist STAGE1. Alle anderen Klauseln sind STAGE2. Boolean Term (BT) kann ein "simple" oder "combound"-prädikat sein. Wird ein Boolean Term für eine Zeile als "false" klassifiziert, sind alle diese Zeile betreffenden WHERE-Bedingungen "false". Beispiel: WHERE col1 = x AND (col4 > y OR col2 = z) ist ein "compound" Boolean Term Prädikat. BT Prädikate sind effizienter als "non-bt" Prädikate, da sie helfen die Qualität einer Zeile ("false" / "true" ) möglichst früh zu bestimmen. BT-Prädikate werden für "Matching Index"-Scans verwendet. Ggf. versucht der Optimizer eine Indexnutzung über einen "multiple index access" zu erreichen. S.K. Consulting GmbH, München DB2_SQL_PERF - 5 -
1.3 Filterung und Filterfaktoren Aus der gelesenen Datenmenge müssen bei Projektion, Gruppierung, usw. Daten gefiltert werden. Eine Filterung bei DB2 wird auf zweierlei Wesen unterstützt: Indexnutzung: aufgrund der WHERE-Klausel werden Indexeinträge gesucht und beim Hit ein Datenzugriff (phys. I/O) eingeleitet. Filter auf Datenebene: aufgrund der WHERE-Bedingung werden Datenzeilen untersucht. Ein Filterfaktor (FF) kalkuliert die Anzahl Zeilen, die in die Resultatsbearbeitung miteinbezogen werdeen müssen - sie sind aufgrund der WHERE-Bedingung als "true" qualifiziert worden. Der FF eines Prädikats ist eine Wahrschein-lichkeitszahl ( 0 <= z <= 1). Jekleiner FF, umso weniger Zeilen können im Ergebnis erwartet werden. Die Filterfaktoren haben eine enorme Auswirlung auf die Performance, da sie die Anzahl zu verarbeitender Zeilen bewerten. Sie werden bei der Ermittlung der I/ O- und Verarbeitungskosten herangezogen. Der Optimizer benötigt hierzu die Aussagen aus dem RUNSTATS-Utility über die Kardinalität der Werte (Häufigkeit) und der Nutzungmöglichkeiten von Indizes. Stehen keine Statistikwerte zur Verfügung, werden Default-Filter-Faktoren benutzt. S.K. Consulting GmbH, München DB2_SQL_PERF - 6 -
1.3.1 Verteilung von Datenwerten Am effizientesten kann der Optimizer arbeiten, wenn die Daten bei der Datenverteilung dem Prinzip der "uniform distribution" folgen. DB2 kenn folgende Verteilungsprinziopien: Uniform Distribution oder Gleichmässige Verteilung Die Datenwerte sind gleichförmig über den Gesamtdatenbestand verteilt. Non-Uniform Distribution oder Ungleichmässige Verteilung Die Datenwerte sind nicht gleichförmig über den Gesamtdatenbestand verteilt. z.b.:! Daten in einem PTS werden aufdgrund des "partitioned index" verteilt Daten! Daten besitzen eine unterschiedliche Kardinalität mit hoher Varianz ( Kunden mit viel und sehr wenig Aufträgen... ) Eine Bewertung der Verteilung für die Filterung bei DB2 gestaltet sich dann schwierig, wenn beim BIND-Prozess noch keinen Hinweise auf die konkrete Datenanforderung vorliegen: Bei Einbezug von Hostvariablen in die SQL-Formulierung ist dies IMMER der Fall. S.K. Consulting GmbH, München DB2_SQL_PERF - 7 -
1.3.2 Filterfaktoren für die Prädikattypen Bei "Simple Predicates" wird der FF durch folgende Kriterien beeinflusst: Statistiken der Spalten im Katalog Konstante aus der Query (bei Hostvariablen nicht erkennbar) Operator des Prädikats Bei "compound Predicates" wird der FF durch folgende Kriterien beeinflusst: Anzahl übereinstimmender Werte beim "single index access" Ergebnis aller Prädikate bezogen auf die Daten einer Tabelle Ergebnis der RID-Kandidatenliste eines "multiple index access" Folgende Typen von FF werden genutzt: "default"-statistikwerte: wenn keine Statistiken verfügbar (COLCARDF = -1) "uniform distribution filter factors": bei einer angenommenen gleichförmigen Verteilung werden Standardwerte eingesetzt. Eine gleichmässsige Verteilung wird angenommen, wenn Statistikdaten vorhanden sind (COLCARDF <> -1) und keine zusätzlichen Statistiken vorhanden sind - z.b. in SYSCOLDIST. Angewandt werden Interpolationsformeln. Werden Host-Variable verwendet, sind "default-ff" definiert. "other distribution filter factors": bei ungleichmässiger Verteilung können über RUNSTATS die häufigsten Inhaltswerte von Index- Spalten aufgezeichnet werden. Dies werden dann in der Spalte SYSCOLDIST geführt. Beispiel: Wert: München Häufigkeit: 678 FF: 6,78 oder 0,0678 S.K. Consulting GmbH, München DB2_SQL_PERF - 8 -
1.3.3 Interpolationsformeln für "uniform distribution" Prädikattyp COL = <wert> COL IS NULL COL >, >= <wert> COL <>, <= <wert> COL BETWEEN <wert1> AND <wert2> COL LIKE '<literal>%' COL IN (<literal-liste>) COL = <ausdruck> <ausdruck> = <wert> <ausdruck> ^= <wert> <ausdruck> op <wert> COL ^ = <wert> COL IS NOT NULL COL NOT BETWEEN <wert1> AND <wert2> COL NOT LIKE '<literal>%' COL NOT IN (<literal-liste>) COL LIKE '%<literal>' COL LIKE '_<literal>' T1.COL = Tx.COL T1.COL ^ = Tx.COL T1.COL op Tx.COL COL = (<subquery>) COL ^ = (<subquery>) COL >, > = (<subquery>) COL <, < = (<subquery>) COL IN (<subquery>) COL NOT IN (<subquery>) COL = ANY,ALL (<subquery>) COL ^= ANY,ALL (<subquery>) <prädikat1> AND <prädikat2> <prädikat1> OR <prädikat2> Filterfaktoren(FF) 1/COLCARDF 1/COLCARDF (HIGH2KEY-<wert>)/(HIGH2KEY- LOW2KEY) (<wert>-low2key)/ (HIGH2KEY-LOW2KEY) (<wert2>-<wert1>)/(high2key-low2key) <analog> BETWEEN <literal> X'00' AND <literal> X'FF' <anzahl literale> (1 / COLCARDF) 1-1 / COLCARDF 1-1 / COLCARDF 1 - (<wert2>-<wert1>) / (HIGH2KEY- LOW2KEY) <analog> NOT BETWEEN <literal> X'00' AND <literal> X'FF' 1 - (<anzahl literale> (1 / COLCARDF)) <analog> BETWEEN <literal> X'00' AND <literal> X'FF' <analog> BETWEEN <literal> X'00' AND <literal> X'FF' MIN(FF(<col1>), FF(<col2>)) 1 - MIN(FF(<col1>), FF(<col2>)) 1/COLCARDF 1-1/COLCARDF (HIGH2KEY-<wert>)/(HIGH2KEY- LOW2KEY) (<wert>-low2key)/(high2key- LOW2KEY) FF(<subquery>) 1 - FF(<subquery>) FF(<subquery>) 1 - FF(<subquery>) FF(<prädikat1>) FF(<prädikat2>) FF(<prädikat1>) + FF(<prädikat2>) - FF(<prädikat1>) FF(<prädikat2>) Default FF = Wert n 1/25 n 0,04 1-1/25 0,96 1/3 0,33 1-1/25 0,96 1-1/25 0,96 1/3 0,33 1/3 0,33 1 - (n 1/25) 1 - (n 0,04) 1 1 1 1 1-1/25 0,96 1/3 0,33 1-1/25 0,96 1/10 0,10 1-1/10 0,90 1/10 0,10 1-1/10 0,90 S.K. Consulting GmbH, München DB2_SQL_PERF - 9 -
1.3.4 Ermittlung der FF - Beispiele "Ausgangsdaten" indizierte Spalten KURS, REFERENT, TERMIN FULLKEYCARDF 2500 unterschiedliche IX-Werte FIRSTKEYCARDF 50 unterschiedliche KURSE COLCARDF auf REFERENT 20 unterschiedliche REFERENTEN CARDF 10.000 Tabellenzeilen Anforderung ermittelter FF WHERE KURS = 'ORA_01' FF = 1/FIRSTKEYCARDF = 1/50 = 0,02 WHERE KURS = 'ORA_01' AND FF = 1/FIRSTKEYCARDF = 1/2500 = 0,0004 REFERENT = 'Kraus' AND TERMIN = '01.10.1999' WHERE KURS = 'ORA_01' AND REFERENT = 'Kraus' FF = (1/FIRSTKEYCARDF 1/COLCARDF von REFERENT) = (1/50 1/20) = (0,02 0,05) = 0,001 WHERE KURS BETWEEN FF = ( 'ORA_04' - 'ORA_01') / (HIGH2KEY - 'ORA_01' AND 'ORA_04' LOW2KEY). Es werden die EBCIDIC- Differenzen binär ermittelt. Anstelle der COLCARDF wird bei IX-Nutzung mit FULLKEYCARDF oder FIRSTKEYCARDF gearbeitet S.K. Consulting GmbH, München DB2_SQL_PERF - 10 -