PERFORMANCE TUNING: OVERVIEW

Transkript

1 ORACLE TUNING TEIL 1 Einführung & Allgemeines

2 PERFORMANCE TUNING: OVERVIEW Schematische Darstellung der wichtigsten Einflussfaktoren auf die Performance Sessions SQL Blockgröße Memory I/O Locks Performance

3 SEGMENTS, EXTENTS UND BLOCKS Übersicht Tablespace Segments Extents Blocks Rows Default: 8KB Max: 32KB

4 SEGMENTS, EXTENTS UND BLOCKS Datenbankobjekte (Tabellen, Indizes, Partitionen) werden in Segmenten gespeichert Segmente bestehen aus mindestens 1 Extent (Initial Extent) Extent Allocation Auto (>64K/<64M) oder Uniform Allocation Uniform Allocation kann Fragmentierung reduzieren (Big- Tables)

5 PCTFREE UND PCTUSED PCTFREE gibt den für Updates zu reservierenden Speicherplatz in einem Block an Verfügbarer Speicherplatz: Blocksize Overhead PCTFREE PCTUSED gibt an, zu wieviel Prozent der Block nur gefüllt sein darf, um neue Rows aufnehmen zu dürfen Row-Chaining: Row muss über mehrere Blöcke verkettet abgelegt werden Row-Migration: Row wird nach Update in neuen Block verschoben, wenn aktueller Block (inkl. PCTFREE) das Update nicht aufnehmen kann PCTFREE = 20% High-Update-Tables = 40-50% empfohlen Low-Update-Tables = 5-10% empfohlen PCTUSED = 40% 100% PCTFREE 1 Row wird empfohlen

6 AUTOMATIC SEGMENT SPACE MANAGEMENT (ASSM) ASSM stellt eine wesentlich einfachere und effizientere Segmentverwaltung bereit. Insbesondere sind ausgedehnte Freelists nicht mehr nötig. Vorteile ergeben sich insbesondere bei Datensätzen stark variierender Größe. Nachteilig ist allerdings die längere Antwortzeit bei Full Table Scans sowie bei häufigen, parallelen Inserts. ASSM sollte bei OLAP-Datenbanken nicht benutzt werden. ASSM sollte bei OLTP-Datenbanken nur dann benutzt werden, wenn die Einfügefrequenz nicht zu hoch ist. Die Parameter PCTFREE und PCTUSED werden nicht mehr benötigt und werden gar ignoriert, falls sie gesetzt sind.

7 MULTIPLE FREELISTS Oracle verwaltet freie Blöcke unterhalb der Highwater-Mark (HWM) in Freelists Multiple-Freelists als Option bei Heavy-Concurrent-User-DML Session verwendet nur eine der Freelists Nicht mit ASSM verwendbar CREATE TABLESPACE mssmts DATAFILE '/u01/oradata/mssmts01.dbf' SIZE 500M SEGMENT SPACE MANAGEMENT MANUAL; CREATE TABLE test ( pid number not null primary key ) STORAGE (freelists 5) TABLESPACE mssmts;

8 DBBLOCKSIZE Der Parameter dbblocksize definiert die Größe der Datenblöcke. dbblocksize Muss ein ganzzahliges Vielfaches der Festplattenblockgröße sein kann laut Donald Burleson nachträglich beim Reorganisieren der Datenbank verändert werden darf zwischen 2048 und Byte liegen Default-Wert: 8192 Byte Größere Werte» erhöhen bei OLTP-Datenbanken die Wahrscheinlichkeit von Sperrsituationen» Bei OLAP-Datenbanken führen sie jedoch zu schnelleren Abfragen Kleinere Werte» führen bei OLAP-Datenbanken zu unnötig häufigen Festplattenzugriffen

9 DBFILEMULTIBLOCKREADCOUNT Gibt an, wie viele Datenblöcke bei Full Table Scans gleichzeitig und asynchron von der Festplatte gelesen werden können. Für OLAP-Datenbanken sollte er hoch gesetzt werden. Bei OLTP-Datenbanken kann ein zu hoher Wert den Optimizer zu unnötig häufigen Full Table Scans verleiten. Unter UNIX liest ORACLE grundsätzlich 64 KByte von der Festplatte. Daher kann es sinnvoll sein, wenn das Produkt von dbblocksize und dbfilemultiblockreadcount den Wert hat.

10 DBWRITERPROCESSES Durch den Initialisierungsparameter dbwriterprocesses kann die Anzahl der parallel laufenden DBWR-Prozesse definiert werden. Aktivitäten des DBWR: Der Database Writer (DBWR), schreibt Änderungen an den Datenblöcken in die Datendateien auf der Festplatte. Die Übertragung geänderter Datenblöcke aus dem Database Buffer in die Datendateien erledigt der Prozess DBWR nahezu kontinuierlich. DBWR Schreibt ASYNCHRON, wenn» Die Anzahl der Dirty Buffers zu hoch ist» Zu wenig Platz im Buffer-Cache ist» Das Zeitintervall abgelaufen ist (3 s)» Der Logwriter einen CHECKPOINT auslöst (z.b. wegen Logfile-Switch)

11 SQL HARD UND SOFT PARSES Jedes DDL/DML-Statement wird nach syntaktischem und semantischem Check in geparster Form nach Bestimmung eines Execution Plans in die SQL-Area geladen Dieser teils mit erheblichen Kosten verbundene Vorgang wird als Hard-Parse bezeichnet Vor dem Parsing wird über einen Hashvergleich bestimmt, ob sich das Statement bereits in der SQL-Area befindet. Wenn ja, kann der Aufwand für das Parsing eingespart werden, es wird dann das bereits vorhandene Statement für das Execute verwendet ( Soft Parse ) Wiederkehrende Statements sollten daher mit Bind-Variablen ausgeführt, um den Anteil der Soft Parses zu erhöhen mehrfache Hard Parses zu vermeiden

12 INDEXE (B-TREE) Die Blattknoten (Leaf) beinhalten Einträge, welche aus den indizierten Werten und der zugehörigen rowid (Nummer des Datensatzes in der Tabelle) aufgebaut sind Über den Wurzelknoten (Root) und die Zweigknoten (Branch) lässt sich der benötigte Blattknoten (Leaf) in logarithmischer Laufzeit auffinden (Unique Scan) Um Bereichanfragen effizent zu beantworten sind Blattknoten untereinander verkettet; alle anderen Werte im Bereich (Range Scan) lassen sich sequentiell finden

13 TABLE ACCESS BY INDEX (ROWID) Zeilen werden über physikalische Adresse (ROWID) ermittelt und die Blöcke gelesen Diesem schnellsten Zugriff auf eine Tabelle via ROWID geht immer ein Index-Zugriff voraus» Index Unique Scan = Auffindung von einer ROWID im Index» Index Range Scan = Auffindung von mehr als einer ROWID im Index» Index Full Scan = Abruf aller ROWIDs aus dem Index, kann sortiert werden» Index Fast Full Scan = Abruf aller ROWIDs über Multiblock I/O, nicht sortierbar SELECT * FROM sh.customers WHERE custid = 1; SELECT * FROM sh.customers WHERE custid > 1 AND custid < 10; SELECT custid FROM sh.customers ORDER BY custid; SELECT custid FROM sh.customers WHERE custid > 1;

14 NESTED LOOP, SORT MERGE JOIN UND HASH JOIN Verknüpfung von zwei Ergebnismengen (bei Plan über mehrere Tabellen bzw. Indizes) Nested Loop = Für jeden Satz der 1. Menge wird die 2. Menge durchsucht (kostengünstig bei kleinen Ergebnismengen und Cartesian Products) Sort Merge Join = Bei gleicher Sortierung des Join-Kriteriums beider Mengen (kostengünstig bei zwei gleich geordneten Ergebnismengen nach Join-Kriterium) Hash Join = Caching der kleineren Ergebnismenge, Berechnung eines Hash (kostengünstig, bei kleiner mit großer Ergebnismenge, kleine Menge wird gepuffert und gehasht) SELECT cu.custlastname FROM oe.customers cu, oe.orders od WHERE cu.customerid = od.customerid; SELECT * FROM sh.customers cu, sh.countries co WHERE co.countryid = cu.countryid;

15 SUBQUERYS [NOT ]IN UND EXISTS Eine IN-Subquery muss für jede Zeile der äußeren Query ausgeführt werden (Nested) Eine EXISTS-Subquery muss nur einmal ausgeführt werden (Ausnahme: korrelierte Subquery) Standard-Joins sind generell meistens kostengünstiger als Subquerys und sollten wenn möglich daher immer bevorzugt werden SELECT c1.customerid FROM oe.customers c1 WHERE c1.customerid IN (SELECT customerid FROM oe.customers c2); SELECT c1.customerid FROM oe.customers c1 WHERE EXISTS (SELECT customerid FROM oe.customers c2);

16 QUERY HINTS Über Query-Hints kann das Verhalten des CBO positiv wie negativ beeinflusst werden Die manuelle Beeinflussung der Plan-Erstellung kann Kosten für das SQL-Parsing sparen Ordered-Hint = Erzwingt die Verarbeitung der From-Klausel in angegebener Reihenfolge SELECT * FROM oe.customers cu, oe.orders od WHERE cu.customerid = od.customerid; SELECT /*+ ordered */ * FROM oe.customers cu, oe.orders od WHERE cu.customerid = od.customerid; Entscheidung des CBO auf Basis der Statistik war hier richtig, Orders als Driving-Table zu nehmen (Count= 105) Query-Hint erzwingt Customers als Driving-Table, hier negative manuelle Einflußnahme (Count = 319)

17 QUERY HINTS Hint ALLROWS CACHE(table) FIRSTROWS(n) FULL(table) INDEX(table index) INDEXFFS(table index) NOINDEX(table index) Beschreibung Verwendung des CBO, optimaler Throughput In Kombination mit Full, Tabelle wird im Buffer gecached Verwendung des CBO, schnelle Rückgabe erster Zeilen Veranlasst den CBO, für die Tabelle einen FTS durchzuführen Zwingt den CBO, den angegebenen Index zu verwenden Zwingt den CBO, den Index mit Fast Full Scan zu verwenden Zwingt den CBO, den angegebenen Index nicht zu verwenden Eine vollständige Auflistung aller Hints ist verfügbar unter:

18 VORGEHENSWEISE BEIM TUNING Schritte: Tunen von Oben nach Unten (Top-Down)» Anwendung vor SQL» SQL vor Instanz Stets dort tunen, wo die größte Einsparung liegt» Wo sind die längsten Wartezeiten?» Wo sind die längsten Antwortzeiten? Wenn Ziel erreicht ist: Aufhören!! Hilfsmittel: Statspack Kostenfrei AWR/ADDM muss gesondert lizensiert werden

19 SQL TUNING TIPPS Function-based-Indexes nutzen, wenn Funktionen in Where-Bedingungen genutzt werden Partionierung, IOT und Bitmap-Indexes in Betracht ziehen Bind-Variablen, Table-Aliase und FQN verwenden Cursor-Loops vermeiden, SQL ist meist schneller als PL/SQL (Context-Switching)! Distinct und Union sind kostenintensiv, Union All aber nicht! Full-Table-Scans vermeiden, wenn < 40% der Zeilen betroffen sind Kleine Tabellen, die FTS unterliegen, in den Keep-Pool des Buffer-Cache aufnehmen EXISTS und NOT-EXISTS als Outer-Joins umschreiben Temporäre Tabellen bei komplexen Unterabfragen in Betracht ziehen Denormalisierung und Materialized Views bewusst einsetzen

20 ORACLE TUNING TEIL 2 Einsatz von Automatischem SQL-Tuning

21 SQL-TUNING Schlecht laufende SQL-Statements können eine Applikation massiv verlangsamen. Kommt es in der Applikation zu datenbankseitigen Performanceproblemen, hat dies meist mit schlecht laufenden SQL- Statements zu tun. Leider haben Entwickler oft zu wenig SQL-Tuning-Kenntnisse. DBAs haben meist zu wenig Kenntnisse bzgl. der Applikation. Klassische Verfahren sind das Erstellen und Analysieren von Trace- Files und die Analyse von sog. Ausführungsplänen. Beides setzt einiges an Erfahrung voraus. An dieser Stelle setzen die Möglichkeiten des Automatischen SQL- Tunings von Oracle ein, die beide Seiten bei der Lösung von Performanceproblemen unterstützen. 21

22 BEGRIFFE RUND UM DAS AUTOMATISCHE SQL-TUNING Automatic Tuning Optimizer (ATO) Query Optimizer SQL Tuning Advisor SQL Tuning Tasks SQL Tuning Sets SQL Profile Automatic Workload Repository (AWR) Diese Begriffe und die damit verbundenen Funktionalitäten sind zahlreichen Administratoren und Entwicklern nicht wirklich bekannt. 22

23 QUERY OPTIMIZER / AUTOMATIC TUNING OPTIMIZER Ausführungspläne SQL- Statements Query Optimizer Query Optimizer muss sich beeilen! Der sog. Automatic Tuning Optimizer kann sich hingegen mehr Zeit lassen. Ein Expertensystem, das bei Bedarf aufgerufen wird, längere Laufzeiten hat und dem Anwender Tuning-Tipps inkl. Skripts hierfür liefert. Oracle-Datenbank 23

24 WIE SIEHT EIN SQL-AUSFÜHRUNGSPLAN AUS? 24

25 WIE KOMMT DIE DATENBANK ZU EINER ENTSCHEIDUNG? Die Datenbank muss viele Dinge entscheiden. Z.B.: Wird über einen Index (falls es einen passenden gibt) zugegriffen oder lieber die ganze Tabelle gescannt. Wie werden Joins durchgeführt (z.b. Hash-Joins oder Nested Loops) Um solche Entscheidungen treffen zu können, benötigt der Query Optimizer Informationen, die sog. Statistiken, die im sog. Data Dictionary abgelegt werden. Oracle erfasst Statistiken großenteils automatisch. Der Automatic Tuning Optimizer erfasst zahlreiche zusätzliche Informationen, die mit den normalen Statistiken nicht erfasst werden. Das führt zu Verbesserungsvorschlägen und/oder besseren Ausführungsplänen. 25

26 SQL-TUNING ADVISOR Das Werkzeug, mit dem der Automatic Tuning Optimizer dieses tut, ist der SQL Tuning Advisor (Package DBMSSQLTUNE). Der Anwender kann hiermit explizit SQL-Statements detailliert untersuchen lassen. Meist sind dies Statements, von denen man festgestellt hat, dass sie große Last auf der Datenbank verursachen und so ggf. die gesamte Anwendung ausbremsen. Dies kann viele Gründe haben (z.b. fehlende Indizes, Defragmentierung, veraltete Statistiken, suboptimale Ausführungspläne). Die Statements werden an den SQL Tuning Advisor übergeben und dieser prüft nun, welche Optimierungsmöglichkeiten es gibt. 26

27 SQL TUNING TASKS Zu diesem Zweck legt der SQL Tuning Advisor eine Aufgabendefinition (Task) in der Datenbank an, der die Untersuchung vornehmen soll. Dies ist der sog. SQL Tuning Task. Anlegen eines Tuning Tasks: DBMSSQLTUNE.CREATETUNINGTASK Ausführen eine Tuning Tasks: DBMSSQLTUNE.EXECUTETUNINGTASK Tuning-Bericht anzeigen: DBMSSQLTUNE.REPORTTUNINGTASK Löschen eines Tuning Tasks: DBMSSQLTUNE.DROPTUNINGTASK 27

28 SQL TUNING TASKS UND SQL PROFILE Der Bericht, den der SQL Tuning Advisor mit Hilfe eines Tuning Tasks erstellt, kann verschiedene Arten von Verbesserungsvorschläge enthalten. Er enthält nicht nur Vorschläge sondern auch die Skripte, mit denen man diese Vorschläge direkt umsetzt! SQL Tuning Advisor kann ein SQL-Statement nehmen und verschiedene Ausführungsplanvarianten schlicht ausprobieren. Findet er einen Plan, der besser ist, als der der zur Zeit verwendet wird, legt er ein sog. SQL Profil an. Ein SQL Profil enthält einige zusätzliche Statistiken zu einem SQL- Statement. Meist ist es sinnvoll, einen vorgeschlagenes SQL Profil zu akzeptieren DBMSSQLTUNE.ACCEPTSQLPROFILE Mehrere SQL-Statements können zu einem sog. SQL Tuning Set zusammengefasst und gemeinsam analysiert werden 28

29 NOCHMAL DIE BEGRIFFE IM ÜBERBLICK SQL-Statement Query Optimizer Ausführungsplan SQL Tuning Task Tuning- Vorschläge SQL-Profil SQL Tuning Advisor Automatic Tuning Optimizer 29

30 SQL-TUNING IM ORACLE ENTERPRISE MANAGER Übersicht im Bereich Performance 30

31 SQL-TUNING IM ORACLE ENTERPRISE MANAGER Übersicht im Bereich Top Aktivität 31

32 SQL-TUNING IM ORACLE ENTERPRISE MANAGER Maske zu SQL Tuning Advisor planen 32

33 SQL-TUNING IM ORACLE ENTERPRISE MANAGER Lauf eines Tuning Tasks 33

34 SQL-TUNING IM ORACLE ENTERPRISE MANAGER Ergebnis des Tuning Tasks; in diesem Fall ein SQL Profil 34

35 SQL-TUNING IM ORACLE ENTERPRISE MANAGER Vergleich alter und neuer Ausführungsplan 35

36 AWR (AUTOMATIC WORKLOAD REPOSITORY) Oft ist es allerdings nicht im ersten Moment klar, welche SQL- Statements für die Performanceprobleme zuständig sind. Hier kann das sog. AWR (Automatic Workload Repository) weiterhelfen. Das AWR sammelt, wenn aktiviert, permanent zahlreiche Statistiken zu aktiven Sessions, Zugriffen, Warteereignissen etc. Auf die Informationen des AWR kann über zahlreiche Dictionary Views zugegriffen werden. Auf den Informationen des AWRs baut der sog. ADDM (Automatic Database Diagnostic Monitor) auf. Der ADDM gibt einen Report mit Empfehlungen zur DB aus. Ein Beispiel 36

37 VIELEN DANK für Ihre Aufmerksamkeit Falls Sie Fragen zu dieser Präsentation haben, sprechen Sie uns einfach an. Ihre Ansprechpartner Dr. Götz Gleitsmann Frank Winter