(*) IBM DB2 V9 for LUW. DB2 Performance & Tuning. (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc.

Transkript

1 (*) IBM DB2 V9 for LUW DB2 Performance & Tuning (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc. 1

2 DB2 for LUW Performance & (SQL) Tuning Kapitelinhalt Best Practices in einem DWH Umfeld BP - Database Design BP Überlegungen zu Applikationen BP Performance Layer BP - Configuration and Operations DB Design und Objektdefinitionen Denormalisierungsmuster Physisches Design und Datentypen bei DB2 Index Designmuster SQL Tuning Query Design Optimization class und Optimizer SQL EXPLAINs SQL runtime optimization (MQT s, temp Tables, SORTs) Beeinflussen des access plan bei DB2 Zugriffsarten bei DB2 Regeln zu Tabellen- und Index-Design 2

3 DB2 for LUW Tuningpotentiale 2 = DB2 System (10%) 3 = phys. DB-Design Design (20%) 4 = Anwendung (60%) = OS System (10%) 3

4 DB2 for LUW BP in einem DWH Umfeld DWH Eigenschaften: Große Datenmengen Millionen/Billionen rows auf bestimmten Tabellen Grosse Datenmengen werden rolled-in und rolled-out Komplexe Queries Grosse Joins Riesige Sorts, Große Anzahl von Aggregationen Viele involvierte Tabellen Ad Hoc Queries Dabei ist es wichtig STÄNDIG auf die Performance zu achten Ziele: Vorgabe von Empfehlungen, um die data warehouse query performance hoch zu halten (1) Empfehlungen zum Database Design (2) Empfehlungen zum Application Design (3) Empfehlungen zu den Performance Layers (4) Empfehlungen zu ständigen Tuningaktivitäten 4

5 DB2 for LUW Performance & (SQL) Tuning Kapitelinhalt Best Practices in einem DWH Umfeld BP - Database Design BP Überlegungen zu Applikationen BP Performance Layer BP - Configuration and Operations DB Design und Objektdefinitionen Denormalisierungsmuster Physisches Design und Datentypen bei DB2 Index Designmuster SQL Tuning Query Design Optimization class und Optimizer SQL EXPLAINs SQL runtime optimization (MQT s, temp Tables, SORTs) Beeinflussen des access plan bei DB2 Zugriffsarten bei DB2 Regeln zu Tabellen- und Index-Design 5

6 DB2 for LUW BP in einem DWH Umfeld Best Practices Parallelism Database partition feature (DPF) wird empfohlen (1) Um Parallelität in DWH Umgebungen zu erreichen (2) Um die Skalierbarkeit des Systems und die Query Performance zu verbessern SMP (Intra-Query Parallelism) ist nicht zu empfehlen (1) In konkurrierenden multi-user environments mit hohem CPU Verbrauch SMP Empfehlung (1) Wenn die CPUs unterbeschäftigt ist (2) Wenn DPF nicht in Frage kommt Partitioning (als ergänzende Strategie in DB2) Database Partitioning (DPF) DISTRIBUTE BY HASH Vorteil: Bessere Skalierbarkeit und Performance durch Parallelverarbeitung Multidimensional Clustering (MDC) ORGANIZE BY DIMENSION Vorteil: Bessere Query Performance durch data clustering Table (Range) Partitioning PARTITION BY RANGE / Table Partitioning Vorteil: Besseres Datenmanagement ( roll-in und roll-out von Daten) UNION ALL Views Vorteil: Unabhängige Optimierung bei mandantenfähigen Daten 6

7 DB2 for LUW BP in einem DWH Umfeld Divide et impera! Distribute, Partition, Organize! 7

8 DB2 for LUW BP in einem DWH Umfeld Best Practices Database Partitioning Man sollte die fact - und die größte dimension Table entsprechend anordnen Die Auswahl erfolgt so, dass signifikante Überschneidungen auf den Partitions vermieden werden Vermeiden von DATE dimension, für aktive Transaktionen, die wegen current date alle auf dieselbe database partition zeigen müssten (TIMESTAMP ist OK) Möglichkeiten der Isolation von workload bei data marts Unterschiedliche «partition groups», aber gemeinsame «dimension tables» replicated tables (Mehr später ) Best Practices Table Partitioning Empfehlung: partitioning der fact tables Typischerweise auf der Basis der DATE Dimension Funktioniert besser mit application key predicates, die direkt angewendet werden Table - oder Range Partitioning Empfehlung: table - / range partitioning (V9.7 : auch partitioned indexes ) Wahl des partitioning nach der roll-in / roll-out Granularität UNION ALL Views Jeder Ableger kann unabhängig optimiert werden Nutzung nur mit gut designten Applicktionen (Gefahr der materialization ) Große Mengen von Ablegern brauchen Zeit und Speicher beim Optimieren Benötigen Prädikate mit Konstanten zur Eliminierung von Ablegern 8

9 DB2 for LUW BP in einem DWH Umfeld Best Practices Multidimensional Clustering (MDC) Empfehlung: Definition von MDC auf der fact table Garantiertes clustering (Also: Vermeidung von REORG wegen des clustering ) I/O Optimierung Kompakte Indexes (in Koexistenz mit den regular indexes ) Auswahl der dimensions auf der Basis von query predicates Empfehlung: 1 bis 4 dimensions Die dimensions sollten so gewählt sein, dass sie möglichst wenig Speicher vergeuden Mögliche Wahl einer feineren Granularität der Table partitioning range : Beispiel: Table Partition range by MONAT, MDC über DATUM 9

10 DB2 for LUW BP in einem DWH Umfeld 10

11 DB2 for LUW BP in einem DWH Umfeld Best Practices (physical) Schema Surrogate Keys Soweit möglich sollten die keys aus den Applikationen direkt verwendet werden Ermöglicht die Anwendung/den Transfer der Prädikate direkt auf die fact table DATE ist ein guter Kandidat (einfach für roll-in / roll-out und für MDC ) Star Schema / Snowflakes Separieren der tables pro dimension hierarchy ( snowflake ) kann in einer großen Zahl JOINs resultieren Das Zusammenlegen von dimensions kann zu hoher Redundanz führen ( space ) Definiere NOT NULL wenn möglich: Viele Optimierungen basieren auf NOT NULL Feldern Definiere Eindeutigkeit, wenn möglich: «Primary Keys» / «Unique Constraints» / «Unique Indexes» Compression (auf der fact table und wenn nicht CPU-bound ) Table, Index und Temp Table Kompression Große Vorteile im Einsparen von Speicherplatz Bei Tabellen- und TEMP Kompression 30-70% Bei Index Kompression 30-40% Performance Gewinne, da weniger I/O und effizientere Nutzung der Bufferpools TEMP table compression hilft bei Verarbeitungen wie Hash Join, Merge Join, Sorts und Table Queues, die überlaufen können 11

12 DB2 for LUW Partitionieren bei DWHs Best Practices bei Applikationen Nutzen von Konstanten anstatt von expressions in einer Query Beispiel:. WHERE DateCol <= CURRENT DATE 5 Nutz man VALUES(CURRENT DATE 5) so erhält man erst die Konstante und kann sie dann in der Query verwenden Vermeiden von expressions auf indizierten Spalten Beispiel:. WHERE DATECOL 2 DAYS > WHERE DATECOL > DAYS Vermischen von Datentypen in JOIN (oder auch anderen) Prädikaten Beispiel:.WHERE IntegerCol = DecimalCol Nutzen von Global Temporary Tables, um eine Query aufzuteilen, falls sie mehr als Tables anspricht Reduziert die Optimierungszeit Später noch mehr davon. 12

13 DB2 for LUW Partitionieren bei DWHs Best Practices Performance Layer Indexes Statistiken Distribution Statistics Column Group Statistics Statistical Views Constraints Referential Integrity Materialized Query Tables (MQT s Replicated Tables Indexes Indexes sind ein vertikales subset der Tabellendaten Indexes sind immer in einer bestimmten Reihenfolge(ORDER: ASC, DESC) sortiert Indexes ermöglichen clustered Zugriffe auf eine Tabelle 13

14 DB2 for LUW Partitionieren bei DWHs Index Überlegungen Index Only Access anstatt teuerer ISCANFETCH oder TSCAN (Table Scan) Vermeiden von SORTs - besonders die grossen SORTs index-oring und index-anding, Star Joins Bei range join predicates : Nested Loop Join bietet mehr Möglichkeiten Indexes for clustering (MDC) Schätzen der Kardinalitäten Schätzen der Größe von Zwischenresultaten, die für gute execution plans kritisch sind Bei ungenügender Information kann der Optimizer nur auf der Basis von Annahmen schätzen Bei Ungleichverteilung und statistical correlation zwischen mehreren Spaltenwerten, entsteht Unsicherheit bezüglich der Statistiken Man achte auf DATE Spalten Best Practices - Statistics Sammeln von distribution Statistics bei Ungleichverteilung und Prädikaten mit Konstanten Sammeln einer großen Anzahl von quantile statistics auf Spalten mit DATE range predicates und character string Spalten Column Group Statistics Beispiel: COUNTRY = Germany And CITY = Frankfurt No CGS: Selectivity = ½ * 1/3 = 1/6 Estimate 1 row With CGS: Selectivity = 1/3 Estimate 2 rows 14

15 DB2 for LUW Partitionieren bei DWHs Best Practices - Statistics Problemscenario: rows CUST Table :100 rows, 100 custids Frequency Statistics SALES Table SELECT WHERE FROM SALES, CUST CUST.CNAME = IBM AND CUST.CUSTID = SALES.CUSTID Cardinality - Schätzung mit Gleichverteilung = 100,000 Aktuelle Kardinalität : 2,000,000!!!!!!!!!!!!!!!!!!!! 15

16 DB2 for LUW Partitionieren bei DWHs Best Practices - Statistics Sammeln von Column Group Statistics bei mehreren gleichwertigen Prädikaten auf derselben Tabelle:.WHERE Country = CANADA and City = TORONTO RUNSTATS ON ALL COLUMNS AND ON COLUMNS ((country, city) ) Man denke an Statistical Views wenn Die JOIN Spalte ungleich verteilte Werte aufweist Es signifikante Unterschiede in der range of values in fact und dimension Table gibt CREATE VIEW SV1 AS (SELECT C.* FROM CUST C, FACT F ALTER VIEW cust_fact ENABLE QUERY OPTIMIZATION WHERE C.CUST_ID = F.CUST_ID) RUNSTATS ON TABLE dba.cust_fact WITH DISTRIBUTION Referential Integrity (RI) Unterstützt den sogen. Prozess des aggregation push down (Beispiel später.) Eliminiert redundante Joins in Views RI hilft bei der Entscheidung, ob Daten von der primary key table gebraucht, aber nicht gejoined werden müssen, auch wenn sie Bestandteil des View sind Hilft beim Materialized Query Table matching Ermöglicht Queries den match einer MQTs mit mehreren dimension table Joins 16

17 DB2 for LUW Partitionieren bei DWHs Materialized Query Tables (MQTs) 17

18 DB2 for LUW Partitionieren bei DWHs Best Practises Definieren von Materialized Query Tables (MQTs) Welche MQTs sollten definiert werden? Schätzen der Größe der MQTs über COUNT Queries gegen die base tables mindestens die 10X Reduktion in der Größe zwischen fact table und MQT sollte erreicht werden Aufbau der MQTs mit einer sinnvollen Zahl von GROUP BY Spalten (3 bis 6 dimension keys ) auf eine Zeitachse bezogen Soweit möglich sollte die MQT ausschließlich aus der fact table gebildet werden Man setze dann Table Partitioning für die fact table und die MQTs ein Best Practices - MQT Matching Definition von Referential Integrity, zur Unterstützung entsprechender MQTs, die mehr Tabellen als Queries enthalten Definition von funktionalen Abhängigkeiten in kleineren MQTs Nutzen von COUNT_BIG anstatt von COUNT bei DPF MQTs Definiton von Indexes auf MQTs Statistiken sollten immer up-to-date sein Definition der base table Spalten mit NOT NULL soweit irgendwie möglich Beispiel: SUM(A + B) kann substituiert werden mit SUM(A) + SUM(B) 18

19 DB2 for LUW Partitionieren bei DWHs Best Practises MQT Maintenance REFRESH IMMEDIATE Create eines IX auf GROUP BY Spalten Create eines IX auf Spalten, die einen unique key ergeben up-to-date halten der Statistiken für base table und MQT s REFRESH DEFERRED Wenn der log space ein Thema sein sollte, sollte NOT LOGGED INITIALLY oder LOAD über cursor erfolgen Eine MQT kann temporär in eine regular table umgeschaltet werden (1) ALTER TABLE DROP MATERIALIZED QUERY (2) ALTER TABLE ADD MATERIALIZED QUERY Einsatz von ATTACH / DETACH, wenn die fact table und MQT range partitioned sind Replicated Tables Replikation der dimension tables (außer bei Kollokation mit fact ) Benefit : Verhindert das Verschieben von Daten Wichtig : Definition passender IX Wenn zu riesig, Replikation eines subset of frequently used columns 19

20 DB2 for LUW Partitionieren bei DWHs Best Practices - Statistics Der DB2 Query Optimizer verläßt sich auf genaue Statistiken und erzeugt nur dann gute query plans User nutzen RUNSTATS wenn sich die Daten ändern (Teil von ETL) Erzeugen von Statistiken (weniger zuverlässig) DB2 hält UPDATE / DELETE / INSERT counters Diese Aufzeichnungen sind limitiert auf einige wenige Statistiken und damit nicht genug Konfiguration mit Automatic Statistics Automatisches Sammeln der tabellenstatistiken nach Bedarf Läuft im background als low priority job Konfiguration mit Real Time Statistics: sammelt Statistiken on-the-fly Best Practises Konfiguration Optimization Level 5 Registry Variable DB2_ANTIJOIN=EXTEND: bei langsamen Queries mit NOT EXISTS, NOT IN Prädikaten DB2_REDUCED_OPTIMIZATION=YES: Falls die Compile Zeit wichtig ist Basisregeln für die Konfiguration BUFFPOOL ~= SHEAPTHRES SORTHEAP ~= SHEAPTHRES/(# of concurrent SORT, HSJN) 20

21 DB2 for LUW SQL Tuning & Monitoring Kapitelinhalt Best Practices in einem DWH Umfeld BP - Database Design BP Überlegungen zu Applikationen BP Performance Layer BP - Configuration and Operations DB Design und Objektdefinitionen Denormalisierungsmuster Physisches Design und Datentypen bei DB2 Index Designmuster SQL Tuning Query Design Optimization class und Optimizer SQL EXPLAINs SQL runtime optimization (MQT s, temp Tables, SORTs) Beeinflussen des access plan bei DB2 Zugriffsarten bei DB2 Regeln zu Tabellen- und Index-Design 21

22 DB2 for LUW Design und Objektdefinition Das Vorgehen bei der vollständigen Informationsanalyse Funk- tions- Analyse Informa- tions- Analyse abgestimmtes Informations- Modell Phys. DB-Design Abstimmung Kanonische Synthese Funk- tions- Modell Elem.- Funktion Informa- tions- Modell Datensichten und "dataflow"- Modell 22

23 DB2 for LUW Design und Objektdefinition Das Vorgehen beim physischen (systemspezifische) Design für DB2 (1) Der physische Design-Prozess unter Technischen Aspekten Performance-Gesichtspunkten (2) STORAGE Parameter ( automatic, on demand, SMS, DMS.) Entity Relatonship modelling (problemorientiert) Normalisierung (datenorientiert) Größen, Typen Bufferpools storage layout conceptual modelling (logisch orientert) (3) DB2 Objekte DATABASE(S) TABLESPACES TABLES INDEXES VIEWS / MQTs / andere Objekte (4) DDL und Implementierung Composite logical modelling (optimiert) Physical modelling (DBMS- / zugriffsorientert) 23

24 DB2 for LUW Design und Objektdefinition Das Vorgehen beim physischen (systemspezifische) Design für DB2 Die Schritte 1. Überführung der "entities" Übernahme von Satztypen Trennen von Satztypen Zusammenlegen von Satztypen Ergänzen von Entities (um Kennzeichen, Marker ) 2. Überführen der Beziehungen Behandlung von 1 : 1 "relationships" Behandlung von 1 : n Beziehungen / Definition von foreign keys Implementieren von Beziehungsregeln ( RI, constraints ) 3. Einrichten der Zugriffspfade Behandlung der Einstiegspunkte Auswahl der physischen Zugriffspfade 4. Festlegen der DBMS-spezifischen Parameter Blockgröße / Satzgröße Speicherplatzgröße / Speicherplatzorganisation physische Speicherungsfolge Beachten organisatorischer Einflüsse (DBA) usw. 5. Integration in das bestehende PDM 24

25 DB2 for LUW Design und Objektdefinition Das Vorgehen beim physischen (systemspezifische) Design für DB2 Beispiel 1. Satztypen zusammenlegen Bei einer 1:n - Beziehung ist eine Zusammenlegung von Satztypen nur sinvoll, wenn der n-satztyp ISOLIERT im Informationsmodell steht! 2. Denormalisierung Denormalisierte Strukturen helfen insbesondere bei relationalen DBMS JOIN-Operationen zu minimieren und so die Performance in bestimmten Bereichen (beim LESEN) zu steigern. Beispiel: KUNDE ( KD-NR, KD-Name, KD-PLZ, KD-ORT, KD-Strasse,.) normalisiert: KUNDE ( KD-NR, KD-Name, KD-OKZ, KD-Strasse... ) ORTE ( OKZ, O-PLZ, O-ORT... ) Anmerkung: Das Beispiel ist hier natürlich nicht vollständig, da es eine PLZ für mehr als einen Ort geben kann und ebenfalls ein Strassennamen in mehr als einem Ort vergeben sein kann Als Voraussetzung für denormalisierte Strukturen sollte gelten: Der Änderungsaufwand der Redundanzen ist überschaubar - Die Änderungshäufigkeit ist gering!! ACHTUNG: Bei jeder Denormalisierung entstehen Redundanzen, die GEPFLEGT werden müssen, um die DB-Inhalte KONSISTENT zu halten! 25

26 DB2 for LUW Design und Objektdefinition Das Vorgehen beim physischen (systemspezifische) Design für DB2 Die Zugriffspfade Beziehungen werden über Schlüsselredundanzen realisiert: "primary key" "foreign key" Es ist dabei wichtig zu wissen, ob nur eine oder BEIDE Richtungen der Beziehungen benötigt werden. 2. Denormalisierung Beachte: Bei konkurrierenden Einstiegspunkten sollte der Index gewählt werden, der möglichst "hochwertig" ist: 1. "cluster index" 2. "primary key" oder "unique index" 3. "normaler" Index ( duplicates ) Wird der Datenbestand sehr häufig erweitert (INSERT ) oder verringert (DELETE), so sollten im Sinne der Performance möglichst SELEKTIVE, aber WENIGE Indizes auf den Tabellen liegen. 26

27 DB2 for LUW Design und Objektdefinition Das Vorgehen beim physischen (systemspezifische) Design für DB2 Die Physik 1. Berechnen der Speicher-Größen "primary space" / "secondary space Bestimmung Bestimmen zusammengehöriger Tabellen für EINEN/MEHRERE TS(?) Bestimmen des TS-Typs (MDC, PTS, normaler TS) Festlegen der Größe und des Füllgrades der Pages (4K, 8K, 16K, 32K, PCTFREE, FREEPAGE) Zuordnung zu file systems / containers etc. LOCKSIZE Festlegung 2. Festlegen der (DB2-)Datentypen in den Tabellen Wenn möglich numerische Felder VOR Feldern mit anderen Datentypen wenige NULL-Felder eher NOT NULL WITH DEFAULT keine LONGVARCHAR / VARCHAR / LOB Felder (wegen IX Nutzung) Lassen Sie die Finger von ineffizienten Datentypen wie: GRAPHIC und VARGRAPHIC Anordnung der Spalten in der Tabelle (VARCHAR und NULL-Felder ans Ende der Tabelle, usw.) Definition von RI-Bedingungen ( falls nötig ) und constraints (nach Domänen etc.) Festlegen der "views / ALIASE / SYNOMYMs 3. Definition der DB2-Datenbanken nach organisatorisch / administrativen Gesichtspunkten nach Datenverfügbarkeitsanforderungen ( mit Hilfe der Datenbankadministration! ) Testdatenbanken sind NIE oder nur SELTEN gleich der PROD-Datenbank!! 27

28 DB2 for LUW Index-Design Warum sind Indizes so wichtig? Eine gute Strategie für Indizierung ist der Schlüssel No 1 für gute Performance IXe reduzieren die I/O-Aufwände dramatisch. IXe reduzieren den CPU Verbrauch. IXe reduzieren die Elapsed Time für Queries. Weitere vorrangige Aufgaben von Indexen? Primary keys sichern Eindeutigkeit der Daten ab.("primary keys" "Entity Integrity ) Clustering bestimmt die physische Reihenfolge bei der Speicherung der Daten Partitionierung erlaubt die Aufteilung von (grossen)datenmengen IX begrenzen die Suche nach bestimmten Wertemengen IX begrenzen die Anzahl physischer Platten-I/O s und verbessern die Datenzugriffe (bei sequentiellem Lesen, SORT, paralleler Verarbeitung usw.) 28

29 DB2 for LUW Index-Design Indexorganisation Root-Page Indexpages (Indexspace) nonleaf-pages * * 08 * * 17 * * 25 * * 33 * * 40 * * 61 * * 86 Pointer auf die Datensätze Leaf-Page Datenpages (Tablespace) 29

30 DB2 for LUW Index-Design Die IX-Struktur im Detail Index leaf pages besitzen für jeden indizierten Wert einer Spalte diesen WERT, gefolgt von einem oder mehreren RID(s) ( Record Identifier ) Die RID ist nichts anderes als ein 4 Byte Pointer auf die Datenpage, die die indizierte row enthält (5 Bytes für einen partitioned tablespace > 64 GB und <= 16 TB) 3 Bytes für die sogen. Page Location 1 Byte für den page directory Eintrag - das offset der row in der Page Besteht der Index aus 3 Ebenen So enthalten die Non-leaf pages über den leaf pages die höchsten Werte der jeweiligen darunter liegenden leaf page mit den Pointers zu diesen leaf pages Bei IX > 3 Levels So enthalten die Nonleaf pages über den leaf pages die höchsten Werte der jeweiligen darunter liegenden leaf page mit dem Pointers zu diesen leaf pages Nonleaf pages oberhalb der 1.en Ebene der nonleaf pages enthalten die höchsten range -Werte für jede nonleaf page gefolgt von den Pointers auf die nächst-niedrigeren nonleaf pages kein architekturbezogenes Limit für die Anzahl von nonleaf Ebenen in einem IX-Baum Die root page verkörpert die oberste Ebene des Index-Baums 3 Byte pagenum 1 Byte slotnum X: 053ED4 : 29 Enthält den höchsten Wert jeder unterliegenden nonleaf page range mit Pointern auf das erste Level der nonleaf pages oder auch der leaf pages (bei einem IX über 2 Ebenen) 30

31 DB2 for LUW Index-Design Die IX-Struktur im Detail SYSIBM.SYSINDEXES enthält die Anzahl der Levels Ein I/O ist auf jeder Ebene eines Index Trees erforderlich Getpage und I/O sind optional für jede Ebene notwendig (IX-Lookaside) getpage alleine ist erforderlich, wenn die IX Page nach dem ersten I/O im Bufferpool steht Hier ein Beispiel eines IX auf eine 10 Byte lange Spalte - es interessiert die Anzahl von Type 2 Index Levels, die benötigt werden, um eine bestimmte Anzahl rows zu referenzieren Ein 2 Level Index besteht aus einer root page und zugehörigen leaf pages Ca. 45,000 unique IX Werte inkl. RIDs können in einem 2 level index Platz finden Ein 3 Level Index besteht aus root page, 1 Level nonleaf pages und leaf pages Ca. 9,850,000 unique IX Werte inkl. RIDs können in einem 3 level index Platz finden «Nonunique indexes» erfordern weniger «index pages» Indizierte Werte müssen müssen für Duplikate nicht wiederholt werden non-leaf page dup IX KEY 1 RID 1 RID 2 Flagbyte Flagbyte RID n KEY 2 Flagbyte KEY- Header 31

32 DB2 for LUW Index-Design Die IX-Struktur Probleme mit unbalanced IX Trees Ein Index Tree wird dann unbalanced, wenn viele INSERTS entlang einem bestimmten Pfad erfolgen Es müssen dann zusätzliche I/Os entlang dem unbalanced path erfolgen, und wenn das auf einem möglichst intensiv genutzten Pfad erfolgt, führt das zu erheblichen Performance-Problemen Methoden, einen balanced index tree zu pflegen 10 % percentage free space für die Hinzufügung von index entries gilt als default Ist der free space in der IX Page voll, so erfolgt Ein page split : die Hälfte der IX-Werte (auch mehr/weniger) werden jeweils auf 2 Index Pages aufgeteilt Ausnahme: die letzte leaf page eines type 2 Index Die übergeordnete Page hat nun einen Pointer auf 2 untergeordnete Pages Ist kein free space für den extra pointer mehr vorhanden erfolgt ein page split der non-leafpage Dieser Prozess wird fortgeführt, bis die root page erreicht wird Ist auch in der root page kein Platz mehr, geschieht folgendes Die root page wird gesplittet, eine neue root page erzeugt, mit dem Ergebnis N+1 Levels Ein REORG wäre jetzt oder ZEITNAH sehr zu empfehlen!!!! Werden alle Daten in einer leaf - bzw. nonleaf page gelöscht, so wird DB2 versuchen die Page aus dem IX Tree zu entfernen (ansonsten pseudo-deletes ) 32

33 DB2 for LUW Index-Design Die wichtigsten Indexarten für DB2 PRIMARY KEY IX eindeutige Indexwerte, die den eindeutigen Identifikator der Tabelle repräsentieren UNIQUE IX alle IX, die nur eindeutige Indexwerte zulassen (!) CLUSTERING IX der IX, der die physische Reihenfolge der Daten festegt Normal / duplicate IX Zugriffsreihenfolgen in IX-Sequenz sind möglich non-partitioning / partitioning IX zum Aufteilen der Daten (physisch (DPSI / NPSI)) Auf eine Tabelle können mehrere Indizes gelegt sein, aber nur ein "clustered" Index. Wie bei einer Tabelle, kann für IXe ein eigener der "tablespace" zur Verfügung gestellt werden. Für UNIQUE und PK-Indexe können weitere Felder mit INCLUDE angefügt werden. So sieht eine typische DDL für (non-partitioned, not clustered) Indexe aus: CREATE UNIQUE INDEX mytab.uxemp2 ON mytab.emp ( emp ASC, workdept ASC ) NOT PARTITIONED IN index_tsp ; 33

34 DB2 for LUW Index-Design clustering Indexes(allgemein) DB2 versucht die Daten in den Pages in der Reihenfolge des "clustering index" zu speichern. Dieser Index muß nicht unbedingt "unique" sein. Tabelle Grundsätzlich optimiert ein "clustering index" die Performance eines SQL-Statements, das eine Untermenge einer Tabelle in der vom "clustering index" vorgegebenen Folge zuzugreifen versucht. Index auf C1, C2 (clustering) Index auf C3 (non-clustering) Insbesondere bei der Verwendung von "range" - Prädikaten ( BETWEEN, >,. ) auf den IX-Spalten ORDER BY, GROUP BY in der Sequenz der Index-Spalten. Dies reduziert die I/O's. "prefetch"-mechanismen (sequential- und list-prefetch) Für die Definition eines "clustering index" sind folgende Kriterien wichtig: 1. Der "clustering index" spiegelt die Folge der Daten wieder, wie sie in (Batch-)Prozessen benötigt werden. Dies ist besonders bei großen Tabellen effizient. 2. Viele Anwendungen werden von einem "clustering index" nicht beeinflusst. Sie greifen oft auf kleine Datenmengen zu. Ausnahme bilden Such-Anwendungen, die Sortieren oder "prefetch" I/O's vermeiden sollen Sollten die genannten Kriterien in der betrachteten DB2-Umgebung keine Rolle spielen, wählt man einen Index der dem INSERT-Algorithmus folgt. Dies minimiert die Disorganisation der Tabelle. Hat man häufige Join's vor kann auch ein "foreign key" als "clustering key" gewählt werden, um den Join effizienter werden zu lassen. 34

35 DB2 for LUW Index-Design CIX Auswirkungen von PCTFREE und REORG Der "clustering index" muss hinsichtlich seines Einflusses auf folgende Parameter überwacht werden: "free space" INSERT Sequenz Reorganisationshäufigkeit Es gibt einen Zusammenhang zwischen dem freigelassenen Platz und der Reorganisationshäufigkeit: 1. Paßt die INSERT-Folge auf den "clustering index" (bei aufeinanderfolgenden aufsteigenden INSERT's beispielsweise), so kann ein REORG der Tabelle gänzlich überflüssig sein. In diesem Fall sollte PCTFREE = 0 gesetzt werden. 2. Paßt die INSERT-Folge NICHT auf den "clustering index", so sollte für alle Pages der Tabelle Freiplatz vorgesehen werden. In diesem Fall sollte der PCTFREE-Parameter passend zum Tabellenwachstum und zur REORG-Frequenz gewählt werden. CIX Auswirkungen auf asynchrone I/O s DB2 nutzt asynchrone I/O's zum Lesen von der Platte immer dann, wenn es einen Anhaltspunkt für sequentielles Lesen entdeckt; d.h. wenn "ranges" gelesen werden, die der physischen Folge der Daten entsprechen. DB2 versucht außerdem die Daten IMMER in "cluster"-sequenz zu speichern: Alle Zugriffe, die dieser Sequenz folgen, können grundsätzlich von asynchronen I/O's profitieren. Diese Sequenz sollte als Anhaltspunkt für einen "clustering index" auf dem Datenbestand dienen können. 35

36 DB2 for LUW Index-Design CIX und MDC Wann WAS? MDC bietet einen großen Vorteil gegenüber einem clustering index : Das clustering ist garantiert und automatisch. Im allgemeinen kann man mit MDC cluster ratios von 93%-100% erreichen. Das hängt von der erforderlichen coarsification ab. Im Gegensatz dazu, können clustering indexes die Daten nahe an der 100% Grenze clustern anfangs. Später werden die Daten über die Zeit mehr und mehr declustered. So braucht man zeitaufwändige REORGs, um die Daten wieder in Ordnung zu bringen. Generell sollte man MDC einsetzen, um das data clustering zu verwalten, AUSSER:. MDC erfordert coarsification und kann keine generierten Spalten in die Tabelle einfügen Die MDC Version der Tabelle resultiert in einem Wachstum, das man nicht akzeptieren kann oder will. Gut designte MDC Tabellen sind typischerweise 2-15% größer als non-mdc tables. Man findet, dass MDC clustering wegen coarsification eine geringere cluster ratio bietet, z.b. 93%, man will den periodischen REORG vermeiden, aber trotzdem das bessere clustering haben(cix). Folgende MDC design best practices : Die Auswahl der MDC Kandidaten erfolgt über columns, die in Prädikaten für Gleichheit/Ungleichheit, ranges und Sortieren verwendet werden. Um das Daten- roll-in zu verbessern, muss die Dimension der roll-in range folgen. Man bemühe sich um Masse! Für jede existierende Zelle wird ein extent zugewiesen ohne Rücksicht auf die row -Menge in der Zelle. Um MDC mit optimaler Platzausnutzung einzusetzen. muss man auf dicht gefüllte Blöcke achten Man beschränke die Anzahl der Zellen in einem MDC Design. Es gibt Ausnahmen bei denen sich die Größe der Datenmenge verdoppelt und dies trotzdem sinnvoll ist das ist aber eher selten 36

37 DB2 for LUW Index-Design CIX und MDC Wann WAS? Anmerkung: Block Indexe sind normalerweise einen kleinen Prozentsatz so groß, wie der zugehörige TS, und meistens kann man den benötigten Speicherplatz dafür vergessen. Einige Dimensionen sollten koarsifiziert werden, um die Datendichte zu erhöhen. generated columns sollen bei der Anreicherung der Tabellen helfen. Die so nerzeugten Spalten haben eine niedrige Kardinalität; z.b. man erzeuge eine Spalte auf dem Monats- und Jahresteil einer Datumsspalte oder man errechne (INT(colname))/100, um eine DATE Spalte im Format von Y-M-D auf Y-M zu konvertieren Beispiel: Die Query CREATE TABLE Sales (SALES_DATE DATE, REGION CHAR(12), PRODUCT CHAR(30), MONTH GENERATED ALWAYS AS((INTEGER(DATE)/100) ORGANIZE BY (MONTH, REGION, PRODUCT). select * from sales where sales_date> 2006/03/03 and date< 2007/01/01.. Der Compiler generiert zusätzliche Prädikate: month>= and month<= Um verschwendeten Platz zu reduzieren, sollte mna kleine TS extents definieren das verkleinert auch die MDC Block Size 37

38 DB2 for LUW Index-Design CIX und MDC Wann WAS? Man wähle nicht zu viele Dimensionen aus. Es geschieht sehr selten, sinnvolle Designs zu finden, die mehr als drei MDC Dimensionen mit zumutbaren Speicheranforderungen haben. Je mehr dimensions, desto mehr wird die cardinality der Zellen exponentiell wachsen. Das macht es schwierig, die Expansion der MDC Tabellen auf 10% gegenüber einer non-mdc table zu beschränken. vergrößert sich die Tabelle z.b um das doppelte, so braucht sie nicht nur mehr Speicher, sondern sie verliert auch den Vorteil des clusterings, weil mehr I/Os erfolgen wegen der nur zum Teil gefüllten Blöcke. Ein einfaches Beipiel: Eine Tabelle habe drei Dimensionen, die sinnvoll geclustert werden können, jede mit 10,000 eindeutigen Werten. Gibt es keine Korrelation zwischen diesen Spalten, so wird das clustering aller drei Dimensionen (ohne coarsification ) 10,000 x 10,000 x 10,000 Zellen erzeugen mit entsprechenden nur zum Teil gefüllten Blöcken pro Zelle. Bei eine Blockgröße von 1 MB wird der overhead aus diesem fahrlässigen Design ca. 500,000 TB betragen! Z.B. ein single-dimensional MDC.kann massive Vorteile gegenüber traditionelle single dimensional clustered indexes haben, weil: (1) Clustering wird garantiert (2) MDC Tabellen sind über block und nicht über row indiziert, mit dem Resultat, dass die IX grob 1/1000 so groß sind, wie bei gleichen row-based Indexes. (3) DELETE Performance für MDC roll-out ist verbessert. RID indexes auf MDC werden seit DB2 9.5 asynchron gepflegt. (4) MDC unterstützt roll-in von Daten (5) single-dimensional MDC (mit coarsification ) forcieren das clustering OHNE clustering index. MDC guarantiert clustering ohne REORG der Daten 38

39 DB2 for LUW Index-Design Table und Indexpartitioning Table partitioning wird vorwiegend genutzt, um roll-in und roll-out der Daten optimal zu unterstützen. Die asynchrone cleanup -Technologie der DB2 database systems bedeutet, dass selbst bei globalen Indexes, dieser Index über mehrere Partitions hinweg genutzt werden kann. Eine range kann aus der Tabelle abgehängt ( detached ) werden und die betroffenen index keys werden unmittelbar für Queries unsichtbar. Die keys werden in der Folge über einen background process gelöscht mit wenig Einfluß auf die laufende database. Table partitioning bietet weitere Vorteile verbesserter Query Performance über einen internen Prozess - partition elimination der in vielen Fällen den Query Compiler dazu bringt, verbesserte execution plans zu erzeugen. Weitere Vorteile sind:. table partitioning ermöglicht die Aufteilung einer Tabelle in mehrere data ranges, die einem oder mehreren physikalischen Objekten innerhalb einer database logical partition gespeichert werden können. Das Ziel des table partitioning ist es, Daten logisch so zu organisieren, dass Zugriff und roll-in / roll-out optimal vonstatten gehen kann. Weitere Attribute und features des table partitioning sind noch: Jede range kann in einem eigenen table space abgelegt werden Ranges können unabhängig voneinander durchsucht werden Performance für bestimmte BI-orientierte Queries wird durch partition elimination verbessert Neue ALTER ATTACH/DETACH Statements für einfachere roll-in / roll-out Vorgänge SET INTEGRITY gibt es jetzt online (mit read/write Zugriff auf ältere Daten) Für neue ranges, können ADD plus LOAD Operationen mit ATTACH plus SET INTEGRITY verwendet werden 39

40 DB2 for LUW Index-Design Table und Indexpartitioning Hier ein Beispiel zur Definition einer partitioned table : CREATE TABLE SALES(SALE_DATE DATE, CUSTOMER INT, ) PARTITION BY RANGE(SALE_DATE) (STARTING 1/1/2006 ENDING 3/31/2008, STARTING 4/1/2006 ENDING 6/30/2008, STARTING 7/1/2006 ENDING 9/30/2008, STARTING 10/1/2006 ENDING 12/31/2012 ); Dieses Statement erzeugt vier Tabellenobjekte, jedes mit einer range of data in einem eigenen DS: Hier die best practises für table partitioning : table (range) partitioning wird sinnvoll, wenn data ranges fachlich unterstützt getrennt verarbeitet werden können. range-partitioning Perioden können roll-in / roll-out optimal unterstützen; z.b Partitionierung über Monat kann bei monatlich periodisch verarbeiteten Daten sinnvoll sein. Partitionen auf DATE Spalten können bevorzugt genutzt werden. Roll-in / roll-out Scenarios sind häufig auf Datumsdaten aufgesetzt. 40

41 DB2 for LUW Index-Design Table und Indexpartitioning Man begrenze die Anzahl ranges. Jede range stellt ein Tabellenobjekt dar - Minimum zwei extents. Man vermeide Designs mit exzessiven Partitionzahlen. Ein Anhaltspunkt sei ca. 50MB Daten pro range (einige Gigabytes pro range ist am Besten). Die Größe der ranges sollte zur rollout Größe passen. Partition elimination verbessert die SQL workload Performance. Sie ist eine interne Strategie des Query Compilers. Der Query Compiler beschließt automatisch, ob table partitioning dafür verwendet werden kann. Werden neue ranges hinzugefügt, dann ist ADD table partition mit LOAD Operation oft schneller als der ATTACH einer Partition mit folgender SET INTEGRITY Operation Das LOAD Utility besitzt eine Option mit der man IX inkrementell pflegen kann und mit der nur eine log row pro Ereignis geschrfieben wird ohne Rücksicht darauf, wieviele rows in eine table INSERTed werden. Obwohl dasload Utility concurrent read access auf ältere Daten zuläßt, müssen die Queries gedrained werden. Man sollte table partitions in separate Tablespaces legen, auch um backup und recovery zu optimieren. Table partitions können pro TS backed up und restored werden Platzieren Sie global indexes, die sehr groß werden können, in einem eigenen table space. Dies kann die elapsed time des BACKUP Utility positiv beeinflussen(der index table space kann viel größer werden, als die data table spaces ). Man sollte das clustering der Daten sicherstellen, indem man den range-partitioning key zur führenden Spalte in einem clustered index (kein MDC) macht. Die Daten werden nicht angemessen geclustered, wenn der clustered index nicht vom partition key angeführt wird. Beispiel: PARTITION BY RANGE (Month, Region) CREATE INDEX (Month, Region, Department) CLUSTER 41

42 DB2 for LUW Index-Design Table und Indexpartitioning Man nutze page-level sampling, um die RUNSTATS Zeiten zu senken. Eine sampling rate von 20% bis 30% führen zu qualitativ guten Statistiken mit einer optimalen Performance. Ein Index kann mit partitioning columns einer Tabelle korrelieren oder nicht - Partitioning index (PI) - Secondary index Ein Index kann physisch partitioned sein oder nicht - Partitioned - Non-partitioned Clustering Index: Jeder beliebige Index kann der clustering index sein!! Der clustering index kann unique / non-unique sein 42

43 DB2 for LUW Index-Design Table und Indexpartitioning Secondary IX: jeder Index der kein partitioning index ist partitioned index : jeder Index, der ein PARTITIONED Schlüsselwort im CREATE INDEX Statement besitzt Secondary indexes Indexes können auf Tabellen aus unterschiedlichen Gründen definiert werden: Eindeutigkeit von Spalten, data clustering, aber meistens zur Unterstützung von access paths oder referential constraints. 43

44 DB2 for LUW Index-Design Table und Indexpartitioning Query Performance Charakteristiken von DPSIs query parallelism möglich Queries mit ausschliesslichen Prädikaten auf secondary index columns müssen möglicherweise alle Partitions scannen DB2 versucht ein sogen. partition pruning -- Die Applikation muss explizit die partitioning key predicates angeben, um partition pruning anzustossen, falls ein DPSI existiert Gut für Queries mit Prädikaten auf partitioning columns plus secondary index columns Secondary indexes NPSIs DPSIs pro: favorisieren einer sequential query performance con: partition-level queries oder Utility Operationen pro: favorisieren von partition-level queries oder utility operations con: sequential query performance, und gut für partition -Parallelverarbeitung DPSIs erlauben query parallelism und werden vom Optimizer für Queries mit Prädikaten auf partitioning columns plus Prädikaten auf secondary index columns ausgewählt. 44

45 DB2 for LUW Index-Design Überlegungen zur Indizierung Predicates Gibt es Prädikate auf partitioning columns? Clustering welches sind die "large" Processes gegen die Daten? ORDER BY wie sieht die gewünschte Sequenz aus? DPSIs sind non-unique - Query muss möglicherweise alle parts scannen, falls es keine Prädikate auf partitioning column(s) gibt Häufigkeit der Index maintenance (INSERT / UPDATE / DELETE / utilities) gegen DPSI / NPSI Ist die # parts auf der Tabelle eine Überlegung für DPSI / NPSI wert? (z. B parts ) (Online) REORG - Häufigkeit? 45

46 DB2 for LUW Index-Design Überlegungen zur Indizierung Non-Unique Indexes und Vorkommenhäufigkeiten Das Problem von "doppelten" Indexwerten ist ihre Vorkommens-häufigkeit: Sie kommen eben meist nicht nur doppelt vor, sondern mehrfach. Dies gilt besonders bei Informationen wie "Status", "xxxx-typ", "yyyy- Art usw. DB2 aktualisiert diese "duplicates" bei jedem INSERT und DELETE über Einbzw. Austräge, d.h. die Selektivtät dieser Werte verändert sich bei dynamischen Tabellen ständig. Beim Typ-2 Index ordnet DB2 die "Duplicates" aufsteigend nach RID, und macht damit "binary search"-algorithmen möglich. "Duplicates" werden beim DELETE nur logisch gelöscht ("leaf page" bleibt strukturell erhalten). 46

47 DB2 for LUW Index-Design Überlegungen zur Indizierung Non-Unique Indexes und Vorkommenhäufigkeiten Beim Typ-2 Index ordnet DB2 die "Duplicates" aufsteigend nach RID, und macht damit "binary search"-algorithmen möglich. "Duplicates" werden beim DELETE nur logisch gelöscht ("leaf page" bleibt strukturell erhalten). Vorteile dieser Technik: 1. Vermeiden des "nicht selektiven" Index auf Tabelle "A". 2. Abhängig von der Länge des PK + der Spalte "Status" spart man mehr oder weniger Plattenplatz. 3. Der Index auf die neue Tabelle hat weniger Ebenen als der Index auf eine Tabelle "A" Nachteile: 1. Die Frage nach den "nicht-typischen" Statusinformnationen erfordert einen JOIN 2. Die Applikation muß die Datenkonsistenz in beiden Tabellen sicherstellen, wenn sich der Status ändert. 47

48 DB2 for LUW Index-Design Überlegungen zur Indizierung Non-Unique Indexes und Vorkommenhäufigkeiten In der Praxis wird man, wenn die Daten mit dem typischen Wert (Status = "bezahlt") gelesen werden, folgenden Weg gehen: Man ordnet der Spalte "Status" eine zusätzliche Spalte hinzu, nicht zuletzt, um innerhalb eines Cursors repositionieren zu können. Dies ist unabhängig vom genutzten Indextyp. Je weniger die "Duplicates" nicht-typischen Indexwerten sind, umso eher ist es zu empfehlen, eine eigene Tabelle mit den nicht-typischen Werten als Daten und dem PK der "Haupttabelle" als "primary key" zu definieren. Um die Daten mit einem anderen Status als "bezahlt" wiederzufinden muß man hier in beiden Tabellen suchen: JOIN über den Primary Key und die Spalte "Status". Vorteile dieser Technik: 1. Die "Status-Only"-Tabellen bestehen aus der Key-Spalte und einem (eindeutigen) Index darauf. 2. Für die Statustabellen gibt es als Prädikat nur die JOIN-Bedingung 3. Plattenplatz wird eingespart 4. Die Status-Spalte muß nicht repliziert werden 5. Die Indizes auf den neuen Tabellen haben weniger "pages" und "levels" 48

49 DB2 for LUW Index-Design Überlegungen zur Indizierung Unique Indexes Man kann Indizes definieren, die Eindeutigkeit für alle Werte sicherstellen außer für NULL-Werte. Erlaubt sind KEINE Mehrfachvorkommen von NULL-Werten. Indizes, die eine große Anzahl "Duplicates" mit NULL-Werten erwarten, können nicht als UNIQUE definiert werden. UNIQUE sichert die Tabelle gegen zwei oder mehr rows mit gleichen Schlüsselwerten ab. Kann ein Schlüsselwert NULL Werte enthalten, so wird die Bedeutung von derselbe Wert angenommen INCLUDE-Klausel Beispiel: Optimierung von Abfragen auf die KFZ Tabelle mit Vertrags-/Kundennr., Kasko: VOR V9 CREATE UNIQUE INDEX I1 ON emp (EMPNO); CREATE INDEX I2 ON emp (EMPNO, DEPTNO, NAME); Optimierung in V9 CREATE UNIQUE INDEX I1 ON emp (EMPNO) INCLUDE (DEPTNO, NAME) COLLECT SAMPLED DETAILED STATISTICS SELECT EMPNO, DEPTNO, NAME FROM emp WHERE EMPNO >= 4711 AND DEPTNO LIKE M% ORDER BY DEPTNO, NAME 49

50 DB2 for LUW Index-Design Überlegungen zur Indizierung Indexes zur Vermeidung von SORT-Vorgängen Indizes können dazu benutzt werden, um Sort-Vorgänge in SQL-Statements zu verhindern. GROUP BY, ORDER BY, DISTINCT und JOIN-Verarbeitung kann von Indizes profitieren. GROUP BY braucht hierfür alle Spalten im Index und dort in der entsprechenden Reihenfolge. Ob aber der Index dann aufsteigend oder absteigend geordnet ist, ist vollkommen irrelevant: GROUP BY setzt keinerlei Sequenzen voraus. Die Vermeidung von ORDER BY erfordert wohl die meisten Voraussetzungen: 1. Die Sequenz der Spalten im Index muß identisch sein mit ihrer Folge im ORDER BY - Statement. 2. Das Prädikat "aufsteigend" / "absteigend" sollte ebenfalls auf die ORDER BY Spezifikation passen. Generell aber ist der "filter factor" der Prädikate, der auf Indizes abgebildet werden kann wichtiger als das Vermeiden von Sort-Vorgängen. Statistiken spielen immer eine Rolle (RUNSTATS): Detailed: ON COLUMNS ON KEY COLUMNS NUM_FREQVALUES NUM_QUANTILES WITH DISTRIBUTION CLUSTERFACTOR und PAGE_FETCH_PAIRS statistics werden gesammelt man kann eine Liste von Spalten angeben, für die Statistiken gesammelt werden sollen. man sammelt Statistiken für alle IX Spalten einer Tabelle. man sammelt die Vorkommenshäufigkeiten von Werten. man sammelt Informationen von Verteilungsquantilen sowohl basic statistics, als auch distribution statistics werden gesammelt RUNSTATS ON TABLE db2user.employee AND SAMPLED DETAILED INDEXES ALL 50

51 DB2 for LUW Index-Design Überlegungen zur Indizierung (Zusammenfassung) Frage: Ein multicolumn index ODER mehrere Indexes??? 1. Nutzung durch die Prädikate, d.h. Die Art, wie die Prozesse ihre Prädikate formulieren, kann als Hauptleitlinie für die Definition von Indizes gesehen werden. Die Kombination der Prädikate, die Art der kritischen Prozesse (1 bis 3 skaliert), und die verwendeten logischen Operatoren, die die Prädikatsaussagen miteinander verbinden, bestimmen das Index-Design. 2. Die Kardinalität der indizierten Spalten ist ein wichtiger Faktor, wenn man mehrere Spalten in einem Index zusammenfassen will. Die eingebauten Grenzwerte in einem "multiple index scan können den Zugriff schnell zu einem "tablespace scan" werden lassen. Um dies zu vermeiden, muß man die Anzahl der qualifizierenden RID's begrenzen, d.h. die Filter der Index-Prädikate müssen passen. 3. Die Effizienz des Zugriffspfads hängt von mehreren Faktoren ab. Zunächst hat man in der Hauptsache zwei Möglichkeiten: a) "Multiple Index" Zugriff: Mehrere Indizes in einem SQL-Statement können nur aufgrund der Entscheidung des Optimizers als gemeinsamer Pfad genutzt werden. Es wird immer "list prefetch genutzt, wenn man eine bestimmte Menge RID's und nicht die aktuellen Spaltenwerte zurückerhalten will. Dieser hat drei Nebeneffekte: es gibt keinen "index-only" - Zugriff alle qualifizierten Zeilen müssen aus dem Index gelesen werden, bevor die erste Zeile ans Programm/den User übergeben werden kann "index screening" kann nicht genutzt werden b) "Single Index" Zugriff: Ein einzeln genutzter Index kann ein effizienter Zugriffspfad beim Filtern von zutreffenden Kriterien und Prädikaten sein. Aber: Es wird schwierig EINEN Index zu entwerfen, wenn eine Hälfte der SQL-Prädikate auf der "Spalte X" und die andere Hälfte auf der "Spalte Y" basieren. In 50% der Fälle wird man einen "non-matching index scan" wenn nicht einen "tablespace scan" auslösen. Das bedeutet: "single index"-zugriffe sind nur effizient, wenn der größte Teil der SQL-Statements Statements dieselben passenden Prädikate benutzen. 51

52 DB2 for LUW Index-Design Überlegungen zur Indizierung (Zusammenfassung) Frage: Ein multicolumn index ODER mehrere Indexes??? Die richtige Anordnung der Spalten im Index kann helfen, Sorts zu vermeiden, INSERT- Vorgänge zu unterstützen, falls der IX "clustering ist und über Prädikate die Chancen auf "matching index" Zugriffe zu erhöhen. 1. Vermeiden von Sortiervorgängen: d.h.der Index muß genau der Sequenz der sortierten Spalten entsprechen. Man hat keine Option, das Design anders zu gestalten, außer das SQL-Statement ändert sich. 2. Minimieren der Reorganisationshäufigkeit: Die Spaltenfolge und die INSERT-Anforderungen ("home page"-definition) bestimmen die Datenstreuung. Will man dies verhindern, so ist man an eine bestimmte Spaltenfolge im Index gebunden. Hierbei gibt es Interessenkonflikte zwischen den ge-wünschten INSERT-Sequenzen und den Filterfaktoren in den Queries bzw. der Anzahl passender Spalten. Die Auswirkung auf den Zugriffspfad ist hier stets der wichtigste Aspekt. Eine Lösung kann heißen: Höhere REORG-Frequenz oder Anpassen der "free space"-parameter im DB2-Objekt. 3. Maximieren der Anzahl von "matching columns": Optimiert wird die Nutzung von Prädikaten, wenn möglichst viele Spalten, die mit einem "=" Operator angegeben sind, als erste Spalten im Index vorkommen. Sollten mehrere Spalten gleichzeitig in den Queries mit einem "=" - Operator angegeben werden, so sollte die Spalte mit der höchsten Kardinalität am Anfang eines "compound index" stehen. Werden nicht alle Indexspalten im Prädikat genutzt, dann ist es wichtig die Spalten mit dem höchsten Filterfaktor an den Anfang des Index zu stellen, um DB2 bei der Pfad-Auswahl zu unterstützen. 4. Einfluss von "correlated index"-spalten: Früher konnte der Optimizer sogenannte "correlated columns" im Index nicht erkennen. So konnte die Auswahl des Zugriffspfads zu erheblichen Performance- Verlusten führen. Jetzt kann das Utility RUNSTATS die Statistiken über eine Menge von im Index zusammengefassten Spalten sammeln. Dies ermöglicht dem Optimizer eine genauere Bestimmung der Filterfaktoren, insbesondere für alle "=" - gesteuerten Operatoren 52

53 DB2 for LUW Index-Design Überlegungen zur Indizierung (Zusammenfassung) Frage: Ein multicolumn index ODER mehrere Indexes??? Folgende Query-Typen profitieren von diesen neuen Statistiken: Prädikate mit "matching columns" in einem Index dazu muß der Index mindestens aus drei Spalten bestehen, z.b. hat ein Index 4 Spalten, kann man neben den FIRSTKEYCARD-Informationen ( nur für die 1. Spalte ) und den FULLKEYCARD-Informationen ( für alle 4 Spalten ) auch Statistiken für die ersten zwei bzw. die ersten drei Spalten nutzen. Queries mit Prädikaten, für die MATCHCOLS = 2 oder MATCHCOLS = 3 ist, profitieren von diesen zusätzlichen Informationen FIRSTKEYCARD BIGINT FIRST2KEYCARD BIGINT FIRST3KEYCARD BIGINT FIRST4KEYCARD BIGINT FULLKEYCARD BIGINT Prädikate für "index screening RUNSTATS sammelt keine Statistiken über "index subsets". Beispiel: Besteht ein Index aus 4 Spalten, so hat das Utility RUNSTATS keine Informationen über die zweite und dritte Spalte. Aber: Man kann Informationen über diese "subsets" in der Katalogtabelle SYSCOLDIST eintragen. Der Optimizer nutzt diese Daten dann zur Pfadbestimmung. 53

54 DB2 for LUW Index-Design Index Design Matrix Welche IX sollten angelegt werden? Ein guter Ansatz ohne Berücksichtigung von cardinality und frequency Information: CREATE INDEX IX1 on TB (Col3, Col1) allow reverse scans; CREATE INDEX IX2 on TB (Col3, Col5, Col2) allow reverse scans; CREATE INDEX IX3 on TB (Col3, Col2, Col6) allow reverse scans CLUSTER; CREATE INDEX IX4 on TB (Col3, Col6, Col8, Col9) allow reverse scans; 54

55 DB2 for LUW Index-Design Überlegungen zur Indizierung (Zusammenfassung) Die Reihenfolge der Spalten Im Index - Beispiele Beispiel 1 SELECT * FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) AND A.STYLE = ADULT MENS T-SHIRT CREATE INDEX X1_TABLE1 ON TABLE1 (COLOR, SIZE, STYLE) ( keys in beliebiger Reihenfolge ABER die selektivste Spalte zuerst) Beispiel 2 SELECT * FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) AND A.STYLE = ADULT MENS T-SHIRT AND A.INVENTORY > 100 CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE, STYLE, INVENTORY) ( keys in beliebiger Reihenfolge ABER die selektivste Spalte zuerst und das non-equal Prädikat zuletzt) 55

56 DB2 for LUW Index-Design Überlegungen zur Indizierung (Zusammenfassung) Die Reihenfolge der Spalten Im Index - Beispiele Beispiel 3 SELECT * FROM TABLE1 A, TABLE2 B WHERE A.KEY = B.KEY AND A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) AND A.STYLE = ADULT MENS T-SHIRT AND A.INVENTORY > 100 CREATE INDEX X1_TABLE1 ON TABLE1 (COLOR, SIZE, STYLE, KEY, INVENTORY) ( keys in beliebiger Reihenfolge ABER die selektivste Spalte zuerst und das non-equal Prädikat zuletzt) CREATE INDEX X1_TABLE2 ON TABLE2 (KEY) Beispiel 4 SELECT * FROM TABLE1 A, TABLE2 B WHERE A.KEY_COL1 = B.KEY_COL2 AND A.COLOR IN ( BLUE, GREEN, RED ) CREATE INDEX X1_TABLE1 ON TABLE1 (COLOR, KEY_COL1) CREATE INDEX X1_TABLE2 ON TABLE2 (KEY_COL2) (Unter Vorwegnahme des key row positioning und des multi-key join (MX)) 56

57 DB2 for LUW Index-Design Überlegungen zur Indizierung (Zusammenfassung) Die Reihenfolge der Spalten Im Index - Beispiele Beispiel 5 SELECT A.STORE, A.STYLE, A.SIZE, A.COLOR, SUM(A.QUANTITY_SOLD) FROM TABLE1 A, TABLE2 B WHERE A.KEY = B.KEY AND A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) AND A.STYLE = ADULT MENS T-SHIRT GROUP BY A.STORE, A.STYLE, A.SIZE, A.COLOR CREATE INDEX X1_TABLE1 ON TABLE1 (COLOR, SIZE, STYLE, KEY); ( keys in beliebiger Reihenfolge ABER die selektivste Spalte zuerst) CREATE INDEX X2_TABLE1 ON TABLE1 (STORE, STYLE, SIZE, COLOR) ( keys sollten in dieser Reihenfolge sein, um die grouping Anweisung zu unterstützen) CREATE INDEX X1_TABLE2 ON TABLE2 (KEY) Beispiel 6 SELECT FROM GROUP A.COLOR, A.SIZE, SUM(A.SALES), SUM(A.QUANTITY) TABLE1 A BY A.COLOR, A.SIZE CREATE INDEX X1_TABLE1 ON TABLE1 (COLOR, SIZE) (Unter Vorwegnahme des index grouping ) Oder CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE, SALES, QUANTITY) (Unter Vorwegnahme des index grouping und des index only access mit allen Spalten im IX) 57

58 DB2 for LUW Index-Design Überlegungen zur Indizierung (Zusammenfassung) Die Reihenfolge der Spalten Im Index - Beispiele Beispiel 5 SELECT A.STORE, A.STYLE, A.SIZE, A.COLOR, SUM(A.QUANTITY_SOLD) FROM TABLE1 A, TABLE2 B WHERE A.KEY = B.KEY AND A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) AND A.STYLE = ADULT MENS T-SHIRT GROUP BY A.STORE, A.STYLE, A.SIZE, A.COLOR CREATE INDEX X1_TABLE1 ON TABLE1 (COLOR, SIZE, STYLE, KEY); ( keys in beliebiger Reihenfolge ABER die selektivste Spalte zuerst) CREATE INDEX X2_TABLE1 ON TABLE1 (STORE, STYLE, SIZE, COLOR) ( keys sollten in dieser Reihenfolge sein, um die grouping Anweisung zu unterstützen) CREATE INDEX X1_TABLE2 ON TABLE2 (KEY) Beispiel 6 SELECT FROM GROUP A.COLOR, A.SIZE, SUM(A.SALES), SUM(A.QUANTITY) TABLE1 A BY A.COLOR, A.SIZE CREATE INDEX X1_TABLE1 ON TABLE1 (COLOR, SIZE) (Unter Vorwegnahme des index grouping ) Oder CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE, SALES, QUANTITY) (Unter Vorwegnahme des index grouping und des index only access mit allen Spalten im IX) 58

59 DB2 for LUW Index-Design Weitere Tips zur Indizierung 1. CLUSTER: das richtige clustering kann die CPU Verbräuche um bis zu 50% senken! (1) Man suche die Tabelle mit den höchsten Leseraten auf den rows (2) Dazu suche man die SQL s, die die I/O Last auf dieser Tabelle auslösen (3) Aus diesen SQL s die Statement(s) mit der höchsten aggregierten SORT-Zeit (4) Mit dem Design Advisor / MDC Advice sollte mna dann die Kosten als input workload abschätzen lassen bzw. die ORDER BY/GROUP BY Klauseln untersuchen (5) Dann: Implementieren eines MDC, oder 1 CLUSTER INDEX 2. Index Design Checkliste (1) Indexes mit Cardinality = 1 sind das Todesurteil jeder Performance. Also keine IX nach dem Motto: just in case (2) Indexes mit ungleicher Verteilung sind teuer für Insert, Update, Delete (3) Redundante Indexes sind teuer in der Verwaltung, verbrasuchen Plattenplatz und bieten keinen Mehrwert für DB2 also DROP! IX on C1, C2 <<- Redundant Index IX on C1, C2, C4 (4) Man nutze composite indexes, um single column indexes los zu nwerden (5) Bei den composite indexes stehen die am häufigsten genutzten Spalten am Anfang(= predicate ). (6) Clustering Indexes reduzieren Sort & CPU Kosten (7) CREATE INDEX auch auf kleine TABLES, um der Gefahr hoher CPU & I/O Kosten vorzubeugen.. 59

60 DB2 for LUW Index-Design 3. Index Forget Me Not Options (1) Erlauben Sie REVERSE SCANS (neu seit 9.5 default ) (2) CLUSTER ein cluster IX pro Tabelle wegen SORT, prefetch etc. Please! (3) PCTFREE 10 N: wenn > 10, sind es nur 10% maximal auf den non-leaf pages (4) LEVEL2 PCTFREE N gibt an, wieviel % auf allen index level 2 Pages als free space zur Anwendung kommt, wenn der IX aufgebaut wird (0 bis 99). Ist LEVEL2 PCTFREE nicht gesetzt, so wird ein Minimum von10% bzw, PCTFREE Größe für alle non-leaf pages angenommen. (5) MINPCTUSED N (gesetzt auf < 50, idealerweise 25-33) Online merge für nahe gelegen leaf pages Beeinflußt Update & Delete Performance (geringfügig) Merge erfolgt auf Type 2 IX, wenn die Tabelle im exclusive mode gesperrt ist, ansonsten pseudo deleted Wichtig: Online Reorg der Indexe CLEANUP ONLY ALL (6) PAGE SPLIT SYMMETRIC (DEFAULT) HIGH genutzt für ascending index Werte LOW sinnvoll für descending index Werte (7) COLLECT [ SAMPLED DETAILED ] STATISTICS erfolgt sofort anstatt eines späteren RUNSTATS (8) Ein expliziter Index für den PK. DB2 DBM indiziert den PK automatisch, aber mit einem systemgenerated Namen. Dieser Name ist für die DBA nicht einfach zu administrieren. (9) Das db2pd Kommando, zeigt an, wie häufig Indexes verwendet wurden: Beispiel: db2pd -db MY_DATABASE -tcbstats index Die Indexe werden über die IID referenziert und können damit auf die SYSIBM.SYSINDEXES's IID verknüpft werden 60

61 DB2 for LUW Index-Design CREATE INDEX als Template Drucken und als Referenz aufheben! CREATE [UNIQUE] INDEX schema.c1c2c4c8 on schema.tablename ( C1 ASC, C2 ASC, C4 ASC, C8 ASC ) [INCLUDE (C9, C11)] [CLUSTER] PCTFREE 15 LEVEL2 PCTFREE 15 MINPCTUSED 40 ALLOW REVERSE SCANS PAGE SPLIT SYMMETRIC [ or HIGH LOW ] COLLECT DETAILED STATISTICS 61

62 DB2 for LUW Index-Design 62

63 DB2 for LUW Design und Objektdefinition Bauen Sie ihre Informationsumgebung nach NUTZENGESICHTSPUNKTEN auf... 63

64 DB2 for LUW SQL Tuning & Monitoring Kapitelinhalt Best Practices in einem DWH Umfeld BP - Database Design BP Überlegungen zu Applikationen BP Performance Layer BP - Configuration and Operations DB Design und Objektdefinitionen Denormalisierungsmuster Physisches Design und Datentypen bei DB2 Index Designmuster SQL Tuning Query Design Optimization class und Optimizer SQL EXPLAINs SQL runtime optimization (MQT s, temp Tables, SORTs) Beeinflussen des access plan bei DB2 Zugriffsarten bei DB2 Regeln zu Tabellen- und Index-Design 64

65 DB2 for LUW SQL Tuning (Query Design) SQL Tuning Der Erfolg von DB-Applikationssystemen hängt von verschiedenen Faktoren ab: Technologie Lösungsarchitektur Gelöste Probleme Benutzererwartungen Letztendlich muss eine erfolgreiche Implemetierung hoch-performant und anpassungsfähig sein. Bei sogen. mission critical applications, wie Telekom- und Finanzanwendungen ist die real-time Performance sehr wichtig. In einer Applikation, die mit einem back-end database system interagiert, ist die SQL Performance in Bezug auf die Antwortzeiten entscheidend. Das Tuning der SQL Performance wird notwendig aus verschiedenen Gründen: komplexe physische Modelle, dynamic workload, Query Design, System Performance, Datenbankimplementierung, ständige Änderung des data environment und harte User-Anforderungen Query design Ein gutes Design der application queries muss einhergehen mit einem realistischen Logischen Datenmodell(LDM), das unter Performance-Gesichtspunkten des genutzten DBMS in das Physical Data Model (PDM) transformiert wurde. Dies sind die Voraussetzungen für die Formulierung einer effizienten Query. Dabei gibt es mehrere Wege, dieselbe Query zu konstruieren oder von einem Gerator erzeugen zu lassen - manche Varianten sind weniger effizient oder mehr oder weniger redundant. 65

66 DB2 for LUW SQL Tuning (Query Design) Query design Die Konstruktion einer Query basiert auf den SQL Standards und kann so angepasst werden, dass alle möglichen DBMS Funktionen ausgenutzt werden. Der DB2 Optimizer kann auch einen Query Rewrite, falls es Wege gibt, die Query semantisch gleich, aber für den Optimizer effizienter und mit mehreren Möglichkeiten ausgestattet zu formulieren. Der DB2 cost-based optimizer nutzt eine rule-based engine, um Queries umzuschreiben. Eine einfache Regel für guter Query Design ist das Vermeiden von Redundanzen. Beispiel: Die klassische CUSTOMER Tabelle beinhaltet einen custkey und eine Spalte NAME Der custkey ist für jeden Kunden eindeutig und so gibt es genau eine row pro custkey in der Tabelle CUSTOMER. Um nun die einzelnen Kunden aufzulisten formulieren wir folgende Query: SELECT DISTINCT custkey, name FROM customer Diese Query zeigt keine Redundanzen auf unbd muss wie folgt geschrieben werden: SELECT custkey, name FROM customer 66

67 DB2 for LUW SQL Tuning (Query Design)... Alles eine Frage der Formulierung und Mengendefinition... to the airport please 67

68 DB2 for LUW SQL Tuning (Query Design) Tuning von SQL-Queries(Grundlagen) Das Tuning von SQL Queries kann folgende Aktivitäten erfordern: 1. Hinzufügen und/oder Ändern von Indizes 2. Anpassen der Spaltengrössen in Tabellen / im Programm 3. Neu-/Umschreiben von Queries Insbesondere Queries, die Bestandteil von angepasstem Code, generierten Abfragen und benutzerverfasste Queries bedürfen häufig eines Tuning. Seit DB2 Version 8 sind es bis zu 225 Basistabellen, die in einer einzigen "joined expression" stehen können. Neue features bestehender oder neuer Funktionen in neuen Releases von DB2 werden seltenst in alten Queries genutzt und eingebaut, obwohl DB2 daraus Vorteile ziehen könnte. Nur allzu wenig wird z.b. die Verwendungsmöglichkeit von CASE Konstrukten beachtet. Mit CASE kann man in SQL UNION Konstrukte minimieren/eliminieren bzw. restrukturieren. In einem 5-fachen UNION Block beispielsweise kann alleine über den Weg von CASE- Formulierungen eine Reduzierung von elapsed time und CPU-Zeit von bis zu 80% erzielt werden. 68

69 DB2 for LUW SQL Tuning (Query Design) Tuning von SQL-Queries(Grundlagen) Beispiel: SELECT CLERK, CUSTKEY, 'CURRENT' AS STATUS, ORDERPRIORITY FROM TBORDER WHERE ORDERSTATUS = '0' UNION ALL SELECT CLERK, CUSTKEY, 'OVER 30' AS STATUS, ORDERPRIORITY FROM TBORDER WHERE ORDERSTATUS = '1' UNION ALL SELECT CLERK, CUSTKEY, 'OVER 30' AS STATUS, ORDERPRIORITY FROM TBORDER WHERE ORDERSTATUS = '2' ; SELECT CLERK, CUSTKEY, CASE WHEN ORDERSTATUS = '0' THEN 'CURRENT' WHEN ORDERSTATUS = '1' THEN 'OVER 30' WHEN ORDERSTATUS = '2' THEN 'OVER 60' END AS STATUS, ORDERPRIORITY FROM TBORDER ; 69

70 DB2 for LUW SQL Tuning (Query Design) Wo kann ich gute und schlechte SQL-Queries erkennen? Die EXPLAIN_Tables Der EXPLAIN gibt Auskunft über Index-Benutzung Zugriffsmodus SORT-Alghorithmen Erzeugen von temporären (Zwischen-)Tabellen Reihenfolge der Tabellen-/Indexverarbeitung EXPLAIN hilft potentielle Performance-Engpässe zu erkennen und legt entsprechende Informationen in den EXPLAIN-Tabellen ab Kosten werden pro Schritt und insgesamt offengelegt a) die Kosten werden aufgrund der verfügbaren Informationen ermittelt b) die Kosten werden geschätzt, da Informationen fehlen Geschätzte Prozessorkosten in Millisekunden 70

71 DB2 for LUW SQL Tuning (Query Design) Umformulieren von Queries 1. WARUM Mehr Zugriffspfade zur Auswahl für den Optimizer Kostenmodelle für die Aufwandschätzung und die Auswahl des/der effizientesten Modells(e) 2. Transformationsmöglichkeiten Prädikate Joins View / table expressions Verteilung und pruning (Erkennen und Weglassen nicht zielführender Äste in einem Optimizing-Tree ) 71

72 DB2 for LUW SQL Tuning (Query Design) Einsatzspektrum und Grenzen von SQL Generell gilt: Zunächst sollte die gesamte SQL-Funktionalität genutzt werden... Bei Performance-Problemen wird Als erstes nach DB2- bzw. SQL-Varianten gesucht Dann erst eine programmtechnische Lösung angestrebt, bei der zu prüfen ist, ob wirklich ein positiver Effekt gegenüber der SQL-Lösung eintritt... Make it Make it WORK Make it WORK FAST... 72

73 DB2 for LUW Der access path Kapitelinhalt Best Practices in einem DWH Umfeld BP - Database Design BP Überlegungen zu Applikationen BP Performance Layer BP - Configuration and Operations DB Design und Objektdefinitionen Denormalisierungsmuster Physisches Design und Datentypen bei DB2 Index Designmuster SQL Tuning Query Design Optimization class und Optimizer SQL EXPLAINs SQL runtime optimization (MQT s, temp Tables, SORTs) Beeinflussen des access plan bei DB2 Zugriffsarten bei DB2 Regeln zu Tabellen- und Index-Design 73

74 DB2 for LUW Der access path Die Query-Evaluation bei DB2 select * from dept d, emp e where d.budget > // P1: stage 1 and d.name like %Opt% // P2: stage 2 and d.id = e.dept // P3: matching and e.salary > // P4: matching and e.bonus < 7000 // P5: screening (1) Matching predicates: Verkürzen der index search range (2) Screening predicates: Filtern der unqualifizierten IX keys (3) Stage-1 predicates: Filtern der unqualifizierten Sätze im Bufferpool (4) Stage-2 predicates: Filtern der unqualifizierten Sätze im private pool (5) RSCAN: Holen der einzelnen Sätze einer Tabelle (6) ISCAN: Holen der Sätze mit qualifizierter RID (record id) (7) NL Join: Einmaliges Durchsuchen der inner table pro outer record und Rückgabe der passenden Sätze. 74

75 DB2 for LUW Der access path 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. 75

76 DB2 for LUW Der access path Die Optimierung Der DB2 Optimierer analysiert das SQL-Statement, interpretiert bestimmte Statistik-Informationen aus den Katalog-Tabellen und ermittelt die möglichen Zugriffspfade und I/O-Zugriffstypen zu den Daten. Entscheidungsfaktoren des Optimierers I/O und Status dertables Verfügbare IX SQL-Query CPU-Nutzung Statistik-Daten IX-Aufbau BP-Auswahl Anzahl Zeilen Unique Typ(einfach, (CARDF) komplex) CPU-Modell/CPU s Anzahl Pages Clustered SELECT (NPAGES) (CLUSTERRATIO) (Auswahl-Liste) % genutzte Pages Index Keys Prädikate und (PCTPAGES/FPAGES) (single, composite) Verarbeitungsebene mehrere Indizes Klauseln(ORDER BY, GROUP BY) 76

77 DB2 for LUW Der access path Die 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: 1. Simple oder Compound ein mit AND bzw. OR verknüpftes Prädikat ist "compound" ansonsten ist es "simple 2. 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 77

78 DB2 for LUW Der access path Die Prädikate und Prädikatkategorien 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-Nutzung über einen Multi-IX Access 78

79 DB2 for LUW Der access path Die Prädikate und Prädikatverarbeitung Indexscreening STAGE1 oder STAGE2 Boolean Term (BT) der DM kann das Suchargument innerhalb des Index filtern. Die Suche betrifft weitere Indexspalten, die nicht im Rahmen des Matching Index Scan nutzbar sind. Der DM liest zunächst nur Index-Pages und leitet daraus die erforderlichen Datenpage-Zugriffe ab. ein Prädikat, das direkt mit dem Einlesen der Daten geprüft werden kann ist STAGE1 ansonsten STAGE2 ein BT kann ein "simple" oder "compound" Prädikat sein. Der Optimizer versucht ggf. einen "Multiple index access" Häufig spricht man von STAGE1 und STAGE2-Prädikaten, da diese Angabe die Verarbeitungseffizienz des Prädikats beschreiben kann. Entscheidend ist also die Verarbeitungsfolge der Prädikate im RDS. WAS bedeutet das bei DB2? 1. welcher Art das Prädikat ist, hängt davon ab, WANN es im RDS wirksam und von DB2 bearbeitet werden kann 2. grundsätzlich ist ein Prädikat umso besser (für die Performance), je eher es im RDS bearbeitet werden kann. 3. "non-sargable"-prädikate führen in den meisten Fällen zu TS-Scan's, wenn sie die einzigen Prädikate einer SQL-Formulierung darstellen. 79

80 DB2 for LUW Der access path Die Filterfaktoren(FF) Filterfaktoren(FF) werden aufgrund der semantischen Anforderungen mit diversen Berechnungsformeln ermittelt. Werden mehrere Spalten im Prädikat angesprochen, wird der FF über Multiplikation ermittelt Beispiel: IX-Spalten: abt_nr, nachname, einst_dat FULLKEYCARD 2500 unterschiedliche Werte im IX FIRSTKEXCARD 50 unterschiedliche Abteilungsnummern COLCARD von nachname 20 verschiedene Nachnamen CARD Tabellenzeilen 1) WHERE abt_nr = A00 FF = 1/FIRSTKEYCARD = 1/50 = 0,02 2) WHERE abt_nr = A00 FF = 1/FULLKEYCARD = 1/2500 = 0,0004 AND nachname = Maier AND einst_dat = ) WHERE abt_nr = A00 FF = (1/FIRSTKEYCARD * 1/COLCARD von nachname) AND nachname = Maier (1/50 * 1/20) = 0,001 Generell ist ein niedriger FF, der nur eine kleine prozentuale Auswahl aus dem Gesamtvolumen ausweist, kostengünstiger als ein hoher FF 80

81 DB2 for LUW Der access path Der Optimizer und die Suche nach dem access path SELECT d.name, sum(e.id), avg(e.compensation) FROM employees e, departments d, projects p WHERE d.location in ( SVL, ARC ) and d.id = e.dept and e.id = p.employeeid and p.class in ( top secret, confidential ) GROUP BY d.name ORDER BY d.name Letztendlicher Zugriffspfad Annahmen: Index: ix1(d.location) ix2(e.id), ix3(e.dept) ix4(p.class) Cardinality: card(e) = card(d) = card(p) = Filtering factor: FF(P1) = 1%, FF(P4) = 10% Employee Department # von join sequences (3! = 6) # von access methods (RSCAN, ISCAN, Midx, etc) # von join methods (NLJ, SMJ, HBJ) Gesamtzahl von Zugriffspfaden Kostenschätzung (elapsed time) Zugriffspfadwahl (kürzeste elapsed time ) Projects 81

82 DB2 for LUW Der access path Der Optimizer und die Suche nach dem access path indexable & not indexable WHERE LASTNAME = 'SMITH' AND FIRSTNME <> 'JOHN' Indexable NOT Indexable 1. indexable predicates : Können passende IX-Einträge finden Können IX-matching predicates werden, abhängig von vorhandenen IX und der Pfadauswahl des Optimizers Begrenzen die range of data, die gelesen wird: Alle anderen Prädikattypen bauen darauf auf. Die Anzahl von matching predicates hängt vom ausgewählten Index ab i.d.r. von den ersten Spalten Mit = oder IN : sobald ein range -Prädikat (oder ein weiteres IN ) verwendet wird, werden alle folgenden Prädikate als non matching gewertet 2. not indexable predicates Können niemals passende IX-Einträge finden Index 1: Firstnme, Lastname WHERE 1 MCOLS AND AND Index 2: Lastname, Firstnme, City LASTNAME = 'SMITH' FIRSTNME LIKE 'J%' 2 MCOLS CITY = 'CHICAGO' 82

83 DB2 for LUW Der access path Tablespace Scan / File Pageset Scan Matching Index Scan (MATCHCOLS > 0 ) IN-List Index Scan Non-Matching Index Scan (MATCHCOLS = 0 ) One-Fetch Index Scan Index Only Access Direkter Zeilenzugriff über eine ROWID-Spalte ( direkt) Multiple Index Scan... Annähernd alle einfachen Zugriffsarten können durch sequential prefetch und/oder list prefetch weiter unterstützt werden... 83

84 DB2 for LUW Der access path Tablespace Scan / File Pageset Scan ein Beispiel Tablespace Scan / File Pageset Scan - Wenn keine Auswahlbedingungen formuliert sind - wenn auf eine interne Workfile oder eine temporäre Tabelle zugegriffen, für die keine Indizes existieren - Wenn kein nutzbarer Index verfügbar ist(where-klausel...) - Wenn ein nutzbarer Index aus Kostengründen nicht eingesetzt wird. Es wird erwartet, dass eine %-ual hohe Anzahl der Gesamtzahl aller Tabellenzeilen ausgefiltert wird ODER ein clustered Index ist nicht mehr optimal organisiert und es wird erwartet, dass eine grössere Zahl von Daten ausgefiltert wird Beispiel: SELECT * FROM mitarbeiter ; IX auf Spalte persnr und abt_nr SELECT... FROM mitarbeiter WHERE einst_dat >

85 DB2 for LUW SQL Tuning & Monitoring Kapitelinhalt Best Practices in einem DWH Umfeld BP - Database Design BP Überlegungen zu Applikationen BP Performance Layer BP - Configuration and Operations DB Design und Objektdefinitionen Denormalisierungsmuster Physisches Design und Datentypen bei DB2 Index Designmuster SQL Tuning Query Design Optimization class und Optimizer SQL EXPLAINs SQL runtime optimization (MQT s, temp Tables, SORTs) Beeinflussen des access plan bei DB2 Zugriffsarten bei DB2 Regeln zu Tabellen- und Index-Design 85

86 DB2 for LUW Regeln zur Verwendung von SQL Index- und Table-Design-Tips Zum Index-Design folgende ergänzenden Empfehlungen: 1. Definieren sie Index TYPE 2: wegen "row level" Locking UR Isolation für den Zugriffspfad wegen paralleler Task-Verarbeitung im Falle von "multiple" Queries wegen konkurrierendem Zugriff auf getrennte logische Partitions 2. Um ROW-Level-Locking nutzen zu können ist zwingend der Indextyp 2 zu erzeugen. Ist beim CREATE- Index keine Typangabe gemacht, so wird er als "default" der Wert genommen. 3. DB2 nutzt keinen Index, wenn ein JOIN einer Tabelle auf sich selbst ( self-referencing ) durchgeführt wird. Das gilt auch für die gleichzeitige Nutzung von mehreren views auf dieselbe Tabelle. 4. Indizes erhöhen die Performance beim Lesen und sichern die Eindeutigkeit von Spaltenwerten ab. 5. Indizes müssen dahingehend überwacht werden, ob sie genutzt werden und ihre Nutzung effizient ist. ABER: Sie verlangsamen Modifikationsoperationen (INSERT, UPDATE, DELETE) und können sogar zu -911 (sqlstate: 40001: Deadlock / timeout ) und -904(sqlstate: 57011: "Resource not available") Fehlern bei Parallelläufen führen. 6. Die Funktion EXPLAIN liefert Informationen über ausgewählte Zugriffspfade, Querykosten, Zugriffsreihenfolge von IX/Tabellen Die Katalog-Tabelle SYSCAT.INDEXES (LAST_USED) gibt Auskunft darüber, ob alle Indizes wie vorgesehen auch genutzt werden. 7. Ein Index sollte gelöscht werden, falls er nicht genutzt wird (db2pd oder LAST_USED in SYSCAT.INDEXES). 8. RUNSTATS ist notwendig, um verlässliche Aussagen durch die EXPLAIN-Funktion zu erhalten und dem optimizer die notwendigen Statistine für den optimalen access path zu liefern 86

87 DB2 for LUW Regeln zur Verwendung von SQL Index- und Table-Design-Tips Zum Index-Design folgende ergänzenden Empfehlungen: 9. REORG sollte regelmäßig durchgeführt werden, abhängig von der Tiefe der Indexstaffelung, der Sequenz der "leaf pages" und der Zersplitterung der Daten. 10. Ein Index kann gelöscht werden, wenn die Tabelle kleiner als 6 "pages" ist. 11. PCTFREE 10 wird empfohlen, wenn häufige Index page splits erwartet werden. 12. Die Werte für PCTFREE können nach dem Laden einer Tabelle modifiziert werden; die neuen Definitionen wirken aber erst nach REORG/RELOAD. 13. Angemessene Nutzung von freiem Speicherplatz führt zu schnellerer Datenreferenz, aber auch zu erhöhten Speicherkosten höherer Anzahl von Index- pages und Index-Ebenen möglicherweise erhöhter Länge von TS Scans. 14. Zusammengesetzte Schlüssel sollten möglichst Eindeutigkeit garantieren. 15. Eine variable, deren Definition nicht zu den Attributen der zugehörigen Spalten paßt, verhindert den Indexzugriff für betroffene Spalten. 16. Indizes über Spalten, die länger als 40 Bytes sind, sollten vermieden werden. 17. Die Kardinalität einer Spalte beeinflußt die Indexnutzung primär. 18. Spalten, die häufig modifiziert werden müssen, sollten in möglichst wenigen Indizes vorkommen. 87

88 DB2 for LUW Regeln zur Verwendung von SQL Index- und Table-Design-Tips Zum Index-Design folgende ergänzenden Empfehlungen: 19. Ein clustering - Index sollte immer dann definiert werden, wenn Daten häufig in EINER BESTIMMTEN Reihenfolge benötigt werden. 20. Der zuerst definierte Index (chronologisch) wird automatisch als "CLUSTER-Index genutzt, falls kein CLUSTER-Index explizit definiert wurde. 21. Ein matching Index ist anderen Indexstrukturen immer vorzuziehen. 22. Die nächstbeste Alternative ist eine non-matching Index Suche ohne Datenzugriff. 23. TS- scans sind normalerweise die am wenigsten effiziente Zugriffsstrategie, außer PREFETCH kann genutzt werden und eine (oder mehr) Zeilen pro (mindestens) zwei Daten- pages können gelesen werden. 24. Der Prädikat-Typ des SQL- requests beeinflußt die Index-Nutzung stark. Er sollte möglichst einschränkend auf die Ergebnismenge wirken 25. Wenn VARCHAR-Spalten nicht benötigt werden, dann verzichte man auf sie. VARCHARs im Index werden mit Blanks auf ihre maximale Länge aufgefüllt 88

89 DB2 for LUW Regeln zur Verwendung von SQL Index- und Table-Design-Tips Tipps zum Table-Design sind im Folgenden zusammengefasst. Alle Punkte sind nicht als Vorschriften zu verstehen, sondern als Möglichkeiten. Die Kombination aus mehreren (einfachen) Maßnahmen kann das Vorgehen entsprechend komplex und nicht mehr trivial erscheinen lassen. 1. Wägen Sie beim physischen Design ab zwischen "UPDATE-Overhead" Performance-Verluste beim Lesen durch Normalisierung Nicht IMMER ist REDUNDANZ schlecht! 2. Benutzen Sie "Views /MQT s, falls abgeleitete Werte NICHT STÄNDIG und aktuell gebraucht werden ( Jahressummen, Vertriebsvorgaben, Quartalszahlen...) 3. Jede Tabelle sollte mindestens EINEN UNIQUE INDEX bzw. PRIMARY KEY haben. Der PK Constraint verlangt, dass PK's UNIQUE definiert werden. 4. "FOREIGN KEYS" werden genutzt, um Beziehungen zwischen DB2-Tabellen darzustellen. 5. FK's müssen nicht, sollten aber immer indiziert sein. Sie können NULL-Werte enthalten. 6. Wenn FK's definiert sind, sollten sie mit einem sprechenden (nicht vom System generierten) Namen versehen werden. Dies hilft später bei der Fehleridentifikation in Rl-Situationen (-53x). Zudem können über diese Namen DROP's von FK's und gezielte Queries auf den Katalog durchgeführt werden. 7. JOlN-Funktionen werden über die Nutzung von Indizes beschleunigt: PK FK -Beziehungen. 8. Die "record size" bei DB2 kann niemals die über die Bufferpools vorgegebene "page size" überschreiten (z.b. 4K, 8K ) 89

90 DB2 for LUW Regeln zur Verwendung von SQL Index- und Table-Design-Tips 9. "rows" sollten nicht kürzer als 24 Bytes sein (!) und wenn irgendwie möglich mit fester Länge definiert werden. 10. Spalten, die miteinander verglichen werden, sollten dieselbe Länge und denselben DATENTYP haben 11. VARCHAR-Spalten, die nicht länger als 40 Bytes sind, sollten als "fixed" CHAR definiert werden. 12. VARCHAR-Felder sollten nicht größer als nötig definiert werden. 13. Man vermeide die Definition von VARCHAR-Feldern, wenn die Variation der Feldlänge konstant und vorhersehbar ist. 14. LONG VARCHAR-Definitionen sind zu vermeiden. keine Nutzung von ALTER TABLE nur BP32K nur 1 Zeile pro "page" usw. 15. Alle xlob-spaltendefinitionen sollten vermieden werden. 16. Bei der Definition numerischer Datenfelder beachte man: SQLCODE "arithmetic overflow" kann auftreten 17. Felder mit variabler Länge (NULL oder VARCHAR) sollten möglichst am Ende einer Tabelle definiert werden. 18. Bei der Nutzung von ALTER und ADD <column> mit Feldern fixer Länge, werden diese bis zum REORG wie variable Felder behandelt. 19. Häufig genutzte (inhaltsstabile) Spalten gehören an den Anfang der Tabelle.. 90

91 DB2 for LUW Regeln zur Verwendung von SQL Index- und Table-Design-Tips 20. NOT NULL WITH DEFAULT sollte bei noch unbestimmter Nutzung des Feldes in der Zukunft gesetzt werden. 21. Man beachte, dass eine CREATE-Anweisung nicht gleichzeitig mit einem DB2-"utility", das einen anderen TS in derselben DATABASE nutzt, ablaufen kann. 22. CHECK-Constraints verringern den Aufwand in Programmen bezüglich der Plausibilitätsprüfungen, führen aber zu erhöhtem Aufwand in der Administration(LOAD, ALTER ). 23. Ist ein "record" nur geringfügig größer als eine ½ 4-K Page (> 2036), so entsteht enorme Platzverschwendung. 24. NULL-Felder sollten soweit irgendwie möglich vermieden werden: Alternative: NOT NULL WITH DEFAULT bzw. NOT NULL 25. Bei der Verwendung von NULL-Werten gilt es folgendes zu beachten: NULL erfüllt niemals einen mathematischen Vergleich bei JOIN - Operationen über Nullfähige Spalten sollte die OUTER JOIN - Formulierung verwendet werden. 91

92 DB2 for LUW Regeln zur Verwendung von SQL Für Automatismen Feaks DO NOT TURN ON AUTOMATIC STMM Tuning Until AFTER Physical Design Flaws are Cured! Wenn kostspielige scans oder sorts in der Last des Rechners existieren, können die wechselnden Anforderungen an den memory STMM zur Verzweiflung treiben und alles mündet in Performance Problemen. STMM sollte für das fine tuning einer database genutzt werden nachdem physische Design-Mängel behoben bzw. entfernt wurden. Nach dem Testen des fine tunings mit STMM shut it off. 92