DB2 SQL. DB2-Optimierung und SQL-Performance. Grundlagen, Standards und Tipps zum effizienten Umgang mit DB2/SQL. Ausgabe 9: 2010 V 9.

Transkript

1 Kapitel 2: Grundsätzliches zu DB2 und Performance Grundlagen, Standards und Tipps zum effizienten Umgang mit DB2/SQL DB2 SQL Optimierung und Performance Ausgabe 9: 2010 V 9.03 S.K.Consulting Services GmbH (inkl. DB2 V9) Seite 1 von 128

2 Kapitel 2: Grundsätzliches zu DB2 und Performance INHALTSVERZEICHNIS 1 VORWORT GRUNDSÄTZLICHES ZU DB2 UND PERFORMANCE Planen von Performance Strategien Management von Performance allgemein Setzen von realistischen Performance Zielen Planung der Performance Überwachung Kontrolle und review der performancerelevanten Daten Optimierungspotentiale bei DB Vorgehensweise beim Tuning von DB Anhaltspunkte und Analysedaten für Tuning Accounting und statistics records Grundvoraussetzungen für DB2/UDB Performance Voraussetzungen für die Performance in SQL bei DB Möglichkeiten und Maßnahmen zur (SQL-)Optimierung Systemtechnische Aktivitäten Anwendungsbezogene Maßnahmen Die Tuningpotentiale des DB2-Systems SQL - DIE STRUCTURED QUERY LANGUAGE BEI DB Relationale Sprachelemente und Operationen bei SQL Die relationale Funktion "SELEKTION" Die relationale Funktion "PROJEKTION" Die relationale Funktion "JOIN" Relationale Mengenoperationen-Zusammenfassung Generelle Überlegungen und Voraussetzungen für SQL Performance Dynamic SQL Datenbankobjekte und ihre Struktur Tabellen und Tablespaces Indexe Primary und Clustering Indexes Index Only -Zugriffe auf VARCHAR Spalten Verzögerte Objektdefinitionen Aufwand und Kosten von Indexes Empfehlungen zu Sortierungen SQL-Abfragen mit Subqueries correlated vs non-correlated Subqueries Correlated subqueries non-correlated Subqueries Komplexität von Queries Spalten-Funktionen Formulieren von Prädikaten Die Verwendung von scalar functions Neuordnen der Tabellenfolge in der FROM Klausel List prefetch Uncommitted read row level locks Freigabe von Locks S.K.Consulting Services GmbH Seite 2 von 128

3 Kapitel 2: Grundsätzliches zu DB2 und Performance lock escalation "materialized query tables"(mqt's) und "automatic query rewrite"(aqr) Empfehlungen für das Design von "materialized query tables" Empfehlungen für das Design der zugehörigen "base tables" Der DB2-Katalog SQL-TUNING UND PERFORMANCE BEI DB Die neuen Limits bei DB2 Version Die DB2 SQL Engine SQL-Tuning und die Logik der Abfragen constant propagation Eliminieren von totem Code Zusammenfassen von Konstanten ( constant folding ) case-insensitive Suchen Sargability Transformation von Prädikaten Transitive closure für Prädikate "Join transitive closure" transitive closure bei OUTER JOINs Ausnahmen zur transitive closure Regel predicate push down predicate bubble up DB2 SQL und Performanceempfehlungen Grundsätzliche Empfehlungen zu DB2-SQL Suche die kleinste row -Menge Lies nur die Spalten, die wirklich benötigt werden Reduziere die Anzahl der SQL-Statements Kodiere Prädikate, die möglichst selektiv sind Beachte die Qualität von DB2-SQL Abfragen Nutze stage1 -Prädikate Verwende nie generische SQL-Statements Vermeide unnötige SORT-Abläufe Sortiere nur die erforderlichen Spalten Benutze die ON-Klausel für alle JOIN-Prädikate Vermeide UNIONs Versuche JOINs anstatt subqueries zu nutzen Komplementärmengen bei outer joins Kodiere die selektivsten Prädikate zuerst Nutze erprobte Methoden zur Existenzprüfung(EXISTS) Subqueries sind zu tunen Wann transformiert DB2 eine Subquery in einen Join? Die Qual der Wahl zwischen Subquery und Join Vermeide alles, was nicht unbedingt notwendig ist Modifikation von SQL-Statements Häufigste Modifikationen durch das DB Modifikationen über zusätzliche Prädikate ( transitive closure ) Vereinfachung der JOIN-Verarbeitung Beeinflussung der Reihenfolge von Tabellen bei OUTER-JOINs Subquery-Transformation in JOINs Auswahl der äusseren Tabelle bei JOINs Ausschalten von Indizes Beeinflussen der IX-Nutzung Beeinflussen von outer table Auswahl und JOIN-Methode Restrukturierung von UNION- durch CASE-Ausdrücke Unterstützung von UNION- durch physisches DB-Design Spezielle Techniken S.K.Consulting Services GmbH Seite 3 von 128

4 Kapitel 2: Grundsätzliches zu DB2 und Performance CASE in Prädikaten CASE in UPDATE Anweisungen CASE zum Vermeiden von Rechen- oder anderen Fehlern CASE zum Eliminieren von UNION-Klauseln Weitere Möglichkeiten der Verwendung der CASE-Klausel Problematische CASE Ausdrücke Funktionsequivalente Ausdrücke zur CASE-Klausel Die CAST-Funktion GROUP BY für single pass GROUP BY für beide Seiten ORDER BY und SORT-Vorgänge bei DB ORDER BY und Vermeiden von Sorts (seit V7) Nutzung von Local Storage Buffer Pool Storage Nutzung DASD Nutzung Nutzung von Work Files Berechnen der SORT Pool Größe "Secondary Extents" Weitere Überlegungen: Sort Assist Weitere Überlegungen: Destructive Reads Weitere Überlegungen: Locks auf Work Files Wann wird ein Sort erforderlich? Größe und Anzahl von Sort Work Files Isolieren der DSNDB07 im eigenen Bufferpool Benutzen von Temporary Tables Weitere Nutzer der Workfile Database Index-Unterstützung bei SORTs Eliminieren nicht erforderlicher Spalten Sort Bufferpool Thresholds Nutzung des Hiperpools für Sortvorgänge Einschalten eines DASD Cache Definition eines 32 KB Bufferpools Überlegungen zum Data Sharing Einsatz des cartesian join ( star-join ) Das Star Join Schema Wann wird ein Star Join Schema genutzt? Beispiele: Query mit drei dimension tables Empfehlungen zur Erstellung von IX für "star join Queries" Bestimmen der Spaltenreihenfolge in einem Index für ein "star schema" Beispiel zum Bestimmen der Spaltenfolge für einen "fact table" Index existence checks mit SQL So sollte es nicht gemacht werden correlated Subquery gegen non-correlated Subquery Grobe Vergleichsmessungen existence check und OPTIMIZE FOR 1 ROW Fetch First Row Only Zusammenfassung JOIN s und OUTER JOIN s Warum Joins von Bedeutung sind Beispiel-Views Die Join Syntax ON-Klausel vs WHERE-Formulierung Die Join Typen Cross Join, Kartesisches Produkt Inner Join = Equivalent Join Natural Join Left Outer Join = Left Join Right Outer Join = Right Join S.K.Consulting Services GmbH Seite 4 von 128

5 Kapitel 2: Grundsätzliches zu DB2 und Performance Full Outer Join = Full Join Union Join Semi-Join Theta Join, Non-Equivalent-Join Self-Join Division (Quotient) Die Kodierung der Join Typen in DB2 SQL Inner Join ON und WHERE Nutzung beim INNER JOIN Left Outer Join ON und WHERE Nutzung beim OUTER JOIN Right Outer Join ON und WHERE Nutzung beim right outer join Full Outer Joins ON und WHERE Nutzung beim full outer join Cartesian Product Bemerkungen zu Joins Nutzung der Funktion COALESCE Liste der non-matching rows Join in der SELECT Phrase Nutzung von CASE Multiple Columns Column Functions Predikate und Joins - eine Lektion Joins - Beachtenswertes Binary Matching Operationen Der NESTED-LOOP JOIN Algorithmus Der MERGE-JOIN Algorithmus Der Hybrid-JOIN Algorithmus Der HASH JOIN Algorithmus Besprechung der Optimierungstechniken Prädikate auf der Preserved Side Prädikate auf der Null Supplying Side Prädikate in einer WHERE Klausel Predicate Push Down in einer ON Klausel Not Null Predicates Push Down Not Null Predicates in einer WHERE Klausel Not Null Predicates in einer ON Klausel Die SQL-Statements INTERSECT und EXCEPT Die Operation MERGE Die Operation TRUNCATE Mehr Performance für SQL-Operationen in Programmen seit V8/V scalar full select multiple DISTINCT s ORDER BY und FETCH FIRST im Subselect multi row FETCH und multi row INSERT common table expressions Rekursives SQL Mehr Performance für Modifikationsoperationen ab DB2 V multi row INSERT Lesen geänderter/eingefügter Zeileninhalte über SELECT multi row FETCH und positioned UPDATE/DELETE" Gestern, heute, morgen - Datumsarithmetik im DB Das Spezialregister current date S.K.Consulting Services GmbH Seite 5 von 128

6 Kapitel 2: Grundsätzliches zu DB2 und Performance Datumsarithmetik Die Date-Duration Skalare Funktionen in Verbindung mit Datumsarithmetik Do s und Don ts bei SQL in Kürze Grundsätzliche Empfehlungen zu SQL Tipps und Hinweise In Programmen möglichst zu verbietende SQL- Anweisungen SQL - Anweisungen, die keine Indexbenutzung zulassen SQL-Anweisungen, die eine Indexnutzung zulassen, SQL - Anweisungen, die ungünstig formuliert sind SQL - Anweisungen, die ungünstige JOIN-Formulierungen enthalten Vermeiden arithmetischer Ausdrücke in einem Prädikat DB2 SQL Nutzungsrichtlinien (Zusammenfassung) Allgemeines ORDER BY und GROUP BY JOIN-Tuning Subquery Tuning DIE RELATIONALEN KOMPONENTEN IN DB Das RDS - Relational Data Systems DM - Data Manager BM - Buffer Manager IRLM Lock, Timeout, Deadlock VSAM (außerhalb von DB2) DIE VERARBEITUNG VON PRÄDIKATEN Indexable Predicates Wie wird der Index durchsucht? "Sargeable und indexable Predicates"(Übersicht) Bemerkungen zur o.g. Tabelle Beispiele bestimmter Prädikatstypen Weitere Beispiele für Sargeable & indexable Predicates Prädikate auf Sargeable & indexable umformulieren (Beispiele) DB2 "Access Path"-Auswahl Access-Path-Selection bei Tablespace- / Table-Scan Access-Path-Selection bei "non-matching" Index Access-Path-Selection bei "matching" Index Access-Path-Selection bei "One-Fetch" Index-Scan Access-Path-Selection bei "Index-only" Zugriff DB2 "Access Path"-Selection (Zusammenfassung) DB2 "Access Path"-Auswahl : "List Prefetch" DB2 "Access Path"-Auswahl : "Multiple Index Access" / UNION (OR) DB2 "Access Path"-Wahl : "Multiple Index Access" / INTERSECT (AND) DB2 "Access Path"-Auswahl : "Multiple Index Access" / AND + OR DB2 - EXPLAIN für MI-Zugriffe DB2 "Access Path"-Auswahl : JOINs / "nested loop" Ablauf des "nested loop"-join Performancetipp DB2 "Access Path"-Auswahl : JOINs / "merge scan" Vorgehensweise Performancetipp S.K.Consulting Services GmbH Seite 6 von 128

7 Kapitel 2: Grundsätzliches zu DB2 und Performance 6.4 Spezielle Techniken zum Beeinflussen der Pfadauswahl bei DB Die Informationen über Zugriffspfade Minimieren des "overhead" durch Anfordern von wenigen "rows" Die Klausel OPTIMIZE FOR n ROWS Was beinhaltet OPTIMIZE FOR n ROWS? OPTIMIZE FOR 1 ROW zum Vermeiden von SORTs? Wie wird OPTIMIZE FOR n ROWS in einer CLI Applikation genutzt? Wieviele rows können mit OPTIMIZE FOR n ROWS gelesen werden? Wann ist OPTIMIZE FOR n ROWS effizient? Auswirkungen bei der Verwendung von OPTIMIZE FOR n ROWS Anfordern einer begrenzten Zahl von "rows" Abhängigkeit OPTIMIZE FOR n ROWS und FETCH FIRST n ROWS ONLY Nutzung der "cardinality" Klausel Reduzieren der Anzahl "matching columns" Neuanordnen der Tabellenreihenfolge Update der Katalogstatistiken Modifizieren des Katalogs (Anpassen der "correlated columns") Update des Katalogs wegen join mit table functions Nutzung von Subsystem Parametern Favorisieren von "matching index" Zugriffen über Subsystem Parameter Optimieren von Queries mit IN-List Prädikaten über Subsystem Parameter Favorisieren eines indizierten Zugriffs Beispiel einer "Column correlation" Feststellen von "column correlations" Einflüsse von column correlations Was tun bei column correlations? DB2 - Parallelverarbeitung Allgemein Konzeptioneller background und Terminologie Bedeutung der concurrency control Locks Lock Modi Granularität von Locking Suspension Timeout Deadlock Concurrency Mechanismen für Utilities und Kommandos Database Design Überlegungen Partitioning Lock escalation LOCKSIZE Welches ist die richtige locksize? Kleine Tabellen Gruppieren von DB2 Objekten und Authorisierungen Überlegungen zum Applikationsdesign BIND Optionen Die BIND-Option ACQUIRE Die BIND-Option RELEASE Die BIND-Optionen: ACQUIRE/RELEASE Kombinationen Die BIND-Option ISOLATION Die BIND-Option CURRENTDATA Überschreiben der Isolation Option aus dem BIND (WITH Klausel) Empfehlungen zur BIND Option ISOLATION Lock avoidance und Isolation Begrenzen der Anzahl Locks auf einem Tablespace Begrenzen der Locks für eine einzelne Applikation System und Installationsüberlegungen S.K.Consulting Services GmbH Seite 7 von 128

8 Kapitel 2: Grundsätzliches zu DB2 und Performance 7 ANALYSE DER ZUGRIFFSPFADE UND DIE DB2-OPTIMIZER INFORMATIONEN Faktoren der Entscheidung für den DB2-Optimizer Der Optimierungsvorgang und EXPLAIN Prädikate und Prädikatkategorien Die Filter Filterfaktoren(FF) Default -Filterfaktoren für simple predicates Filterfaktoren Interpolationsformeln Filterfaktoren für alle anderen Verteilungsformen Nutzung von multiple filter factors zur Bestimmung der Quiery-Kosten Update von Kataloginformationen PLAN_TABLE und EXPLAIN Voraussetzungen für effizientes EXPLAIN Informationen, die nicht in der PLAN_TABLE stehen Die DSN_STATEMNT_TABLE Einflüsse auf die Kostenkategorien Verbesserungen für "stage 2"-Prädikate "view" Materialisierung "nested table expression" Materialisierung Verbessern der Lock-Nutzung bei DB Generelle Empfehlungen Vermeiden von "false contention" Monitoring auf "false contention" Wieviel contention ist akzeptabel? Wie kann man false contentions reduzieren? Verändern der Größe einer lock structure Dynamische Änderung der lock structure Größe Ändern der lock structure Größe durch Neuaufbau Verringern der lock entry size Reduzieren der Zeit bis zum Auflösen von contentions Vermeiden von partition locks auf alle TS Partitions Tuning von deadlock und timeout Verarbeitung Globales deadlock processing Kontrolle der deadlock detection Der global deadlock manager Der local deadlock detector Abhängigkeiten zwischen local und global deadlock detection Globales timeout processing Elapsed time bis timeout bei non-data-sharing Elapsed time bis timeout bei data sharing Empfehlungen BEHANDLUNG LANGLAUFENDER QUERIES/STATEMENTS Explain und PLAN_TABLE prüfen DSN_STATEMNT_TABLE einbeziehen SQL-Statement überprüfen Prüfen der Struktur des Datenmodells RUNSTATS-Statistik-Spalten des Katalogs überprüfen S.K.Consulting Services GmbH Seite 8 von 128

9 Kapitel 2: Grundsätzliches zu DB2 und Performance 8.6 Monitor einsetzen und Ergebnisse überprüfen (z.b. DB2PM) SQL TRACE REPORT überprüfen (z.b. DB2PM) MESSWERTE UND DATEN FÜR SQL-PERFORMANCE Bufferpool-Hit Ratio und Maximal Unreferenced Pool Age (MUPA) DB2-Tools und Möglichkeiten zur Ermittlung von Performance-Werten Statistikdaten des Katalogs Statistikdaten und ihre Auswirkung auf das DB2 Optimizing Manipulation von Statistikwerten DB2-Accounting-Zeiten SQL Query-Typen: "I/O Bound" und "CPU Bound" SQL-QUERY UND TUNING EMPFEHLUNGEN (ZUSAMMENFASSUNG) Richtlinien zur Leistungsoptimierung Kodieren Sie SQL nur für die erforderlichen Ergebnisse Wird die erwartete Performance nicht erreicht Prädikate werden in stages verarbeitet Weitere Empfehlungen zu SQL-Queries ORDER BY / GROUP BY JOIN Tuning Allgemein Subquery Tuning ANHANG SQL - Zusatzinformationen Zum Thema LIKE DB2 zum Thema optimistic locking builtin-functions Abbildungsverzeichnis Index Glossar Literaturhinweise S.K.Consulting Services GmbH Seite 9 von 128

10 Kapitel 2: Grundsätzliches zu DB2 und Performance 1 Vorwort Information steht heute und auch in Zukunft im Mittelpunkt wirtschaftlichen Handelns. Information wird zur treibenden Kraft der Informationsgesellschaft... Das Zitat von John Naisbitt aus seinem Buch Megatrends (1988) sagt über die Bedeutung der Information in unserer Gesellschaft alles aus. Information ist ein denkbar abstrakter Stoff, der leichter, effizienter und produktiver verwendet werden kann, wenn er geordnet und seinem Zusammenhang gemäß sinnvoll dargestellt und angeboten wird. Datenbankmanagementsysteme (DBMS) sind die Werkzeuge, mit denen Informationen strukturiert, verwaltet und bedarfsgerecht aufbereitet, wiedergegeben werden können sollten. Über sie werden moderne Informationssysteme erst möglich. DB2/UDB von IBM ist eines dieser Datenbanksysteme, das in einer modernen IT- Umgebung in der Lage ist, Informationsarchitekturen und -systeme über und für die gesamte Unternehmenshierarchie umfassend real werden zu lassen. Informationsverarbeitung ist immer dann effizient, wenn die richtigen Informationen zum richtigen Zeitpunkt am richtigen Ort sind. Dazu bedarf es einer sorgfältigen Planung und Konzeption, einer technisch perfekten Implementierung und einer ständigen Kontrolle und Abstimmung. Die Datenbank als Informationsspeicher muss in der Lage sein, gestellte Anforderungen sicher, konsistent und schnell zu erfüllen: Manche Informationen sind eben nur dann wertvoll, wenn sie hochaktuell sind. Und - jeder Nutzer spezifischer Informationen kann seine eigenen individuellen und subjektiven Ansprüche an diese Ressource Information stellen. Das erfordert technisch hochperformante und flexible, aber auch stabile und sichere Systeme. DB2/UDB beispielsweise läßt sich so einstellen, dass alle erforderlichen Aktivitäten und Anwendungen auf effizienteste Art und Weise bedient werden könnten. Dazu müssen alle (System-)Parameter optimal gewählt und die Datenstrukturen nach sorgfältiger Analyse in die physische DB2-Umgebung überführt werden. Dies gilt umso mehr, als mit der Ausweitung der Informationstechnik die Komplexität der Informationsstrukturen selbst und die Quantität angebotener Datenmengen ständig zunimmt, andererseits die Informationsqualität weiter verbessert und die verfügbaren Informationen immer effektiver und zielgerichteter dargeboten werden müssen. Insbesondere aber gilt es, Applikationen architektonisch so abzubilden und Programme so zu schreiben, dass Performanceziele erreicht werden und ein Minimum an Kosten entsteht. Denn: Ein Datenbanksystem selbst bringt den Unternehmen noch keinen oder nur geringen Nutzen. Dieser entsteht erst aus der intensiven Nutzung der verfügbaren Information und der daraus resultierenden betriebswirtschaftlichen Wertschöpfung: Je mehr Nutzung, desto mehr Nutzen ist möglich und umso besser kann die Informatiosnbewirtschaftung für das Unternehmen sein. Die Erkenntnis, dass der Unternehmenserfolg, wie bei den bekannten klassischen Produktionsfaktoren - Finanzen, Material, Anlagen und Personal - unmittelbar von einer erschöpfenden und werteffizienten Verwertung der fünften Kraft Information - abhängt, führte zur Suche nach neuen Konzepten in einem neuen betriebswirtschaftlichen Umfeld - der Informationswirtschaft. Im Zentrum der wirtschaftlichen Aspekte aber steht die Informationstechnologie - ihre Möglichkeiten, ihre Produkte. Die Erwartungen an die Leistungsfähigkeit eines DBMS sind folglich hoch. S.K.Consulting Services GmbH Seite 10 von 128

11 Kapitel 2: Grundsätzliches zu DB2 und Performance In dieser Handbuchserie werden unter DB2 Performance-Gesichtspunkten alle wichtigen Fragen zu und die Möglichkeiten in Hinsicht auf das Produkt DB2 thematisiert. Die Serie besteht aus folgenden Büchern: 01_Die Umgebung von DB2 Eine Architekturübersicht 02_DB2 und das Relationenmodell von Dr. Codd 03_DB2-Optimierung und SQL-Performance 04_Physisches DB-Design und DB2-Performance 05_DB2 und effiziente Anwendungsentwicklung 06_Administration von DB2 Umgebungen 07_Tunig-Beispiele zu DB2: Erfahrungen aus der Praxis 08_DB2 im Client-Server Umfeld 09_Tools und hilfreiche Produkte zu DB2 Die gesamte Handbuch-Serie stellt sich nicht in Form von Manuals im Sinne von Systemdokumentation dar diese werden vom Hersteller angeboten. Vielmehr ist beabsichtigt, DB2 unter Nutzbarkeits- und Performance-Gesichtspunkten möglichst umfassend zu beleuchten. Die Serie ist für Kenner, nicht in erster Linie für Neulinge im Umgang mit DB2, konzipiert. Das vorliegende Handbuch beschäftigt sich mit dem Thema: DB2 und SQL- Performance. Es soll als Leitfaden dienen, das SQL Statements ursprünglich, richtig und effizient zu entwickeln, zu testen und zukünftig optimal schreiben und einstellen zu können - immer mit dem Ziel, höchstmöglicher Performance in allen direkt betroffenen und umliegenden Betrachtungsfeldern. Viel Spaß beim Lesen und viel Erfolg bei der Nutzung von IBM s DB2/UDB. Mit freundlichen Grüßen S.K. Consulting Services GmbH Sepp Kraus Für die Mitarbeit an diesem Handbuch bedanken wir uns insbesondere bei den Firmen ARAL AG, Bochum AXA Versicherungen, Köln BMW AG, München VW Financial Services AG, Braunschweig Itellium GmbH & Co, Fürth IT-Verlag, Sauerlach b. München S.K.Consulting Services GmbH Seite 11 von 128

12 Kapitel 2: Grundsätzliches zu DB2 und Performance 2 Grundsätzliches zu DB2 und Performance 2.1 Planen von Performance Strategien Der erste Schritt zur Verbesserung von Performance besteht in der Planung der Ziele, Kriterien, Vorgehensweisen und Aufwände: Zum Planen einer Performance-Strategie sollten folgende Punkte in Betracht gezogen werden: Management von Performance allgemein Setzen von realistischen Performance Zielen Planung der Performance Überwachung Kontrolle und review der performancerelevanten Daten Neben den Informationen über Performance Monitoring und Tuning sollten folgende Tatsachen nicht außer Acht gelassen werden: DB2 ist nur ein Teil eines Gesamtsystems. Jede Änderung an der Hardware von zseries, am disk subsystem, an z/os, IMS, CICS, TCP/IP, VTAM, dem Netzwerk, WebSphere oder den Anwendungen verteilter Plattformen, z.b. Windows, UNIX oder Linux, die sich die gemeinsame IT Infrastruktur teilen, können Einfluss darauf nehmen, wie DB2 und seine Anwendungen laufen. Die Empfehlungen für Performance Monitoring und Tuning basieren also auf den derzeitigen Erkenntnissen über DB2 Performance unter normalen Umständen und typischen Systemzuständen. Deshalb kann auch nicht garantiert werden, dass die in diesem Buch veröffentlichten Empfehlungen für jede spezielle Konfiguration seine uneingeschränkte Gültigkeit hat. Um genau zu sein, häufig erfolgen die Hinweise zu Performance Situationen aus einem speziellen Performancegesichtpunkt heraus. In manchen Installationen können aber andere Faktoren eine höhere Priorität haben und normale Empfehlungen könnten so ungeeignet sein. Die Empfehlungen sind allgemein. Performance Messungen sind in höchstem Maße abhängig von der Last und Systemcharakteristiken außerhalb von DB Management von Performance allgemein Die Kontrolle und das Management von Performance umfassen in allen Systemen dieselben Schritte: 1. Aufstellen und Festlegen der Performanceziele 2. Planung, wie Performance überwacht werden soll ( performance monitoring ) 3. Durchführen der geplanten Aktionen 4. Analyse der performance reports, um zu entscheiden, ob die Ziele erreicht wurden 5. Ist die Performance uneingeschränkt zufriedenstellend, gelten folgende Optionen: Weniger monitoring, denn monitoring selbst benötigt ebenfalls Ressourcen S.K.Consulting Services GmbH Seite 12 von 128

13 Kapitel 2: Grundsätzliches zu DB2 und Performance Weiteres monitoring, um gegebenenfalls eine Historie des Performanceverhaltens zu haben, die dann mit zukünftigen Ergebnissen verglichen werden können 6. Ist die Performance nicht zufriedenstellend, gibt es folgende mögliche Aktionen: a. Bestimmen der hauptsächlichen Hemmnisse im System b. Bestimmen, wo man den höchsten Effekt und die höchste Ressourcenentlastung erhalten kann und will c. Tunen des Systems, indem die Charakteristiken gut justiert werden, um damit die Performance zu verbessern d. Zurück zu Schritt 3 und Durchführung weiterer monitoring Aktionen In bestimmten Zeitabständen oder signifikanten Änderungen an System oder der Systemlast sollte man zu Schritt 1 zurückkehren, die Zielsetzungen überprüfen und die monitoring - und Tuning-Strategien entsprechend verfeinern und anpassen Setzen von realistischen Performance Zielen Wie gute Performance für das jeweilige DB2 Subsystem definiert wird, hängt von den Anforderungen an das System und deren Priorisierung ab. Performanceziele sollten realistisch, innerhalb des Budgets liegend, verständlich und messbar festgelegt werden. Normalerweise schließen diese Zielsetzungen Werte für mit ein. Akzeptable response time (eine Zeit, innerhalb der ein bestimmter Prozentsatz aller Applikationen beendet sein sollte) Durchschnittlichen Durchsatz (die Gesamtzahl der Transaktionen / Queries, die innerhalb einer vorgegeben Zeit fertig werden) Systemverfügbarkeit, inklusive der mean time to failure und der Dauer der down times Ziele, wie diese, definieren auch die Last für das System und bestimmen die Anforderungen für Ressourcen, wie Prozessorgeschwindigkeit, Speichergrösse, zusätzlich erforderliche Software usw. Oft bestimmen die verfügbaren Ressourcen die maximale Grenze der akzeptablen Systemlast. Dies wiederum hieße, die Zielsetzungen neu zu überdenken. Service-level agreements(sla): Angenommen die User haben ein Mitspracherecht, was ihre Performanceziele angeht: Eine Vereinbarung auf Gegenseitigkeit für akzeptable Performance zwischen der IT Gruppe und den Benutzergruppen wird formalisiert und zum sogenannten Service-Level Agreement. SLA s können Erwartungen an query response time, den Durchsatz pro Tag / Stunde / Minute und Fenster für Batch Jobs ( inklusive utilities ) beinhalten. Diese Vereinbarungskriterien sind ein Anhaltspunkt dafür, ob ein System angemessene Performance ausweist Planung der Performance Überwachung Die Planung des monitoring von DB2 Performance sollte folgendes berücksichtigen: Einen generellen monitoring Terminplan. Große Batch Jobs oder Utility Läufe können zu Lastspitzen führen. Man sollte also monitoring mit anderen Operationen koordinieren, sodass keine Konflikte mit unüblichen Lastspitzen gibt, außer man will genau diese überwachen S.K.Consulting Services GmbH Seite 13 von 128

14 Kapitel 2: Grundsätzliches zu DB2 und Performance Die Art der Analyse, die erfolgen soll und die Art von Tools, die für das monitoring einzusetzen sind. Man sollte auch die Daten, die aus dem monitoring resultieren dokumentieren Einige Performance Reports kommen von den Produkten, die man für das monitoring nutzt: Tivoli Decision Support for z/os, OMEGAMON XE for DB2 Performance Monitor (DB2 PM), OMEGAMON (inklusive der Funktion DB2 PM), andere Reporting Werkzeuge oder eigene Programme, die Informationen aus Standardreports filtern Ein Team, das die Ergebnisse analysiert. Die Resultate des monitoring und die Folgerungen daraus sollten der User Support Group und den System performance Spezialisten zur Verfügung gestellt werden. Eine Strategie zum Tunen von DB2. Man sollte beschreiben, wie oft Änderungen erlaubt sind und auch die Standards, nach denen Folgewirkungen zu testen sind. Die Tuning Strategien sollten Bestandteil der regulären System Management procedures sein. Tuningempfehlungen können sowohl normale Datenbankänderungen aber auch Änderungen am Anwendungsdesign umfassen. Man sollte angelehnt daran die Entwicklungsrichtlinien aktualisieren, um so die gemachten Erfahrungen wiederzugeben und wiederholte Fehler zu vermeiden. Typischerweise enthält der Plan vier Ebenen des monitoring : Kontinuierliches Performance monitoring Periodisches Performance monitoring Detailliertes Performance monitoring Außergewöhnliches / Problem-. Performance monitoring Eine Performance Monitoring Strategie beschreibt in einem Plan, was zu tun ist und jede der genannten Ebenen Kontrolle und review der performancerelevanten Daten Die Analyse der Performance-Messdaten erfolgt, um festzustellen, ob die Performance die vorgegebenen Anforderungen erfüllt, um Problembereiche zu identifizieren und den monitoring Prozess auszuwerten. Wenn die Anforderungen definiert und der monitoring Prozess geplant wird, wird auch ein Plan erstellt, wie die performancerelevanten Daten ausgewertet werden sollen. Diese Daten sollten systematisch ausgewertet werden. Man sollte tägliche Daten wöchentlich und wöchentliche Daten monatlich betrachten. Birgt ein Report Auffälligkeiten, so muss er des Öfteren überprüft werden. Details sollten nur in Problemfällen untersucht werden. Ansonsten wird nur die Stimmigkeit der Reports in Bezug auf die historischen (Referenz-) Reports überprüft. S.K.Consulting Services GmbH Seite 14 von 128

15 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.2 Optimierungspotentiale bei DB2 Die Optimierungspotentiale bei relationalen Datenbanksystemen unterscheiden sich generell auch zwischen DB2 und Oracle, SQL Server und SYBASE - nur minimal. Sicher ist, dass die höchsten Potentiale, um diese relationalen Datenbanksysteme schneller zu machen, im Bereich der Abfragesprache SQL und damit im Umfeld der Anwendungsentwicklung und der Programme zu suchen ist (siehe Grafik unten). Weitere Fehlerquellen bzw. weitere Performancepotentiale liegen im physischen DB-Design, gefolgt von der Einstellung der Systemparameter im DB2 selbst und im Betriebssystem (OS/390, z/os, AIX, UNIX, Linux usw.) Empfehlenswert ist es natürlich im Tuningfall dort zuerst zu suchen, wo das größte Potential zum Lösen der Tuningaufgaben existiert. Man darf dann nur die anderen Bereiche nicht vergessen. In diesem Handbuch werden vorrangig die Problematiken der Sprache SQL und der damit zusammenhängenden Performance behandelt. Die Problematik des physischen Designs in DB2 findet man im Band "Physisches DB Design und DB2 Performance" aus dieser Reihe Tuning und Performance für DB2-Umgebungen. 2 = DB2 System (10%) 3 = phys. DB-Design Design (20%) 4 = Anwendung (60%) = OS System (10%) Bild-01: Tuningpotentiale bei DB2 S.K.Consulting Services GmbH Seite 15 von 128

16 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.3 Vorgehensweise beim Tuning von DB2 Grundsätzlich ist Tuning ein iterativer Vorgang: Schritt_1: Analyse der Details Schritt_2: Erarbeiten einer Lösung Schritt_3: Test der Lösung Schritt_4: Vergleich der Ergebnisse Wiederholung des Prozesses bis zum besten Resultat Bild-02: Vorgehensweise beim Tuning In allen Schritten ist jede mögliche Maßnahme zum Erreichen des Tuning-Ziels erlaubt Anhaltspunkte und Analysedaten für Tuning Anhaltspunkte für Tuning bieten bei DB2 für z/os folgende Messdaten 1. Elapsed Time Analysis und Tuning 2. CPU Time Tuning: Aufwand für Select, Insert, Update, Delete, Dynamic Bind, DB2 Traces, Distributed/ Stored Procedure, DB2 Data Compression 3. Buffer Pool, Locking, EDM Pool, Work File, LOB, DBM1 Virtual Storage Accounting und statistics records Alle accounting und Statistikdaten sind bei DB2 relativ einfach und kostengünstig zu erhalten. Sie sind vor allem nützlich für ein kontinuierliches Monitoring der Performance und das daraus erforderliche Tuning. Für eine erste Analyse genügen meistens: Der Accounting report (nicht trace ) pro connection type oder Plan und Der Accounting Report (nicht trace ) für dieselbe Zeitspanne Diese Fakten sollten die ersten sein, die betrachtet werden, wenn ein DB2 Performance Problem auftaucht. Beispiel: DB2PM Command Eingabe zum Erhalt der entsprechenden passenden Daten: DB2PM DB2PM DB2PM STATISTICS REPORT LAYOUT (LONG), und ACCOUNTING REPORT LAYOUT (LONG) ORDER (CONNTYPE) EXCLUDE (PACKAGE(*)) zur Gruppierung über thread connection type, wie TSO, CICS, DB2CALL, IMS, APPL- DIR, SYST- DIR, usw., oder ACCOUNTING REPORT LAYOUT (LONG) ORDER (PLANNAME) und INCLUDE (DB2ID (xxxx)) FROM (03/ 11/ 00,10: 00: 00.00) TO (...) Weitere Anhaltspunkte zur Analyse der DB2-Faktoren unter Pkt Fehler! Verweisquelle konnte nicht gefunden werden. ff. S.K.Consulting Services GmbH Seite 16 von 128

17 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.4 Grundvoraussetzungen für DB2/UDB Performance 1. Stellen Sie sicher, dass genügend Plattenplatz vorhanden ist. (6-10 Laufwerke pro CPU ist für den Anfang genug). Jeder "Tablespace Container" sollte alle verfügbaren Platten erreichen können. Einige "tablespaces", wie zum Beispiel SYSCATSPACE und alle mit einer geringen Anzahl von Tabellen sollten nicht über alle möglichen "Disks" gestreut werden, wogegen die TS mit einer großen Userzahl oder auch "temporary tables" möglichst über den gesamten "Diskpool" gestreut sein sollten. 2. Bufferpools sollten einen Nutzungsgrad des verfügbaren Speichers von ca. 75% (bei OLTP Anwendungen) oder 50% (bei OLAP Anwendungen) ausweisen. 3. RUNSTATS sollte auf allen Tabellen, inklusive der Systemtabellen (Katalog) durchgeführt sein. Gegebenenfalls sollte man den "Design Advisor" nutzen, um eine Empfehlung und ein "review" für die Indizes bezüglich ihrer SQL" workloads" zu erhalten. 4. Man kann auch den "Configuration Advisor" nutzen, um den "Database Manager" und die Datenbank für die entsprechenden Applikationen zu konfigurieren. 5. Logging sollte auf separaten "high-speed Disks" erfolgen 6. "Concurrency" kann durch häufige "commits" verbessert werden (SQL Statement Tuning). Der Parameter SORTHEAP/SORTHEAPSIZE sollte höher eingestellt werden, um so "sort overflows" zu vermeiden 7. Der Tablespace Typ für den "System catalog table space" sollte ein eigener SMS-Pool oder sogar ein eigener (schneller) Plattentyp sein. 8. "Temporary table spaces", work TS und "DMS raw (device)" oder "Files" sollten ebenfalls separat definiert sein. 9. Man nutze "parameter markers" für sich wiederholende (dynamic) SQL- Statements (SQL Statement Tuning). 2.5 Voraussetzungen für die Performance in SQL bei DB2 Es ist bekannt, dass sich Tuning- und Performance-Maßnahmen auch bei relationalen Systemen bis auf die Applikationsentwicklung auswirken. Es gilt auch hier, dass die ineffiziente Nutzung von Systemressourcen durch Anwendungsprogramme über systemtechnische Einstellungen nicht korrigiert werden kann. Entwickler müssen deshalb: Verständnis für die Interna der DB2-Umgebung besitzen ein tiefes Wissen über DB2-Tuning-Ansätze und Optimizer-Verhalten haben Das Fundament für gute Performance kann nur über entsprechende Maßnahmen beim System-Design in Daten- und Funktionsentwurf erreicht werden S.K.Consulting Services GmbH Seite 17 von 128

18 Kapitel 2: Grundsätzliches zu DB2 und Performance Weitere den Leistungsdurchsatz und Performance beeinflussende Faktoren sind: 1. Bestimmte Benutzergruppen Die grob einzuteilenden Benutzergruppen, die diese Frage aus der Sicht des Anwenderverhaltens problematisch werden lassen, sind End-User mit allen Erwartungen/Anforderungen in allen denkbaren und nicht planbaren Datenkonstellationen mit komfortablen Oberflächen mit guten, unverzüglichen Antwortzeiten mit permanenter Verfügbarkeit Anwendungsentwickler mit ihrer Qualifikation mit dem Wissen über Vorgehensmethoden und techniken mit dem Verständnis komplexer Zusammenhänge mit Verständnis für interne, systemtechnische Zusammen-hänge und Konsequenzen unter dem Aspekt des Einsatzes und der Handhabung von Tools Administratoren mit ihrem Qualitätsanspruch Planung und Kontrolle optimierter Ressource-Nutzung Sicherstellen aller möglichen und notwendigen security -Aspekte Nutzung effizienter und sicherer Administrationswerkzeuge 2. Methodeneinsatz In den aus der Praxis entlehnten Erfahrungen mit Performanceproblemen weisen die meisten auf unsystematisches Vorgehen in der Anwendungsentwicklung hin (siehe auch Grafik im Kapitel DB2 Anwendungsentwicklung / Pkt. I: Übersicht). Sinnvollerweise sollte beim Vorgehen in der AE (= Anwendungsentwicklung ) auf folgende Faktoren besonderes Augenmerk gelegt werden: Einsatz einer fundierten Vorgehens- und Systementwicklungsmethodik und deren Kontrolle Festlegung objektivierbarer und sinnvoller Performance- Zielsetzungen Permanente Berücksichtigung aktueller Performance-Erkenntnisse 3. Technologie-Einsatz Hoher Komfort verlangt nach hohem Ressourceneinsatz. Dennoch sollen die Ressourcen angemessen sein. Übergroße Schuhe hindern einen am Laufen ebenso wie zu kleine... Dabei ist es entscheidend, dass auf keiner der unterschiedlichen Ressourcenund Technologieebenen Engpässe auftreten: angemessene Hardware abgestimmtes Betriebssystem und systemnahe Software moderater Einsatz von Standard-Software-Systemen Unterstützung von Individualanwendungen Nutzung von Performance-Tools S.K.Consulting Services GmbH Seite 18 von 128

19 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.6 Möglichkeiten und Maßnahmen zur (SQL-)Optimierung Wie in jedem Datenbanksystem sind auch bei DB2 die Tuningmöglichkeiten auf einige, aber komplexe und sinnvolle Maßnahmen beschränkt. Die Tuningmaßnahmen in den einzelnen Bereichen gehorchen jedoch den allgemeinen Gesetzen des Systemtunings und diese sind: 1. Performance entsteht nicht von selbst! 2. Performance ist niemals statisch! 3. Performance ist zu definieren und damit PLANBAR 4. "benchmarks" sind meist SUBJEKTIV und damit im Einzelfall NICHT aussagefähig!!!!! 5. Performance wird erreicht durch das Zusammenwirken mehrerer (annähernd) GLEICHWERTIGER Faktoren: a) realistisches, "sauberes" Informationsmodell b) optimale Umsetzung in die physische Umgebung c) systematische Anwendungsentwicklung d) effiziente Anwendungsprogramme e) optimale Einstellung der DBMS-Parameter f) entsprechende Änderung der OS-Parameter g) ständige Überwachung der Produktionsumgebung - Datenadministration - Datenbankadministration - "Monitoring" h) entsprechender Hardware-Einsatz Die Tuning-Möglichkeiten bei DB2 lassen sich so grob unterteilen in: Systemtechnische Aktivitäten Anwendungsbezogene Maßnahmen Tuningpotentiale des DB2-Systems S.K.Consulting Services GmbH Seite 19 von 128

20 Kapitel 2: Grundsätzliches zu DB2 und Performance Systemtechnische Aktivitäten Zu den systemtechnischen Maßnahmen, die in den direkten Zuständigkeitsbereich der Datenbankadministratoren (DBAs) beispielsweise für DB2/MVS fallen, gehören: Optimierung der Generierungsparameter für MVS, CICS, IMS-DB und TSO. Autorisierungskonzept. Connection- und Thread-Nutzung Optimierung der Generierungsparameter für DB2, wie z.b.: Bufferpool-Größe und Nutzung EDM-PooI-Größe Lock-Definitionen (IRLM) LOG-Definitionen. Festlegung der Optionen für physische DB2-Objekte, wie z.b.: Storage group / User defined VSAM-Datasets DB2-Databases Tablespaces Indizes Packages, Collections und Pläne. Re- bzw. Umorganisation der physischen Datenspeicherung. Anlegen, Ändern oder Löschen von Indizes. Beeinflussung des DB2-Zugriffspfades durch Manipulation von Katalog- Statistik-Spalten. Permanente Überwachung des Systemverhaltens, Starten von Utilities, wie z.b. RUNSTATS, Durchführung gezielter REBIND-Maßnahmen Anwendungsbezogene Maßnahmen Unter anwendungsbezogenen Maßnahmen versteht man: logische und physische Datenmodellierung mit Festlegung der Benutzer- DB2-Objekte (auch Denormalisierung, falls erforderlich). Einsatzentscheidungen für: Tabellen, Views, Synonyme und Aliase. Veränderungen der Datenablage mit Auswirkung auf die logische Ebene (z.b. Aufteilen langer Zeilen, Kompression, Änderung von Datentypen). Festlegung und Test von SQL-Statements (z.b. durch EXPLAIN nach Ausführung von RUNSTATS). Umschreiben von Queries (Abfragen und Manipulationen) in effizienterer Form. Festlegung von "constraints", "triggers", UDF s und Prozeduren S.K.Consulting Services GmbH Seite 20 von 128

21 Kapitel 2: Grundsätzliches zu DB2 und Performance Die Tuningpotentiale des DB2-Systems Die Tuningpotentiale des DB2-Systems selbst liegen vor allem in folgenden Bereichen: MVS-Prioritäten-Steuerung Adressraum-Nutzung Paging/Swapping Interne Ressource-Nutzung Generierungsparameter(ZPARMS) Connection/Thread-Nutzung Anzahl parallele Threads Autorisierungs-Konzepte MVS- und DB2-Systemparameter Cross-Memory- und System-Kommunikation Bufferpool-Größe und Nutzung LOG-Management LOCK-Management Interne Ressource-Nutzung: - Anzahl intern zu haltender Zeilen (Materialisierungen) Definition der Daten-Zugriffspfade: - Einfache Zugriffspfade - Page Set Scan, Index-Nutzung - Komplexe Zugriffspfade - Join, Subqueries Filtermöglichkeiten und Aufwand bei der Bearbeitung vorgegebener SQL- Prädikate. Anzahl zu übertragender Pages = Cl s VSAM-Optionen DB2-DDL-Optionen Page-Nutzung Freespace-Zuordnung Daten-Zusammenlegung Daten-Verteilung(DDF) Speicherhierarchien Index-Definition und Nutzung IRLM - - Services System- Services Database- Services DDF- DDF- Services Andere Trägersysteme VSAM Bild-03: Die DB2-Services im Überblick S.K.Consulting Services GmbH Seite 21 von 128

22 3 SQL - Die Structured Query Language bei DB2 SQL besteht aus folgenden Kategorien, die sich wiederum in ihren Sprachelementen unterscheiden: DDL DML DCL Data Definition Language Data Manipulation Language Data Control Language DDL DML DCL CREATE SELECT GRANT DROP INSERT REVOKE ALTER UPDATE LABEL DELETE COMMENT COMMIT / ROLLBACK Bild-04: Übersicht über die SQL-Sprachelemente Während DDL und DCL in Richtung des "environment management" von DB2 zielen, kann die DML als das User-Interface der Sprache SQL bezeichnet werden. Dabei ist nicht die Menge der Sprachelemente entscheidend, sondern deren Kombinierbarkeit. Sie macht die Mächtigkeit von SQL aus. DB2 deckt damit die DML-Anforderungen im Relationenmodell ab: Es gibt keine Auswirkung der physischen Speicherungsgegebenheiten auf - die Formulierung von SQL, z. B. TS-Formen, Indizes usf. - SQL als nicht-prozedurale Sprache - die Qualität von DB2-SQL: alle Sprachelemente sind Mengenoperationen Und: SQL enthält Sprachkonstrukte für Projektion, Selektion, Join. SQL bietet eine Vielzahl "eingebauter Funktionen" ("builtin functions" und "scalar functions" ) für bool sche Operationen, für spezielle Prädikate und "date / time" - Arithmetik. Fast alle SQL-DML-Befehle können in Form von "views" abgelegt werden. Die wichtigsten Sprachelemente der SQL-DML finden Sie in der folgenden Übersicht: S.K.Consulting Services GmbH Seite 22 von 128

23 Kapitel 3: SQL Die Structured Query Language bei DB2 Lesen SELECT eingebaute Funktionen SUM Ändern INSERT MAX, MIN, AVG UPDATE DISTINCT DELETE COUNT TRUNCATE Gruppieren spezielle Aussagen UNION GROUP BY INTERSECT, EXCEPT HAVING MERGE LIKE, IN, ANY, ALL BETWEEN EXISTS Sortieren ORDER BY Bool sche Operatoren AND OR NOT Sperren LOCK Arithmetische Operatoren Vergleichsoperatoren +, - =, >=, <= /, * ^=, ==, <> ( ) >, < Spez. Arithmetik YEAR, MONTH, DAY, DAYS "Scalar Functions" HOUR, MINUTE, SECOND, LENGTH, VALUE, SUBSTR, MICROSECOND, CHAR, INT, HEX, DEC, CURRENT FLOAT, DIGITS, DATE, TIME, DAY, CAST, BINARY, TIMESTAMP, WEEK, NULLIF, CASE, MONTHS DECFLOAT, BIGINT, COALESCE Weitere Funktionen(Beispiele): CLOB, BLOB ABS, ROUND, ACOS, ASIN, "Table Functions" ATAN, COS, MQREADALL, LOWER, UPPER MQRECEIVEALL LTRIM, RTRIM, WITH RAND, REPEAT SIGN, STRIP, TAN, TRUNC, RANK() ROWID, INCLUDE, ROW_NUMBER... Bild-05: Grobe Übersicht über die SQL-Funktionen Eine Liste aller derzeit in DB2 implementierten builtin-functions mit Beispielen ist im Anhang unter Pkt ff. zu finden. 3.1 Relationale Sprachelemente und Operationen bei SQL SQL nutzt algebraische Mengenfunktionen zur Qualifikation der Daten. Die Grundelemente sind dabei: PROJEKTION SELEKTION JOIN Auswahl bestimmter Spalten Auswahl bestimmter Zeilen aufgrund von Dateninhalten - auch anhand verknüpfter Suchkriterien Zusammenführen von Daten aus mehreren Tabellen S.K.Consulting Services GmbH Seite 23 von 128

24 Kapitel 3: SQL Die Structured Query Language bei DB Die relationale Funktion "SELEKTION" Die Funktion "SELEKTION" meint in der relationalen Algebra die Auswahl bestimmter Zeilen, z. B. aus TAB A A B C D E a1 b1 c1 d1 e1 a2 b2 c2 d2 e2 a3 b3 c3 d3 e3 a4 b4 c4 d4 e4 ergibt A B C D E a2 b2 c2 d2 e2 a4 b4 c4 d4 e4 In SQL lautet die Formulierung: SELECT * FROM TABA WHERE A = 'a2' OR A = 'a4' Bild-06: Die Selektion im RDB-Modell S.K.Consulting Services GmbH Seite 24 von 128

25 Kapitel 3: SQL Die Structured Query Language bei DB Die relationale Funktion "PROJEKTION" Die "PROJEKTION" im Sinne der relationalen Algebra bedeutet die Auswahl bestimmter Spalten aus einer Relation, z.b. Spalte A, C, D A B C D E a1 b1 c1 d1 e1 a2 b2 c2 d2 e2 a3 b3 c3 d3 e3 a4 b4 c4 d4 e4 ergibt a) A C D a1 c1 d1 a2 c2 d2 a3 c3 d3 häufig erfolgt auch eine a4 c4 d4 Mischung aus Selektion und Projektion In SQL lautet die Formulierung: ergibt b) A C D a2 c2 d2 a4 c4 d4 a) SELECT A, C, D b) SELECT A, C, D FROM TABA FROM TABA WHERE A = 'a2' OR A = 'a4' Bild-07: Die Projektion im RDB-Modell S.K.Consulting Services GmbH Seite 25 von 128

26 Kapitel 3: SQL Die Structured Query Language bei DB Die relationale Funktion "JOIN" Die Funktion JOIN basiert auf dem Verbinden von Tabellen = Bilden des kartesischen Produkts. Diese Mengenfunktion ist mathematisch korrekt, aber informationstechnisch von minderem Wert. Deshalb bildet man bei SQL-JOINs nicht das kartesische Produkt, sondern vielmehr eine Intersektionsmenge (= Durchschnittsmenge). Dazu muss der Anwender wissen, über welche Attribute (Spalten) die Verbindung zur jeweils anderen Tabelle hergestellt werden kann. Zusammengesetzte Schlüssel müssen dazu vollständig qualifiziert werden. Im Beispiel wird über A verknüpft. TABA A B C D E a1 b1 c1 d1 e1 a2 b2 c2 d2 e2 a3 b3 c3 d3 e3 a4 b4 c4 d4 e4 nicht im Ergebnis (out of join) TABB F G H ergibt als karthesisches Produkt die Permutation aus beiden Tabellen - als JOIN Menge aber folgendes Resultat: a1 g1 h1 a2 g2 h2 a4 g3 h3 A B C D E F G H a1 b1 c1 d1 e1 a1 g1 h1 a2 b2 c2 d2 e2 a2 g2 h2 a4 b4 c4 d4 e4 a4 g3 h3 In SQL lautet die JOIN-Formulierung: SELECT * FROM TABA, TABB WHERE TABA.A = TABB.F Bild-08: Der Join im RDB-Modell S.K.Consulting Services GmbH Seite 26 von 128

27 Kapitel 3: SQL Die Structured Query Language bei DB Relationale Mengenoperationen-Zusammenfassung Alle Mengenoperationen des Relationenmodell sind in genau diesem beschrieben und diese sind als die folgenden relationalen Operationen in SQL formulierbar. Untermenge ( SELECTION, PROJECTION ) Schnittmenge ( (INNER) JOIN, INTERSECT ) Vereinigungsmenge ( UNION, FULL OUTER JOIN ) Ausschlussmenge (... NOT IN... NOT EXISTS.., LEFT oder RIGHT OUTER JOIN mit NOT <op>) Differenzmenge (EXCEPT ) Bild-09: Funktionen im RDB-Modell (Zusammenfassung) S.K.Consulting Services GmbH Seite 27 von 128

28 Kapitel 3: SQL Die Structured Query Language bei DB2 3.2 Generelle Überlegungen und Voraussetzungen für SQL Performance In diesem Kapitel werden zunächst einige Basisfragen zum Thema "Do's and Don'ts bei DB2 SQL" behandelt und damit soll mit einigen Gerüchten von vorneherein aufgeräumt werden Dynamic SQL Dynamisches SQL ist zunächst kein Problem aber die mehrfache Nutzung desselben SQL-Statements kann zu unnötigen Verzögerungen im Vergleich zu statischen SQL-Anweisungen führen. Deshalb sollten dynamische SQL-Anweisungen in einem speziellen Cache abgelegt werden. In diesem Fall prüft das DB2 erst den Cache-Inhalt, wenn ein PREPARE öfter dasselbe SQL-Statement benötigen sollte. Wird das SQL-Statement im Cache gefunden, kann es wieder verwendet werden und das System erspart sich einen overhead von bis zu 80% CPU Verbrauch für zusätzliche Prepare's. Benutzt man aber das so genannte dynamic SQL-Caching dann muss der EDM- Pool ebenfalls entsprechend angepasst werden. EDM-Pool Statistiken helfen das Caching zu tunen (siehe IFCID-Informationen). Wichtig ist es zudem, dass die SQL Queries dann als "parameter marked" Queries an das DB2 gegeben werden. Das bedeutet nichts anderes, als dass keine "hostvariablen direkt in die Query-Formulierungen eingebettet werden sollen, sondern alle Stellen, an denen eine Hostvariable stehen kann mit einem "?" vorbelegt werden. Dann wird prepared und das nur EINMAL, da DB2 erkennt, dass es sich bei diesem mini-plan immer um dasselbe SQL-Statement handelt. Beispiel: SELECT... Parametermarker FROM tab t WHERE t. c1 >? AND t.c6 BETWEEN? AND? Bild-10: Dynamic SQL - Parametermarker Erst der Aufruf der Query versorgt die "Parametermarker" mit Variablenwerten: EXECUTE sql_statement USING :hvc1, :hvc61, :hvc62; Datenbankobjekte und ihre Struktur Oft trifft man gerade in Standardsoftware-Umgebungen schwierige und riesige Anzahlen von DB-Objekten an. DWH- und/oder SAP-Anwendungen erzeugen für sich oft mehr als Objekte. In der Version DB2V8 installiert beispielsweise Peoplesoft mit seiner Anwendung alleine 5 eigene DB2-Datenbanken(!). Nun stellt in DB2 eine Datenbank nicht ein physisches Objekt dar, sondern eine "DB2 Database" bedeutet vielmehr eine Unterteilung der gesamten DB2-Objekte in kleinere überschaubare Mengen von Objekten. Empfehlenswert wären nicht mehr als 20 Tablespaces pro "Database". Der Grund hierfür ist die Größe des DBD ( Database Descriptor ). DBD-Sperren erfolgen bei DB2 auf Datenbank-Ebene. Der DBD ist es auch, der, wann immer Ände- S.K.Consulting Services GmbH Seite 28 von 128

29 Kapitel 3: SQL Die Structured Query Language bei DB2 rungen erfolgen, auf die Log-Datei geschrieben wird. Der DBD muss im Speicher resident sein und im EDM-Pool in einem zusammenhängenden Speicherabschnitt liegen Tabellen und Tablespaces Bei einer großen Menge von Tabellen, so ab ca Tabellen, sollten die Daten in Gruppen eingeteilt werden. I/O Strategien und die Verwaltbarkeit der DB- Umgebung bestimmen das physische Design mit. Obwohl multiple table Tablespaces einfach zu implementieren sind, sind doch einige Punkte bezüglich Größe und physischer Strukturierung zu beachten und empfehlenswert: Anzahl pages n > n > Tablespace Typ Partitionieren eine einzelne table pro segmented TS reicht 128 < n < mehr als eine Tabelle in einem segmented TS n < 128 mehr als eine Tabelle in einem segmented TS Bild-11: Übersicht über Strukturierungsempfehlungen zum TS Aber: 100 Tabellen für einen shared segmented TS sollten das Maximum sein. Extrem wichtig in diesem Zusammenhang ist auch die Größe der TB-Segmente. Anzahl pages n <= 28 SEGSIZE 4 bis 28, ähnlich der Anzahl pages 28 < n < n >= Bild-12: Übersicht über Segmentierungsempfehlungen zum TS Alle gruppierten Tabellen sollten sorgfältig dahingehend untersucht werden, ob sie sich in ihren fundamentalen Charakteristiken ähneln. Manche Arbeits- und temporäre Tabellen (gerade von Softwareherstellern wie z. B. Peoplesoft, SAP usw.) haben sehr unterschiedliche Eigenschaften. Diese können sein: Daten für die Clients "Codetabellen" Referenzen und lookup tables TS größer als pages sollten als PTS definiert werden. Die Gesamtgröße eines STS sollte kleiner pages sein, um unnötige "prefetch"-aktivitäten zu vermeiden. S.K.Consulting Services GmbH Seite 29 von 128

30 Kapitel 3: SQL Die Structured Query Language bei DB2 Eine Methode hier gegenzusteuern wäre es, sicherzustellen, dass der VPSEQT Parameter auf 0 gesetzt ist und somit diese "prefetch"-aktivitäten weitgehend ausgeschaltet sind. Zusätzlich sollte die queueing Methode auf FIFO gesetzt werden (ab DB2V6), um Overhead für das latch -Management zu vermeiden Indexe Index-Tuning ist eine Aufgabe, die in allen DB2-Installationen und Subsystemen dringend zu empfehlen ist. Viele Indexe beispielsweise umfassen nicht die erforderlichen Spalten, um die Wahl eines besten Pfades für den Optimizer zuzulassen: Einige Indizes enthalten die Spalten in der falschen Spaltenreihenfolge oder in der falschen Sortierreichenfolge. Gerade für JOIN-Operationen aber, sind gute und optimale Indexe unerlässlich Primary und Clustering Indexes Einmal gesetzte Primary Indexes sollten nicht mehr verändert werden (auch nicht bei SAP, Peoplesoft oder anderer Fremd- bzw. Standardsoftware). Änderungen am PI gefährden nicht nur die Eindeutigkeit der Daten, sondern können auch RI- Bedingungen massiv (negativ) betreffen. Ebenso sollte der clustering Index sorgfältig ausgewählt werden. Nicht immer ist es geschickt den PK/PI auch als clustering Index einzusetzen, obwohl dies bei vielen Unternehmen als Quasi-Standard gilt Index Only -Zugriffe auf VARCHAR Spalten Wegen der vermehrten Nutzung von VARCHAR-Spalten im Index, wurde nach der Version 5 ein Feature für Index Only -Zugriffe auf solche Felder implementiert. Dies ist nur möglich, da die Längeninformation dieser Spalten nun in den Index mit aufgenommen wird. Somit kann auch auf indizierte VARCHAR-Felder zugegriffen werden, ohne dazu die Datenpage lesen zu müssen. Dabei wird abhängig von der Länge der eingetragenen Werte die maximale Länge mit Leerzeichen aufgefüllt. Gesteuert wird dies über den neuen DSNZPARM RETVLCFK=YES. Dazu müssen bei der Migration auf die Versionen 6 oder 7 die Anwendungsprogramme neu mit BIND behandelt werden. Bei der Migration auf DB2 Version 8 ist ein REBIND für alle Programme empfohlen. In der DB2 Version 8 gibt es zum Thema VARCHAR- und Indexverarbeitung weitere Verbesserungen ("padding"), sodass sich einige Nachteile der Nutzung von VARCHAR-Spalten im Index relativieren Verzögerte Objektdefinitionen Seit der DB2 Version 6 gibt es ein neues Feature, das es zulässt, TS und Indizes für einen späteren CREATE zu definieren. Dies geschieht mit dem Parameter DEFER. Im Gegensatz zu früher (vor DB2 V6), müssen nun nicht mehr alle TS und Indexes zum Zeitpunkt der Installation eines Systems (SAP, Peoplesoft...) definiert sein. Dies war früher unabdingbar, auch wenn diese Indizes noch nicht genutzt wurden. Das soll nun Installationsvorgänge beschleunigen und die DBA einfacher machen. S.K.Consulting Services GmbH Seite 30 von 128

31 Kapitel 3: SQL Die Structured Query Language bei DB Aufwand und Kosten von Indexes Bevor man mit dem Anlegen von Indexes beginnt, sollte man sich Gedanken über den Aufwand zur Pflege dieser Indexes machen: Indexes benötigen Speicherplatz - große Indexes benötigen viel Speicherplatz. Jeder Index benötigt einen eigenen Indexspace und darunter liegende VSAM Datasets. Es existiert eine Einschränkungen in der Anzahl der offenen Datasets im z/os Betriebssystem (1000 Address Spaces (=Default)). Ein Index muss bei jeder Datenänderungen mit gepflegt werden, um die Änderungen in seinen Basistabellen zu reflektieren. Wenn eine UPDATE SQL- Anweisung eine Spalte verändert und die Spalte Bestandteil eines Index ist, muss der Index ebenfalls verändert werden. Die Gesamtzeit für die Pflege der Daten steigt somit entsprechend. Indexes müssen während des Ladens einer Table erstellt werden - das kostet Zeit. Sie müssen und können aus ihrer Basis-Tabelle wiederhergestellt werden, wenn der Tablespace wiederhergestellt werden muss, dies verbraucht ebenfalls zusätzlich Zeit. Indexes können seit DB2 V7/V8 mit der Funktion REBUILD jederzeit aus den Daten der zugehörigen Tabelle wiederhergestellt werden. Nachdem diese Funktion dem Utility REORG beigeordnet ist, ist es mehr als hilfreich, dass dieser im online -Modus laufen kann, d.h. der laufende Betrieb von DB2 wird während der REORG-Zeit kaum behindert. Empfehlung: Das Design der Indexe sollte Bestandteil des Database Design sein und keinesfalls vernachlässigt werden. Treten bei SQL-Anweisungen Performanceprobleme auf, stellt man sich bezüglich der Indizierung zunächst folgende Fragen: 1. Würde das Hinzufügen einer Spalte zu einem bestehenden Index einer Anweisung erlauben Index-Only-Zugriffe zu nutzen? 2. Wird ein neuer Index benötigt? Ist er sinnvoll? 3. Ist der (bisherige) Index-Aufbau korrekt? Empfehlungen zu Sortierungen Häufig kann man Sortierungen vermeiden, wenn Index Keys in der Reihenfolge vorliegen, die in ORDER BY, GROUP BY, einer Join-Operation, oder bei einem DISTINCT in einer Column-Funktion benötigt werden. In anderen Fällen, beispielsweise bei Einsatz des List Sequential Prefetch stehen im Index keine sinnvollen Sortierungen zur Verfügung und die selektierten Daten müssen zwangsläufig sortiert werden. Sollte es zwingend erforderlich sein, Sortierungen zu verhindern, so sollte man die Anlage eines passenden Index für die erforderlichen Spalten erwägen und gegebenenfalls die OPTIMIZE FOR n ROW- Anweisung einsetzen (siehe auch Pkt. Fehler! Verweisquelle konnte nicht gefunden werden. ff). S.K.Consulting Services GmbH Seite 31 von 128

32 Kapitel 3: SQL Die Structured Query Language bei DB2 Beispiel: SELECT C1, C2, C3 FROM T1 WHERE C1 > 1 ORDER BY C1 OPTIMIZE FOR 1 ROW; Ein aufsteigender Index auf der Spalte C1 kann eine Sortierung vermeiden helfen. Ein Index auf C1 + C2 + C3 erfüllt den gleichen Zweck, ermöglicht aber gleichzeitig einen Index-Only-Zugriff. Man beachte in diesem Zusammenhang auch die Hinweise im Abschnitt "Aufwand und Kosten von Indexes", bevor mit neuen Indizes versucht wird, Sort-Operationen zu vermeiden: Nicht alle Sorts bedeuten eine Behinderung. Ist beispielsweise ein Index nicht effizient genug und werden sehr viele Rows qualifiziert, kann der Optimizer einen anderen Zugriffspfad wählen und stattdessen die Daten ohne Indexzugriff selektieren, anschließend sortieren, und damit u. U. erheblich kostengünstiger arbeiten. Faktoren, die man beachten muss, weil sie die Sort-Performance beeinflussen und Techniken, die Sorts verbessern können, sind: die eingesetzten Prädikate sollten die Daten liefern, die man benötigt: Jede Einschränkung eines Auswahlergebnisses, die Reduzierung des Result Sets, usw. reduziert auch den Sort-Aufwand. wenn Sorts durchgeführt werden, hängt die Row-Länge von der Anzahl der selektierten Ergebnisspalten ab. Die Reduktion der Spalten erhöht die Performance eines Sortvorgangs, wobei vor allem der Umfang der Daten und des Work spaces eine Rolle spielen. Generelle Vorschläge zur Reduzierung der Sort-Row-Länge: 1. 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. Anmerkung: Dies gilt seit DB2 V8 nicht mehr IX können nun gepadded sein, d.h. die Blanks werden nicht mehr im IX gespeichert. 2. Minimieren der Anzahl von Sort Key Columns, 3. Minimieren der Anzahl der Sort Data columns. Workfiles verfügen über ein vielfältiges Einsatzspektrum und haben eine Wechselwirkung zur Sort-Performance. Es gilt über Global Temporary Tables und Materialized Views nachzudenken. Der Systemadministrator sollte ausreichend physischen Platz bereitstellen und diese Work spaces in einen eigenen Bufferpool legen. Die Isolierung von anderen Objekten vereinfacht das Monitoring und Tuning der Sort-Performance. Anwendungen die Global Temporary Tables (GTT s) nutzen, belegen Workfile-Space bei einem COMMIT oder ROLLBACK. Wenn Sorts und GTT- Nutzung gleichzeitig erfolgen, dann benötigt man sehr wahrscheinlich mehr Work-Space. Der Systemadministrator sollte die Bufferpool-Größe für Workfile Buffers erhöhen, wenn die Prefetch Rate 4 Pages oder weniger beträgt. S.K.Consulting Services GmbH Seite 32 von 128

33 Kapitel 3: SQL Die Structured Query Language bei DB2 Bei der Nutzung von STOGROUP s sollte nur jeweils ein Volume je Storage Group genutzt werden. Zusätzliche Volumes werden erst genutzt, wenn das erste Volume vollständig belegt wurde. Nie mehr als ein physisches Workfile Dataset je DASD Volume anlegen. Die Größe des Sort Bufferpool beeinflusst die Sort-Performance. Je größer der Buffer, desto größer die Effizienz von Sorts. Die Planung der Konfiguration sollte so erfolgen, dass minimale I/O Contention auf den I/O Paths zu den physischen Workfiles sicherzustellen. Eine Verteilung der Workfiles auf unterschiedliche Disk Paths hilft meist. Sind Statistiken nicht aktuell, sollte man diese mit dem RUNSTATS Utility auf den aktuellen Stand bringen SQL-Abfragen mit Subqueries Nutzen Sie Input (Host) Variablen in Prädikaten Ihrer Static SQL Query? Variable wie Parameter-Marker erlauben keine Auskunft über mögliche Werte zur BIND- und Ausführungszeit. DB2 nutzt deshalb den sog. Filterfaktor um den besten Zugriffspfad für ein SQL-Statement zu bestimmen. Wenn sich dieser Zugriffspfad als ineffizient herausstellen sollte, könnte man eine erneute Überprüfung (REOPT) für langlaufende Queries (>10 secs Elapsed Time) zur Laufzeit veranlassen. Das Binden mit EXPLAIN-Option veranlasst ein "Static Explain". Um bereits vor dem Bind den voraussichtlichen Zugriffspfad von Explain ermitteln zu lassen, also einen "Dynamic EXPLAIN" auszuführen, extrahiert man das jeweilige Statement aus dem Programm und ersetzt die Host-Variablen durch Konstante. Der "Dynamic Explain" wird sich dann wie ein "Static Explain" verhalten correlated vs non-correlated Subqueries Unterschiedliche Subquery-Typen verlangen auch nach unterschiedlichen Vorgehensweisendiese für eine effiziente Verarbeitung durch DB2 zu verbessern. Alle Subqueries können über zwei Kategorien klassifiziert werden: correlated subqueries und non-correlated subqueries Correlated subqueries Correlated subqueries enthalten einen Verweis auf eine Tabelle bzw. eine Spalte, die ausserhalb der Subquery benutzt/definiert ist. Im folgenden Beispiel ist X ein Wert aus einer Tabelle, die sich nicht in der FROM Klausel der Subquery wiederfindet. Der Einschluss von X zeigt, dass die Subquery auf den äusseren Block verweist: Bild-13a: correlated subquery SELECT * FROM DSN8910.EMP X WHERE JOB = DESIGNER AND EXISTS ( SELECT 1 FROM DSN8910.PROJ WHERE DEPTNO = X.WORKDEPT AND MAJPROJ = MA2100 ); S.K.Consulting Services GmbH Seite 33 von 128

34 non-correlated Subqueries Non-correlated subqueries verweisen dagegen auf keinerlei Tabellen / columns ausserhalb des eigenen Subquery-Blocks. Die folgende Beispielquery verweist also nur auf tabellen im Umfeld der eigenen FROM Klausel:. SELECT * FROM DSN8910.EMP WHERE JOB = DESIGNER AND WORKDEPT IN ( SELECT DEPTNO FROM DSN8910.PROJ WHERE MAJPROJ = MA2100 ); Bild-13b: non-correlated subquery Komplexität von Queries Man sollte sicherstellen, dass die SQL Query so einfach und effizient wie möglich formuliert ist. Die Auswahl nicht benötigter Spalten und unnötige ORDER BY oder GROUP BY Anweisungen sind unbedingt zu vermeiden. Dennoch sollte man diese Aussage nicht missverstehen und SQL-Funktionen oder gar relationale Funktionen selbst programmieren. DB2 wird in jedem Fall jede Datenbankaufgabe schneller lösen können, als eine vergleichbare programmierte Sequenz. wer kennt schon die DB-Umgebung besser als das System DB2 selbst? Spalten-Funktionen Werden Column Functions eingesetzt, sollten diese so einfach wie möglich gestaltet sein, damit die Wahrscheinlichkeit, dass sie bereits aufgeführt werden, wenn die Daten beschafft werden, und nicht erst im Anschluss daran, möglichst hoch ist. Grundsätzlich kann man sagen, dass Column Functions am effizientesten sind, wenn sie nicht erst während der Sort-Phase des Statements ausgeführt werden. Um Column Functions bereits während des Datenzugriffs zu ermöglichen, müssen folgende Bedingungen vorliegen: GROUP BY benötigt keinen Sort (EXPLAIN-Output prüfen). Kein Stage-2-Prädikat verwenden. Dies ist in der Anwendung zu formulieren. Keine Distinct-Set Funktion (wie z.b. COUNT(DISTINCT C1)). Beinhaltet die Query einen Join, dann beziehen sich alle Set Functions auf die letzte Tabelle des Joins (EXPLAIN-Output prüfen). Alle Column Functions beziehen sich auf eine einzige Column ohne arithmetischen Ausdruck, ausgenommen die Column Functions VARIANCE and STDDEV, die niemals während einer Retrieval -Aktion ausgeführt werden können Formulieren von Prädikaten Manche Formulierungen in den Prädikaten schließen eine Indexnutzung bei DB2 aus (siehe Pkt.: Fehler! Verweisquelle konnte nicht gefunden S.K.Consulting Services GmbH Seite 34 von 128

35 Kapitel 3: SQL Die Structured Query Language bei DB2 werden. und Fehler! Verweisquelle konnte nicht gefunden werden. ff.). Deshalb folgende Empfehlungen: Prädikate die Indexes nutzen könnten, sollten bevorzugt werden Unabsichtlich redundante oder unnötige Prädikate sind zu vermeiden Deklarierte Längen von Host Variablen darstellen: Die Länge deklarierter Host- Variablen (HV) darf nicht länger sein als das Attribut der Datenspalte, mit der die Host-Variable korrespondiert. Wenn die HV-Länge größer ist, wird das Prädikat Stage-2 und kann niemals passendes Prädikat für einen Index Scan werden. Folgende Host Variable und SQL Tabellenspalte sei angenommen: Assembler Declaration SQL definition MYHOSTV DS PLn value COL1 DECIMAL(6,3) Bild-14: Deklaration von HOST-Variablen Die Präzision der Host-Variablen beträgt 2n-1. Bei n = 4 und Wert = würde das Prädikat, wie nachfolgend dargestellt, kein passendes sein, weil die Präzision (7,0 und 6,3) unterschiedlich sind:... WHERE COL1 = :MYHOSTV Eine Möglichkeit solche ineffizienten Prädikate zu vermeiden besteht darin, Host- Variablen ohne Längenoption zu versehen, also MYHOSTV DS P l23.l23 Dies garantiert die identische Attributdefinition wie die der SQL Spalte Die Verwendung von scalar functions Die Verwendung von skalaren Funktionen, wie SUM, MAX, MIN, AVG, COUNT, LENGTH, VALUE, CHAR, DATE, DECIMAL, DIGITS usw., sollte immer mit Vorsicht zu erfolgen. Es ist genauestens zu prüfen, ob Programmfunktionen in Anwendungsprogrammen nicht dieselbe Wirkung und Funktionalität besitzen, ohne den DB2-Kernel unnötig zu belasten. DB2 ist ein Meister in relationaler Funktionalität aber kein Konvertieroder Rechenprogramm Neuordnen der Tabellenfolge in der FROM Klausel Die Reihenfolge der Tabellen oder Views in der FROM Klausel kann die Auswahl des Zugriffspfads beeinflussen. Wenn die Query langsam läuft kann dies deshalb sein, weil die "Join sequence" ineffizient ist. Man kann die "Join sequence" innerhalb eines Query-Blocks aus der Spalte PLANNO in der PLAN_TABLE ersehen (siehe auch Pkt. 0 ff.). Eine Neuanordnung der Tabellen oder Views in der FROM Klausel kann zu einer besseren Performance der Query führen. S.K.Consulting Services GmbH Seite 35 von 128

36 Kapitel 3: SQL Die Structured Query Language bei DB2 Es sollte Dabei darauf geachtet werden, dass in den verschiedenen JOIN-Verfahren immer die Tabelle/View mit den kleineren Join-Resultaten als äußere Tabelle beim Join verwendet wird List prefetch Index Screening ist genau die richtige Medizin für exzessive List prefetch - Operationen. List prefetch erfolgt immer, wenn Indizes nicht genau zur WHERE- Klausel passen. Beispiel: Index: c1, c2, c3, c4.where c1 = xx AND c3 = yy AND c4 = zz Bisher wurde nur die c1 Spalte genutzt, um die RID s für den list prefetch zu finden. Jetzt werden auch die Spalten c3 und c4 überprüft, um die entsprechenden RID s vor dem list prefetch zu eliminieren. Damit wird die Last für den RID Pool reduziert, über die ansonsten RID Pool failures und andere Probleme hervorgerufen werden können Uncommitted read Wenn irgend möglich sollte das isolation level uncommitted read (UR) gesetzt werden. UR vermeidet unnötigen lock overhead. Am einfachsten wird die Nutzung von UR bei read-only Daten. Jede Tabelle, die als read-only erkannt und analysiert ist sollte im SELECT-Statement die Klausel WITH UR enthalten. Bei langlaufenden Queries auf den Clients können nach Erfahrungen so bis zu 30% CPU-Zeit gespart werden. Achtung: Uncommited read darf nicht mit skip locked data (seit DB2 V9) verwechselt werden! Die Funktionalität dieser beiden Anweisungen ist sehr unterschiedlich row level locks Man sollte row-level locking vermeiden wo immer es geht. Oft wird RLL ( row level locking ) genutzt, um Probleme bei der Parallelverarbeitung zu vermeiden. Meist jedoch erzeugt diese Methode mehr Probleme als sie löst. Dies besonders deshalb, weil diese Verfahrensweise zu einem potentiellen Anstieg von deadlock -Situationen führt, indem sie mehr als einen Prozess pro Page zulässt Freigabe von Locks In n-tier Umgebungen verursachen locks die Belegung von aktiven oder inaktiven threads nach einem Commit. In der Komponente DB2-Connect kann man den Parameter cursorhold auf 0 (kein default ) setzen, was dazu führt, dass Sperren nach einem commit aufgehoben werden. Zusätzlich dazu sollte man den Parameter autocommit überprüfen, der unterschiedlich, z.b. in ERP-Systemen, eingesetzt werden kann. So setzen manche ERP Systeme den Parameter autocommit auf 0, um commits zwischen den SQL-Statements zu unterbinden, da alle commits in der Applikation ausgelöst werden. In anderen Fällen ist der autocommit zur Transaktionsorientierung unerlässlich, z.b. in Tuxedo-Umgebungen. S.K.Consulting Services GmbH Seite 36 von 128

37 Kapitel 3: SQL Die Structured Query Language bei DB lock escalation Bei bestimmten TS ist es sinnvoll lock escalation auszuschalten. Lock escalation kann in einigen Situation durchaus zu einer echten Performance-Bremse werden. Setzt man LOCKMAX in der TS-Definition auf 0, so schaltet man damit lock escalation für den jeweiligen Tablespace aus. LOCKSIZE sollte zudem auf PAGE oder ROW gesetzt sein. Bei "partitioned table spaces" (PTS) sollte das selective partition locking (SPL) eingeschaltet sein (LOCKPART YES). Dies verursacht nur bei den benutzten Partitions Sperrungen, nicht aber auf allen anderen auch den nicht verwendeten. Bedingungen, die SPL verhindern, sind: Type 1 Index wird im access path verwendet Der Plan wurde mit ACQUIRE(ALLOCATE) gebunden Der TS wurde mit LOCKSIZE TABLESPACE erstellt LOCK TABLE IN EXCLUSIVE MODE wurde ohne PART Angabe gesetzt "materialized query tables"(mqt's) und "automatic query rewrite"(aqr) Materialized query tables sind Tabellen, die Informationen enthalten, die aus anderen Tabellen gewonnen werden. MQT's speichern Resultate aus vorangehenden Queries, die aufwendige Joins und Aggregationsoperationen durchführen. Indem die gewonnene, zusammengefasste Information aufbewahrt und vorgehalten wird, können MQT's folgende Query-Verarbeitung vereinfachen und die Performance von "dynamic SQL queries" erheblich verbessern. MQT's sind deshalb besonders oft in "data warehousing applications" zu finden. Automatic query rewrite (AQR) ist der Prozess bei DB2, der zur Verarbeitung von Daten aus einer MQT führt. Wird AQR zugelassen, dann entscheidet DB2 selbst, ob es eine "dynamic query" oder einen Teil daraus über die Nutzung einer "materialized query table" schneller erledigen kann. Wenn ja, wird DB2 die Query so umformulieren ("rewrite"), dass anstatt der originalen Tabelle(n) die MQT verwendet werden kann. Dabei ist zu beachten, dass eine MQT Query-Resultate enthalten kann, die nicht "ad hoc"-aktuell sind vor allem, wenn die betroffenen "base tables" nach der Erstellung der MQT desöfteren geändert wurden. Zu diesem Thema gibt es in der einschlägigen Literatur folgende Punkte nachzulesen: Einführung in MQT's und AOR Definition einer MQT Aufbau von MQT's Security und MQT's Nutzung von AQR Beispiele zu MQT s und AQR Empfehlungen für das Design von "materialized query tables" Die folgenden Empfehlungen betreffen direkt das Design von MQT's: "Aggregate Functions" sollten strategisch im Fullselect einer "materialized query table"-definition berücksichtigt werden: - COUNT(*) und SUM(Ausdrücke) S.K.Consulting Services GmbH Seite 37 von 128

38 Kapitel 3: SQL Die Structured Query Language bei DB2 - SUM(expression*expression) nur, wenn auf VAR(expression), STDDEV(expression), VAR_SAMP(expression), oder STDDEV_SAMP(expression) abgefragt werden soll. - COUNT(expression) zusätzlich zu COUNT(*), fall der Ausdruck "nullable" sein sollte. - MIN(expression) und MAX(expression), wenn dies abgefragt wird - NICHT: AVG(expression), VAR(expression), oder STDDEV(expression) direkt, falls eine der folgenden Parameter Kombinationen genutzt werden sollte: SUM(expression), SUM(expression*expression) und COUNT(*) SUM(expression), SUM(expression*expression) und COUNT(expression) - DB2 kann AVG(expression), VAR(expression) und STDDEV(expression) aus SUM(expression), SUM(expression*expression) und der zugehörigen COUNT "aggregate function" ableiten. Der "foreign key" einer "dimension table" einer GROUP BY Klausel einer MQT Definition sollte ebenfalls in der MQT vorhanden sein; z.b. wenn PGROUP.ID existiert, sollte auch PGROUP.LINEID existieren. DB2 kann dann die MQT verwenden, um eine Summierung auf der Ebenen LINEID vorzunehmen, ohne über PGROUP erneut zu "joinen" Alle "higher-level columns" in der MQT sollten vorhanden sein, da DB2 die funktionale Abhängigkeit einer denormalisierten "dimension table" nicht kennt; z.b. CITY in einer GROUP BY Klausel impliziert auch STATE und COUNTRY für diese Klausel. Ebenso wie MONTH in der GROUP BY Klausel ebenfalls YEAR impliziert. HAVING Klauseln haben in der MQT nichts verloren. Eine "materialized query table" mit HAVING in ihrer Definition besitzt nur eine limitierte Verwendbarkeit während des "query rewrite". Erzeugen Sie Indexe auf materialized query tables, wie Sie sie auch auf den Basistabellen anlegen würden Empfehlungen für das Design der zugehörigen "base tables" Die folgenden Empfehlungen betreffen die Strategien zum Design der Basistabellen und dienen der Performancesteigerung und einer erhöhten Anwendbarkeit von materialized query tables : "referential integrity" sollte wann immer möglich entweder als ENFORCED oder NOT ENFORCED definiert sein. Ebenso sollte ein IX als UNIQUE definiert werden, wenn er eindeutig ist. Alle "base table" Spalten sollten wo immer möglich als NOT NULL definiert sein, sodass COUNT(X) genauso möglich wird wie COUNT(*). In diesem Fall muss man nicht auch noch COUNT(X) für jede "nullable column" X in einer MQT Definition vorsehen. Falls nötig sollte ein spezieller Wert definiert werden, der den NULL-Wert ersetzt. Normalisierte Tabellen sollten denormalisierten Tabellen im "base tables"-umfeld vorgezogen werden. Nutzt man normalisierte Tabellen, so kann man "nonprimary key columns" für eine MQT eher vernachlässigen und spart damit nebenbei auch noch Speicherplatz. DB2 kann das Fehlen von "non-primary key columns" kompensieren, indem es diese Spalten über einen Join auf eine "dimension table" immer noch gewinnen kann. Ist Performance ein Aspekt, so kann man MQT's auch so definieren, dass die so genannten "snowflake dimensions" denormalisiert dargestellt werden. S.K.Consulting Services GmbH Seite 38 von 128

39 Kapitel 3: SQL Die Structured Query Language bei DB Der DB2-Katalog Es ist wichtig, den Katalog sauber und ordentlich zu verwalten. Normalerweise nämlich ist die Anzahl packages und DB2-Objekte in einer Produktionsumgebung nicht unerheblich. Der Katalog sollte keine unnötigen Objekte enthalten und ebenfalls von Zeit zu Zeit reorganisiert werden. Dies ist Aufgabe einer leistungsfähigen DBA. Erfahrungen zeigen eine Reduktion von I/O s um ca. 10 bis 12 Prozent und eine Reduktion von elapsed time um ca. 11 bis 14 Prozent nach einer Reorganisation. In einigen Fällen, z.b. bei starker Fragmentierung wurden sogar bis zu 50% Reduktion der I/O Tätigkeit nach einem REORG des Katalogs erzielt. S.K.Consulting Services GmbH Seite 39 von 128

40 4 SQL-Tuning und Performance bei DB2 Das Tuning von SQL Queries kann folgende Aktivitäten erfordern: Hinzufügen und/oder Ändern von Indizes Anpassen der Spaltengrössen in Tabellen Neuschreiben von Queries Jede Kombination aus den genannten Aktivitäten Insbesondere Queries, die Bestandteil von angepasstem Code, generierten Abfragen und benutzerverfasste Queries bedürfen häufig eines Tuning. Insbesondere bei Reporting Aufgaben überschreiten die generierten Queries schon einmal die erlaubte Anzahl von 15 Tabellen in einem Join in der DB2 Version 5. Seit DB2 Version 6 sind bis zu 255 Tabellen in einem SQL-Statement verarbeitbar, aber nur 15 joined -Tabellen in einem SQL-Statementblock erlaubt. Ab DB2 Version 8 sind es bis zu 225 Basistabellen, die in einer einzigen "joined expression" verarbeitet werden können. Joins über Spalten mit ungleicher Länge führten bis zur Version 5 zu Performance- Problemen. Seit DB2 Version 6 kann DB2 dies über zusätzliche interne Funktionen kompensieren. Dennoch sind nach der Migration betroffene Indizes anzupassen. In Version 8 wird DB2 über "query rewrite"-funktionalitäten derartige User-Fehler weitgehend beheben 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 konnte alleine über den Weg von CASE-Formulierungen eine Reduzierung von elapsed time und CPU-Zeit von bis zu 80% erzielt werden (siehe auch Pkt ff). 4.1 Die neuen Limits bei DB2 Version 9 Folgende Begrenzungen in DB2 Version 8 und 9 haben sich im Vergleich zu den vorhergehenden Versionen verändert: Die Größe des Virtual Storage von 2 GB (2 31 Bytes) auf 16 EB (= Exabytes = 2 64 Bytes) das sind 16 Milliarden GB(!) Maximale Länge von Table- & Viewnames von 18 auf 128 Zeichen Maximale Länge eines SQL Statements: Bytes Maximale Anzahl von Elementen in einer SELECT-Liste: 750 Maximale Anzahl von Subqueries in einem Statement: 224 Maximale Länge der Columnnames : 30 Zeichen Maximaler Länge eines Cursornamens ist 30 Bytes Die Länge von Character Literals von 255 auf Zeichen S.K.Consulting Services GmbH Seite 40 von 128

41 Kapitel 5: Die relationalen Komponenten in DB2 Maximale Länge eines SQLpath ist jetzt 2048 Bytes Die Anzahl Tables in einem Join: 225 Maximale Länge eines index key : o Partitioning: 255-n o non-partitioning(padded): 2000-n o non-partitioning(not padded): 2000-n-2m ( n = # Spalten, die NULLs zulassen und m = # von VARCHAR-Spalten ) Maximale Anzahl von expressions in einem index key : 64 Maximale Grösse eines non-lob TS bzw. Table: 128 TB Maximale Grösse eines simple bzw. segmented TS ist 64 GB Die Maximale Anzahl Partitions in einem PTS von 254 auf 4096 Die Anzahl von Active logs von 31 auf 93 Die Anzahl Archive logs von 1000 auf 10,000 Maximale Anzahl Databases in einem Subsystem: Maximale Länge eines sortkey : Bytes Maximale Länge eines XPATH Levels in der Klausel XMLPATTERN beim CREATE INDEX: 50 nesting levels Zusätzlich wurden einige der wichtigsten internen (systemtechnischen) Grenzen aufgehoben: Veränderungen im Maschinencode (64-Bit Architekturen) Mehr Realspeicher (reduziert das "paging") Mehr "threads", größere Bufferpools, mehr Anwendungen parallel mehr Objekte größere Objekte usw. Für komplexe Joins sollten auch die ZPARMs in der DB2-Umgebung entsprechend angepasst werden: Schlüsselwort Beschreibung Default Werte MAX_OPT_STOR (SPRMMXOS) MAX_OPT_CPU (SPRMMXOC) MAX_OPT_ELAP (SPRMMXOE) Maximal vom DB2 Optimizer verbrauchbarer RDS OP POOL(MB) Maximal vom DB2 Optimizer verbrauchbare CPU Zeit (Sekunden) Maximal vom DB2 Optimizer verbrauchbare elapsed Zeit (Sekunden) 20 MB MB 100 sec sec 100 sec sec Bild-15: SQL-wirksame Optimizer- ZPARMs - seit DB2 V8 S.K.Consulting Services GmbH Seite 41 von 128

42 Kapitel 5: Die relationalen Komponenten in DB2 4.2 Die DB2 SQL Engine Im Folgenden wird die generelle Verarbeitung von SQL-Statements in DB2 dargestellt und welche Fragestellungen der Optimizer zu beantworten hat, bevor er über die Zugriffe auf eine DB2-Tabelle entscheidet. Bild-16: Die DB2-SQL Engine Die kritischen Fragen sind: Werden alle Indexe genutzt? Wird sequentual prefetch bzw. list prefetch effizient angesteuert? Sind alle Spalten im Index korrekt? Wie viele der Spalten passen zu den Queries ( matching index columns )? Werden weniger als alle index columns verwendet? Wenn ja: Gibt es Statistiken über die Kardinalität dieses subsets? Wurde index-only Zugriff verwendet oder sollte er verwendet werden? Wurden column functions in Stage1, Stage2 oder anderswo aufgelöst? Könnten sie eventuell während der Datenwiedergewinnung aufgelöst werden? Wird ein ORDER BY über einen Index bedient oder wird ein expliziter SORT ausgelöst? bzw. Muss ein temporary Workspace verwendet werden? Wie viele rows werden von Stage1 an Stage2 übergeben? Werden Views, Aliase und MQT s genutzt und materialisiert? Werden table expressions genutzt und materialisiert? Wurde alles, was möglich ist, für die Daten getan, bevor sie ans Programm/den User zurückgegeben werden? S.K.Consulting Services GmbH Seite 42 von 128