DB2-Optimierung und SQL-Performance

Transkript

1 Kapitel 3: SQL Die Structured Query Language bei DB2 Standards, Tipps und Grundlagen zum Umgang mit DB2/SQL und anderen SQL - Dialekten DB2 - Optimierung und SQL - Performance Ausgabe 6: 2006 (inkl. DB2V7/V8) S.K. Consulting Services Seite 1 von 127

2 Inhaltsverzeichnis INHALTSVERZEICHNIS 1 Vorwort 8 2 Grundsätzliches zu DB2 und Performance Optimierungspotentiale bei DB Vorgehensweise beim Tuning Anhaltspunkte und Analysedaten für Tuning Accounting und statistics records Grundvoraussetzungen für DB2/UDB Performance Voraussetzungen für SQL-Performance bei DB Möglichkeiten und Maßnahmen zur SQL-Optimierung Systemtechnische Aktivitäten Anwendungsbezogene Maßnahmen Die Tuningpotentiale des DB2-Systems 17 3 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 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 lock escalation Materialized query tables(mqt's)und AQR Empfehlungen für das Design von "materialized query tables" Empfehlungen für das Design von zugehörigen "base tables" Der DB2-Katalog 34 S.K. Consulting Services Seite 2 von 127

3 Inhaltsverzeichnis 4 SQL-Tuning und Performance bei DB Die neuen Limits bei DB2 Version Die DB2 SQL Engine SQL-Tuning und die Logik von Abfragen constant propagation Eliminieren von totem Code Zusammenfassen von Konstanten ( constant folding ) case-insensitive Suchen Sargability "Join transitive closure" DB2 SQL und Performance 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 Nutze JOINs anstatt subqueries Komplemetärmengen bei outer joins Kodiere die selektivsten Prädikate zuerst Nutze erprobte Methoden zur Existenzprüfung(EXISTS) Subqueries sind zu tunen 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 Reihenfolgen bei OUTER-JOINs Subquery-Transformation in JOINs Auswahl der outer table bei JOINs Ausschalten von Indizes Beeinflussen der IX-Nutzung Beeinflussen von outer table Auswahl und JOIN-Methode Restrukturierung von UNION- durch CASE-Ausdrücke Spezielle Techniken CASE in Prädikaten CASE in UPDATE Anweisungen CASE zum Vermeiden von Rechen- oder anderen Fehlern CASE zum Eliminieren von UNION-Klauseln Funktionsequivalente Ausdrücke zur CASE-Klausel 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 89 S.K. Consulting Services Seite 3 von 127

4 Inhaltsverzeichnis 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" Mehr Performance für SQL-Operationen in Programmen ab V scalar full select multiple DISTINCT s multi row FETCH und multi row INSERT common table expressions Rekursives SQL Mehr Performance für Modifikationsoperationen ab V multi row INSERT INSERT innerhalb eines SELECT multi row FETCH und positioned UPDATE/DELETE" Do s und Don ts bei SQL in Kürze Grundsätzliche Empfehlungen zu SQL Tipps und Hinweise In Programmen verbotene SQL- Anweisungen SQL - Anweisungen, die keine Indexbenutzung zulassen SQL-Anweisungen, die eine Indexnutzung zulassen, SQL - Anweisungen, die ungünstig formuliert sind SQL Anweisungen mit ungünstigen JOIN-Formulierungen Vermeiden arithmetischer Ausdrücke in einem Prädikat DB2 SQL Nutzungsrichtlinien (Zusammenfassung) Allgemeines ORDER BY und GROUP BY JOIN-Tuning Subquery Tuning 123 S.K. Consulting Services Seite 4 von 127

5 Inhaltsverzeichnis 5 Die relationalen Komponenten in DB Das RDS - Relational Data Systems DM - Data Manager BM - Buffer Manager VSAM (außerhalb von DB2) Die Verarbeitung von Prädikaten Indexable Predicates Wie wird der Index durchsucht? "Sargeable und indexable Predicates"(Übersicht) Sargeable & indexable Predicates / Beispiele 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": "Multiple Index Access" / UNION (OR) DB2 "Access Path": "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 Spezielle Techniken zum Beeinflussen der Pfadauswahl bei DB Die Informationen über Zugriffspfade Minimieren des "overhead" durch Anfordern von wenigen "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? 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 158 S.K. Consulting Services Seite 5 von 127

6 Inhaltsverzeichnis Modifizieren des Katalogs (Anpassen "correlated columns") Update des Katalogs wegen join mit table functions Nutzung von Subsystem Parametern Favorisieren von "matching index" Zugriffen Optimieren von Queries mit IN-List Prädikaten Favorisieren eines indizierten Zugriffs Beispiel einer "Column correlation" Feststellen von "column correlations" Einflüsse von column correlations Was tun bei column correlations? Analyse der Zugriffspfade und DB2-Optimizer Informationen Faktoren der Entscheidung für den DB2-Optimizer Der Optimierungsvorgang und EXPLAIN Prädikate und Prädikatkategorien Die Filter Filterfaktoren(FF) 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 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 die 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" 202 S.K. Consulting Services Seite 6 von 127

7 Inhaltsverzeichnis 10 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 builtin-functions Abbildungsverzeichnis Index Glossar Literaturhinweise 264 S.K. Consulting Services Seite 7 von 127

8 Kapitel 3: SQL Die Structured Query Language bei DB2 1 Vorwort Information steht heute und auch in Zukunft im Mittelpunkt wirtschaftlichen Handelns. Information wurde zur treibenden Kraft der Informationsgesellschaft... Das Zitat von John Naisbitt über die Ressource Information in seinem Bestseller Megatrends von 1988(!) sagt in Kürze immer noch alles über die Bedeutung der Information in unserer Gesellschaft aus. Information ist ein denkbar abstrakter Stoff, der leichter, effizienter und produktiver verwendet werden kann, wenn er geordnet und seinem sinnvollen Zusammenhang gemäß dargestellt und angeboten wird. Datenbankmanagementsysteme (DBMS) sind die Werkzeuge, mit denen Informationen strukturiert, verwaltet und bedarfsgerecht aufbereitet, wieder geliefert werden können sollen. Ü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 möglich zu machen. Informationsverarbeitung ist dann effizient, wenn die richtigen Informationen zum richtigen Zeitpunkt am richtigen Ort sind. Dazu bedarf es einer sorgfältigen Planung, einer technisch perfekten Implementierung und einer ständigen Kontrolle und Abstimmung. Die Datenbank als Informationsspeicher muss in der Lage sein, die gestellten 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. Dies erfordert seitens der Technik hochperformante und flexible, aber auch stabile und sichere Systeme. DB2/UDB bietet Möglichkeiten, so eingestellt zu werden, 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 implementiert werden. Dies gilt umso mehr, als mit der Ausweitung der Informationstechnik die Komplexität der Information selbst und die Quantität angebotener Datenmengen ständig zunimmt, andererseits die Informationsqualität weiter verbessert und die verfügbaren Informationen immer effektiver und genauer dargeboten werden sollen. Insbesondere aber gilt es, Applikationen architektonisch so abzubilden und Programme so zu schreiben, dass die Performanceziele erreicht werden und ein Minimum an Kosten entstehen. 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 und umso besser für das Unternehmen. Die Erkenntnis, dass der Unternehmenserfolg, wie bei den bekannten klassischen Produktionsfaktoren - Finanzen, Material, Anlagen und Personal - unmittelbar von einer erschöpfenden und werteffizienten Verwertung dieser fünften Kraft Information - abhängt, führte zur Suche nach neuen Konzepten in einem neuen betriebswirtschaftlichen Umfeld - der Informationswirtschaft. Im Zentrum dieser wirtschaftlichen Aspekte steht die Informationstechnologie - ihre Möglichkeiten, ihre Produkte. Die Erwartungen an die Leistungsfähigkeit eines DBMS sind folglich enorm hoch. S.K. Consulting Services Seite 8 von 127

9 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 sowieso 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. Dieses 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 Quelle AG, Fürth Itellium GmbH & Co, Fürth IT-Verlag, Sauerlach b. München S.K. Consulting Services Seite 9 von 127

10 Kapitel 2: Grundsätzliches zu DB2 und Performance 2 Grundsätzliches zu DB2 und Performance 2.1 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). Eine weitere Fehlerquelle ist das physische DB-Design, gefolgt von der Einstellung der Systemparameter im DB2 selbst und im Betriebssystem (OS/390, z/os, AIX, UNIX 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 Seite 10 von 127

11 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.2 Vorgehensweise beim Tuning 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 OS/390 oder z/os folgende Messdaten 1. Elapsed Time Analysis und Tuning 2. CPU Time Tuning: Aufwände 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 STATISTICS REPORT LAYOUT (LONG), und DB2PM 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 DB2PM 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 9.6 ff. S.K. Consulting Services Seite 11 von 127

12 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.3 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 "table space's container" sollte alle verfügbaren Platten erreichen können. Einige "table spaces", 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. Diese sollten über den DB2 Konfigurationsparameter NEWLOGPATH identifiziert werden. 6. "Concurrency" kann durch häufige "commits" verbessert werden (SQL Statement Tuning). Der Parameter SORTHEAP sollte höher eingestellt werden, um so "sort overflows" zu vermeiden (DBM und DB Konfiguration). 7. Der Tablespace Typ für den "System catalog table space" sollte SMS sein und "temporary table spaces" und "DMS raw (device)" oder "File" sollte für den Rest definiert sein. Empfohlen wird die Ausführung der Prozedur "db2empfa", um die "multipage file allocation" für die SMS Tablespaces einzuschalten. Dies erlaubt den SMS Tablespaces in einem Zug per "extent" zu wachsen (anstatt "page"-weise). Das kann massive INSERT-Operationen und Sortvorgänge, die die Platten nutzen, erheblich beschleunigen. 8. Man nutze "parameter markers" für sich wiederholende SQL- Statements (SQL Statement Tuning). S.K. Consulting Services Seite 12 von 127

13 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.4 Voraussetzungen für SQL-Performance 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 Weitere den Leistungsdurchsatz 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 Zusammenhä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 S.K. Consulting Services Seite 13 von 127

14 Kapitel 2: Grundsätzliches zu DB2 und Performance 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 Ressourcen- und 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 Seite 14 von 127

15 Kapitel 2: Grundsätzliches zu DB2 und Performance 2.5 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 dann grob unterteilen in: Systemtechnische Aktivitäten Anwendungsbezogene Maßnahmen Die Tuningpotentiale des DB2-Systems S.K. Consulting Services Seite 15 von 127

16 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-Definifionen. Festlegung der Optionen für physische DB2-Objekte, wie z.b.: - Storagegroup / 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 Seite 16 von 127

17 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. Andere Trägersysteme 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 System- Services Database- Services IRLM - - Services DDF- Services Bild-03: Die DB2-Services im Überblick VSAM S.K. Consulting Services Seite 17 von 127

18 Kapitel 3: SQL Die Structured Query Language bei DB2 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 DELETE LABEL COMMENT 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. S.K. Consulting Services Seite 18 von 127

19 Kapitel 3: SQL Die Structured Query Language bei DB2 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 Gruppieren GROUP BY spezielle Aussagen LIKE HAVING UNION GROUP BY IN, ANY, ALL HAVING 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 TIMESTAMP WEEK, NULLIF, CASE COALESCE Weitere Funktionen(Beispiele): CLOB, BLOB ABS, ROUND, ACOS, ASIN, "Table Functions" ATAN, COS, MQREADALL, LOWER, UPPER MQRECEIVEALL LTRIM, RTRIM, RAND, REPEAT SIGN, STRIP, TAN, TRUNC... Bild-05: Grobe Übersicht über die SQL-Funktionen Eine Liste aller derzeit in DB2 implementierten builtin-functions mit Beispielen findet man im Anhang unter Pkt.11.1 ff. S.K. Consulting Services Seite 19 von 127

20 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 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 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 OR A = 'a2' A = 'a4' Bild-06: Die Selektion im RDB-Modell S.K. Consulting Services Seite 20 von 127