DB2 SQL. DB2-Optimierung und SQL-Performance. Grundlagen, Standards und Tipps zum effizienten Umgang mit DB2/SQL

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 11: 2014 V (inkl. DB2 V9/V10) S.K.Consulting Services GmbH Seite 1 von 44

2 Inhaltsverzeichnis INHALTSVERZEICHNIS 1 VORWORT GRUNDSÄTZLICHES ZU DB2 UND PERFORMANCE Planen von Performance Strategien Management von Performance allgemein Setzen von realistischen Performance Zielen Service-level agreements(sla) Planung der Performance Überwachung Kontrolle und review der performancerelevanten Daten Die Optimierungspotentiale bei DB Vorgehensweise beim Tuning von DB Anhaltspunkte und Analysedaten für Tuning Accounting und statistics records Die Grundvorgaben für gute DB2 Performance Weitere Voraussetzungen für Performance in SQL bei DB Möglichkeiten und Maßnahmen zur (SQL-)Optimierung Systemtechnische Aktivitäten Anwendungsbezogene Maßnahmen Die Tuningpotentiale des DB2-Systems selbst 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 ÜBERLEGUNGEN ZUR SQL PERFORMANCE Dynamic SQL Datenbankobjekte und ihre Struktur Tabellen und Tablespaces Indexe Primary und Clustering Indexes Index Only -Zugriffe auf VARCHAR Spalten Aufwand und Kosten von Indexes Verzögerte Objektdefinitionen Empfehlungen zu Sortierungen SQL-Abfragen mit Subqueries Die Typen von Subqueries Correlated subqueries non-correlated Subqueries Bedingungen bei DB2 um eine Subquery in einen Join zu tranferieren S.K.Consulting Services GmbH ++49 (0) Seite 2 von 44

3 Inhaltsverzeichnis Resultate im EXPLAIN Subqueries transformiert auf Joins Subqueries, die DB2 nicht auf Joins transformieren können Correlating und de-correlating Subqueries Set functions und grouping functions Correlated ranges und <> Vergleiche Subquery Tuning Komplexität von Queries Spalten-Funktionen Formulieren von Prädikaten Die Verwendung von scalar functions Neuordnen der Tabellenfolge in der FROM Klausel Die Prefetches Sequential prefetch Dynamic prefetch List prefetch Uncommitted read row level locks Freigabe von Locks 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" Beispiele für MQTs 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 S.K.Consulting Services GmbH ++49 (0) Seite 3 von 44

4 Inhaltsverzeichnis 5.5 DB2 SQL und Empfehlungen Grundsätzliche Empfehlungen zu DB2-SQL Modifikation von SQL-Statements Restrukturierung von UNION- durch CASE-Ausdrücke Unterstützung von UNION- durch physisches DB-Design Spezielle Techniken ORDER BY und SORT-Vorgänge bei DB Einsatz des cartesian join ( star-join ) existence checks mit SQL So sollte es nicht gemacht werden correlated Subquery und 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 Division (Quotient) Die Kodierung diverser Join Typen in DB2 SQL Bemerkungen zu Joins 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 Die SQL-Statements INTERSECT und EXCEPT Die Operation MERGE Delete only MERGE Complex 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 Erzeugen rekursiver Funktionen und Prozeduren in SQL PL Mehr Performance für Modifikationsoperationen seit 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 Datumsarithmetik S.K.Consulting Services GmbH ++49 (0) Seite 4 von 44

5 Inhaltsverzeichnis 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 DB2 SQL Nutzungsrichtlinien (Zusammenfassung) 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) Weitere Beispiele für Sargeable & indexable Predicates Prädikate auf Sargeable & indexable umformulieren (Beispiele) Index probing 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" DB2 "Access Path"-Auswahl : JOINs / "merge scan" Spezielle Techniken zum Beeinflussen der Pfadauswahl bei DB Die Informationen über Zugriffspfade Minimieren des "overhead" durch Anfordern von wenigen "rows" Nutzung der "cardinality" Klausel Reduktion der Anzahl "matching columns" Neuanordnen der Tabellenreihenfolge Update der Katalogstatistiken Nutzung von Subsystem Parametern DB2 - Parallelverarbeitung Allgemein Konzeptioneller background und Terminologie Database Design Überlegungen Überlegungen zum Applikationsdesign BIND Optionen S.K.Consulting Services GmbH ++49 (0) Seite 5 von 44

6 Inhaltsverzeichnis System und Installationsüberlegungen 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) 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 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 Globales timeout processing 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 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 S.K.Consulting Services GmbH ++49 (0) Seite 6 von 44

7 Inhaltsverzeichnis 10.3 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 Performance Änderungen in DB2 V Hash access auf einzelne Tabellenzeilen Verbesserte LOB und XML Verarbeitung LOB Daten Locking SQL Zusatzinformationen Zum Thema LIKE DB2 zum Thema optimistic locking Die EXPLAIN_Tables Die input -Tables Die PROFIL Tabellen builtin-functions Abbildungsverzeichnis Index Glossar Literaturhinweise S.K.Consulting Services GmbH ++49 (0) Seite 7 von 44

8 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 eine denkbar komplizierte (Betriebs-)Ressource, die leichter, effizienter und produktiver verwendet werden kann, wenn sie geordnet und seinem Zusammenhang gemäß sinnvoll dargestellt und angeboten wird. Datenbankmanagementsysteme (DBMS) sind immer noch die Werkzeuge, mit denen Informationen strukturiert, verwaltet und bedarfsgerecht aufbereitet, wiedergegeben und verwaltet werden können. Über sie werden moderne Informationssysteme erst möglich. DB2 for z/os und DB2 LUW von IBM sind derartige Datenbanksysteme, die in einer modernen IT-Umgebung in der Lage sind, Informationsarchitekturen und -systeme über und für die gesamte Unternehmenshierarchie umfassend real werden zu lassen. Informationsverarbeitung ist zunächst abstrakt und dann effizient, wenn die richtigen Informationen zum richtigen Zeitpunkt am richtigen Ort sind. Das gelingt nur mit einer sorgfältigen Planung und Konzeptionen, 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 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. DB2for z/os und DB2 LUW beispielsweise lassen sich so konfigurieren, dass alle erforderlichen Aktivitäten, Anwendungen und Anforderungen auf effizienteste Art und Weise bedient werden können. Dazu müssen nicht nur alle (System-)Parameter optimal gewählt, das logische Datenmodell genau und sorgfältig entwickelt, sondern auch die Datenstrukturen nach genauer Analyse in die physische DB2-Umgebung überführt sein. Dies umso mehr, als mit der Ausweitung der Informationstechnik die Komplexität der Informationsstrukturen selbst und die Quantität angebotener Datenmengen ständig zunimmt und letztendlich beliebig umfangreich werden kann. Andererseits soll die Informationsqualität ständig verbessert und die verfügbaren Informationen immer effektiver und zielgerichteter dargeboten werden. Insbesondere gilt es, Applikationen architektonisch so abzubilden, dass sie konsistent und stabil allen möglichen business logics folgen; d.h. letzendlich Programme so zu schreiben, dass sie wartbar, entwickelbar, komplexe Vorgänge unterstützen und Performanceziele erreicht werden. Im Endeffekt soll ein Minimum an Kosten entstehen. Die Erkenntnis, dass der Unternehmenserfolg, wie bei den bekannten klassischen Produktionsfaktoren - Finanzen, Material, Anlagen und Personal(ist das eine Ressource?) - 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. 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 effektiver kann die Informationsbewirtschaftung für das Unternehmen sein. Im Zentrum der wirtschaftli- S.K.Consulting Services GmbH Seite 8 von 44

9 Kapitel 1: Vorwort chen Aspekte aber steht die Informationstechnologie - ihre Möglichkeiten, ihre Produkte und die Wertschöpfung, die man mit ihren Ausprägungen der Information erzielen kann. Die Erwartungen an die Leistungsfähigkeit und Stabilität eines DBMS sind also hoch und berechtigt. In dieser Handbuchserie werden unter DB2 Performance-Gesichtspunkten alle wichtigen Fragen zu und die Möglichkeiten in Hinsicht auf das Produkt DB2 for z/os 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 Anfänger im Umgang mit DB2, konzipiert. Das vorliegende Buch beschäftigt sich mit dem Thema: DB2 Optimierung und SQL-Performance. Es ein Leitfaden sein, der SQL Statements ursprünglich, richtig und effizient entwickeln, testen und zukünftig optimal schreiben und einstellen helfen kann - 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 for z/os (manche SQL Vorschläge gelten genauso für DB2 LUW). Mit freundlichen Grüßen S.K. Consulting Services GmbH Sepp Kraus Für die Mitarbeit an diesem Handbuch bedanken wir uns bei den Firmen AXA Versicherungen, Köln BMW AG, München Deutsch Bank Bauspar AG, Frankfurt NORD/LB, Hannover Raiffeisenverband IT, Bozen IT-Verlag, Sauerlach b. München S.K.Consulting Services GmbH ++49 (0) Seite 9 von 44

10 2 Grundsätzliches zu DB2 und Performance 2.1 Planen von Performance Strategien Der erste Schritt zur Verbesserung von Durchsatz 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 Reaktion auf erkennbare Performance Probleme 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, VMWare oder den Anwendungen verteilter Plattformen, z.b. Windows, UNIX oder Linux, die sich die gemeinsame IT Infrastruktur teilen müssen, können Einfluss darauf nehmen, wie DB2 und seine Anwendungen sich verhalten. 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 nicht garantiert werden, dass die in diesem Buch veröffentlichten Empfehlungen für jede spezielle Konfiguration seine uneingeschränkte Gültigkeit haben. 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 zu DB2 könnten so ungeeignet sein. Die Empfehlungen sind allgemein. Performance Messungen sind in höchstem Maße abhängig von der Last und den 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(ggf. aus einem Performance DWH ) 4. Über die Analyse der performance reports, wird entschieden, ob die gesetzten Ziele erreicht wurden 5. Ist die Performance uneingeschränkt gut, gelten folgende Optionen: Weniger monitoring, denn monitoring selbst benötigt auch Ressourcen S.K.Consulting Services GmbH Seite 10 von 44

11 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 erforderlichen Charakteristiken so gut justiert werden, dass sich damit die Performance verbessert d. Zurück zu Schritt 3 und Durchführung weiterer monitoring Aktionen In festen Zeitabständen oder nach signifikanten Änderungen an System oder der Systemlast sollte man zu Schritt 1 zurückkehren, die Zielsetzungen überprüfen und entsprechend die monitoring - und Tuning-Strategien verfeinern und anpassen Setzen von realistischen Performance Zielen Wie gute Performance für das DB2 System 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 sein. Normalerweise schließen diese Zielsetzungen Werte für 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 Systemstabilität, mit Funktionalitäten, wie HADR, cloning von DBs, BACKUP und RECOVERY etc. mit ein. 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: So ist eine Vereinbarung auf Gegenseitigkeit für akzeptable Performance zwischen der betreibenden IT Gruppe und den Benutzergruppen formalisiert und zum sogenannten Service-Level Agreement bestimmt. 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 oder nicht. Sie können beliebig komplexen Algorithmen folgen. Die Kriterien dafür müssen jedoch ohne Ausnahme messbar sein. S.K.Consulting Services GmbH ++49 (0) Seite 11 von 44

12 Kapitel 2: Grundsätzliches zu DB2 und Performance 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 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), Mainview von BMC 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 (SQL, physische DB Struktur etc.), aber auch Änderungen am Anwendungsdesign und im aufwändigsten Fall auch am Datenmodell 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 von Fall zu Fall 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. S.K.Consulting Services GmbH ++49 (0) Seite 12 von 44

13 Kapitel 2: Grundsätzliches zu DB2 und Performance Diese Daten sind systematisch auszuwerten. 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 und seine Auffälligkeiten analysiert 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 ++49 (0) Seite 13 von 44

14 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.2 Die Optimierungspotentiale bei DB2 Die Optimierungspotentiale bei relationalen Datenbanksystemen unterscheiden sich generell, was SQL betrifft auch zwischen DB2 und Oracle, SQL Server und SYBASE - nur minimal. Genau so sieht es bei der DB-Physik und den Installationsparametern aus Sicher ist, dass die wirksamsten Tuning-Potentiale, diese relationalen Datenbanksysteme schneller zu machen, im Bereich der Abfragesprache SQL und damit im Umfeld der Anwendungsentwicklung und der laufenden Programme und Abfragen zu suchen ist (siehe Grafik unten). Weiteres Performancepotential stellt das physische DB-Design, gefolgt von der Einstellung der Systemparameter selbst und dem Betriebssystem (z/os, AIX, UNIX, Linux, Windows usw.), dar. Empfehlenswert ist es, im Tuningfall dort zuerst zu suchen, wo das größte Potential zum Lösen der Tuningaufgaben existiert. Man darf dabei nur die anderen Bereiche nicht aus den Augen verlieren. In diesem Handbuch werden vorrangig die Problematiken und Möglichkeiten der Optimierung von SQL bei DB2" behandelt. Die Design- und Strukurierungsproblematik der physischen Datenbankstruktur bei DB2 findet man im Band DB2 - DB-Design und physische Strukturen aus dieser Handbuchreihe 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 Die Grafk zeigt die Anteile der Tuningpotentiale im DB2 Umfeld. Entsprechend kann man auch seine Erwartungen platzieren. S.K.Consulting Services GmbH ++49 (0) Seite 14 von 44

15 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. IFI Informationen: Anzahl GETPAGES, Aufrufhäufigkeiten etc. 4. Buffer Pool, Locking, EDM Pool, Work File, LOB, DBM1 Virtual Storage Accounting und statistics records Alle accounting und Statistikdaten sind bei DB2 for z/os relativ einfach und kostengünstig zu erhalten. Sie sind vor allem nützlich für ein kontinuierliches Monitoring der Performance und daraus abzuleitende Tuningaktivitäten. Für eine erste Analyse genügen jedoch 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 ff. S.K.Consulting Services GmbH ++49 (0) Seite 15 von 44

16 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.4 Die Grundvorgaben für gute DB2 Performance 1. Stellen Sie sicher, dass genügend Plattenplatz vorhanden ist. (6-10 Laufwerke pro CPU ist für den Anfang genug das gilt auch für DB2 LUW und seine SAN Systeme). Jeder "Tablespace Container" sollte alle verfügbaren Platten erreichen können. Einige "tablespaces", wie zum Beispiel SYSCATSPACE und alle Platten mit einer geringen Anzahl von Tabellen, sollten nicht über alle möglichen "Disks" gestreut werden, wogegen die TS mit einer großen Useranzahl oder auch mit vielen "temporary tables" möglichst über den gesamten "Diskpool" aufgeteilt sein sollten. 2. (Buffer-)Pools 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) immer durchgeführt sein. Gegebenenfalls sollte man einen "Design Advisor" nutzen, um eine Empfehlung und ein "review" für die Indizes bezüglich ihrer SQL" workloads" und Wirksamkeit zu erhalten. 4. Man kann auch den "Configuration Advisor" nutzen, um Empfehlungen bezüglich der Konfiguration fürden "Database Manager" und die Datenbank für die entsprechenden Applikationen zu erhalten. 5. Logging sollte auf separaten "high-speed Disks" erfolgen 6. "Concurrency" kann durch häufige "commits" und konsistentes Transaktionsverhalten verbessert werden (SQL Statement Tuning). 7. Der Parameter SORTHEAP/SORTHEAPSIZE sollte hoch genug eingestellt werden, um "sort overflows" zu vermeiden 8. Der Tablespace Typ für den "System catalog table space" sollte ein eigener SMS-Pool oder sogar ein eigener (schneller) Plattentyp sein. 9. "Temporary table spaces", work TS und "DMS raw (devices)" oder "Files" sollten ebenfalls separat definiert sein. 10. Man nutze "parameter markers" für sich wiederholende (dynamic) SQL- Statements (SQL Statement Tuning). 2.5 Weitere Voraussetzungen für Performance in SQL bei DB2 Es ist bekannt, dass sich Tuning- und Performance-Maßnahmen auch bei relationalen Systemen bis auf die Applikationsentwicklung auswirken. So gilt auch hier, dass die ineffiziente Nutzung von Systemressourcen durch Anwendungsprogramme über systemtechnische Einstellungen nicht korrigiert werden kann. Deshalb müssen vor allem die Entwickler: Verständnis für die Interna der DB2-Umgebung besitzen ein tiefes Wissen über DB2-Tuning-Ansätze und Optimizer-Verhalten haben das (logische und das physische) Datenmodell kennen S.K.Consulting Services GmbH ++49 (0) Seite 16 von 44

17 Kapitel 2: Grundsätzliches zu DB2 und Performance Das Fundament für gute Performance kann nur über entsprechende Maßnahmen beim System-Design in Daten- und Funktionsentwurf erreicht werden 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 an alle denkbaren und nicht planbare Datenkonstellationen an komfortable Oberflächen an gute, unverzügliche Antwortzeiten an permanente Verfügbarkeit Anwendungsentwickler mit ihrer Qualifikation und dem Wissen über Vorgehensmethoden und techniken und dem Verständnis komplexer Zusammenhänge und dem Verständnis für interne, systemtechnische Zusammenhänge und Konsequenzen und ihrem Wissen unter dem Aspekt des Einsatzes und der Handhabung von Tools Administratoren mit ihrem Qualitätsanspruch an Planung und Kontrolle optimierter Ressource-Nutzung unter der Anforderung des Sicherstellens aller möglichen und notwendigen security -Aspekte an die 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 Ressourcenverbräuche angemessen sein. Übergroße Schuhe hindern einen am Laufen ebenso wie zu kleine... S.K.Consulting Services GmbH ++49 (0) Seite 17 von 44

18 Kapitel 2: Grundsätzliches zu DB2 und Performance Dabei ist es entscheidend, dass auf keiner der unterschiedlichen Ressourcenund Technologieebenen Engpässe auftreten dürfen: angemessene Hardware abgestimmtes Betriebssystem und systemnahe Software moderater Einsatz von Standard-Software-Systemen Unterstützung von Individualanwendungen Nutzung von Performance-Tools Nutzung von moderaten Entwicklungshilfen S.K.Consulting Services GmbH ++49 (0) Seite 18 von 44

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. Diese Tuningaktivitäten in den einzelnen Bereichen gehorchen 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) ein realistisches, "sauberes" Informationsmodell b) eine optimale Umsetzung dessen in die physische Umgebung c) eine klare und systematische Anwendungsentwicklung d) effiziente Anwendungsprogramme e) die optimale Einstellung der DBMS-Parameter f) eine entsprechende Änderung und Anpassung der OS-Parameter g) eine ständige Überwachung der Produktionsumgebung - durch Datenadministration - durch die Datenbankadministration - über "Monitoring" h) nicht zuletzt ein entsprechender Hardware-Einsatz Die Tuning-Möglichkeiten bei DB2 lassen sich also grob unterteilen in: Systemtechnische Aktivitäten Anwendungsbezogene Maßnahmen Tuningpotentiale des DB2-Systems S.K.Consulting Services GmbH ++49 (0) Seite 19 von 44

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 (DBA) beispielsweise für DB2 for z/os fallen, gehören: Optimierung der Generierungsparameter für z/os, CICS, IMS-DB und TSO. Autorisierungskonzept. Connection- und Thread -Nutzung ( Pooling ) Optimierung der Generierungsparameter für DB2, wie z.b.: Bufferpool-Größe und Nutzung EDM-PooI-Größe Bereitstellen der virtuellen Speicher/Systeme Lock-Definitionen (IRLM) LOG-Definitionen und -einstellungen Festlegung der Optionen für physische DB2-Objekte, wie z.b.: Storage group / User defined (VSAM-)Datasets DB2-Databases Typisierung der (User-)Tablespaces Typisierung und Einrichten der optimalen Indizes Nuztzung von Packages, Collections und (Anwendungs-)Plänen Re- bzw. Umorganisation der physischen Datenspeicherung. Anlegen, Ändern oder Löschen von Indizes. Beeinflussung der DB2-Zugriffspfade durch Manipulation von (Katalog-) Statistik-Werten. Permanente Überwachung des Systemverhaltens Einsatz von Utilities, wie z.b. RUNSTATS, CHECK, REORG etc. Durchführung gezielter REBIND-Maßnahmen und damit Nutzung von statischem SQL für operative Systeme Optimale Einrichtung der JDBC-, ODBC, CONNECT-Strecken 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, Einsatz von UNIOCODE etc.). Festlegung und Test von SQL-Statements (z.b. durch EXPLAIN nach Ausführung von RUNSTATS, durch Tools wie APPTUNE, MAINVIEW etc.) beim operativen Einsatz Umschreiben von Queries (Abfragen und Manipulationen) in effizienterer Form. S.K.Consulting Services GmbH ++49 (0) Seite 20 von 44

21 Kapitel 2: Grundsätzliches zu DB2 und Performance Festlegung der Nutzung von "constraints", RI, "triggers", UDF s und gespeicherten Prozeduren (STPs) Die Tuningpotentiale des DB2-Systems selbst Die Tuningpotentiale des DB2-Systems selbst liegen vor allem in folgenden Bereichen: z/os-prioritäten-steuerung Adressraum-Nutzung Paging/Swapping Interne Ressource-Nutzung Generierungsparameter(ZPARMS) Connection/Thread-Nutzung Anzahl parallele Threads Autorisierungs-Konzepte z/os- und DB2-Systemparameter Cross-Memory- und System-Kommunikation Bufferpool-Größe und Nutzung LOG-Management LOCK-Management Interne Ressource-Nutzung: - Anzahl intern zu behandelnder 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 VSAM System- Services Database- Services DDF- DDF- Services Andere Trägersysteme Bild-03: Die DB2-Services im Überblick S.K.Consulting Services GmbH ++49 (0) Seite 21 von 44

22 Kapitel 4: Überlegungen zur SQL-Performance 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 / SELECT INTO GRANT DROP INSERT REVOKE ALTER UPDATE LABEL DELETE EXCHANGE MERGE RENAME TRUNCATE COMMENT PREPARE EXECUTE (IMMEDIATE) CONNECT / REFRESH SET CONNECTION / CURRENT.. CALL RELEASE (connect) SAVEPOINT COMMIT RELEASE SAVEPOINT ROLLBACK DECLARE OPEN / CLOSE DESCRIBE ALLOCATE EXPLAIN FREE GET DIAGNOSTICS HOLD LOCATOR INCLUDE LOCK REFRESH TABLE SIGNAL VALUES / VALUES INTO WHENEVER Bild-04: Übersicht über die wichtigsten 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 nur die Menge der Sprachelemente entscheidend, sondern deren Kombinierbarkeit. Sie macht die Mächtigkeit von SQL aus. DB2 deckt damit die DML-Anforderungen im Relationenmodell und mehr 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 S.K.Consulting Services GmbH Seite 22 von 44

23 Kapitel 3: SQL Die structured Query Language bei DB2 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: Lesen SELECT eingebaute Funktionen SUM Ändern INSERT MAX, MIN, AVG UPDATE DISTINCT DELETE COUNT TRUNCATE MERGE Gruppieren spezielle Aussagen UNION GROUP BY INTERSECT, EXCEPT HAVING 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. S.K.Consulting Services GmbH ++49 (0) Seite 23 von 44

24 Kapitel 3: SQL Die structured Query Language bei DB2 3.1 Relationale Sprachelemente und Operationen bei SQL SQL nutzt algebraische Mengenfunktionen zur Qualifikation der Daten. Die Grundemente 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 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 ++49 (0) Seite 24 von 44

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 ++49 (0) Seite 25 von 44

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 (alte Schreibweise) im RDB-Modell S.K.Consulting Services GmbH ++49 (0) Seite 26 von 44