Tuning Johannes Ahrends Technical Director Presales Consulting Quest Software GmbH

Transkript

2 Agenda Was ist Tuning? Beispiele aus der Praxis Der Optimizer Kleine Historie Tuningmöglichkeiten Statistiken Zugriffsmethoden Hints Tuningwerkzeuge Datenbank-Parameter Vorausschauende Programmierung 1

3 Was ist Tuning? Tuning ist die Summe aller Maßnahmen, welche die Optimierung der Antwortzeiten und die Verbesserung der Skalierbarkeit zum Ziele haben. (Dr. Günter Unbescheid) 2

4 Tuningpotential Klassische Anforderung: 90% des Optimierungspotential liegt in den SQL-Befehlen HW Network DB Changes Indexes 90% 60% SQL Statements Quelle: Forrester Research 3

5 Übliche Beschwerden (1) Ein Anwender beschwert sich über die schlechten Antwortzeiten der Applikation Grund? Schlecht geschlafen Schlechtes Wetter Streit mit dem (Ehe)-Partner Fehlerhafte Bedienung Lösung? Andere Anwender fragen (schwierig bei schlechtem Wetter) Nachsehen, ob in der Datenbank alles in Ordnung ist Tägliche oder stündliche Vergleichsmessungen 4

6 Übliche Beschwerden (2) Die Anwender beschweren sich über die schlechten Antwortzeiten der Applikation Grund? Neue Anwendung Falsche Statistiken Anwendungen kommen sich in die Quere Lösung? Anwendungen testen Statistiken einfrieren Anwendungen entkoppeln Alarmierung bei zu langen Batchläufen 5

7 Übliche Beschwerden (3) Nach der Umstellung auf ein neues Release ist die Anwendung wesentlich langsamer Grund? Anwender wollen die neue Anwendung nicht (torpedieren) Falsche Statistiken Falsche Parametrierung Lösung? Anwender schulen Neue Statistiken erstellen Datenbank / Instanzparameter überprüfen 6

8 Ein paar Praxisfälle (1) Problem: Nach Umstellung einer Datenbank von Version 8i auf Version 9i beschweren sich die Anwender (1500!) darüber, dass die Performance immer wieder einbricht (unkalkulierbar). Grund: In Version 9i wurden u.a. zwei neue Parameter eingeführt: pga_aggregate_target und workarea_size_policy Default: pga_aggregate_target = 32 MB workarea_size_policy = AUTO sort_area_size ignoriert Lösung: pga_aggregate_target = 1000 MB 7

9 Ein paar Praxisfälle (2) Problem: Eine Anwendung scheint immer wieder zu hängen Grund: Aufgrund mangelndem Oracle Knowhow wurde die Datenbank (Oraclei8i) mit Default-Einstellungen installiert Default für Redolog-Dateien (bis Oracle8i) 3 x 512 KB Lösung: Drei neue Redolog-Dateien mit je 50 MB 8

10 Ein paar Praxisfälle (3) Problem: Eine einfache Abfrage dauert ca. 5 Minuten SELECT DISTINCT produktname, warenwelt, gruppe FROM produktinformationen 9

11 Grund: View auf View auf View auf 10

12 Regelbasierter Optimizer (RBO) Grundsätzlich Untersucht so viele Pläne wie Tabellen in der Abfrage vorkommen Jeder Plan korrespondiert mit einer Tabelle am Anfang der Liste Nachfolgende Tabellen werden entsprechend der günstigsten Zugriffsmethode angeordnet Join-Reihenfolge Bei jedem Join wählt der Optimizer zwischen Nested-Loop und Sort-Merge Der (nach verschiedenen Kriterien) beste Plan wird behalten Bei gleicher Effizienz wird der Plan gewählt, der mit der letzten Tabelle der FROM-Klausel beginnt 11

13 Kostenbasierter Optimizer (CBO) Grundsätzlich Analyse für n Permutationen der in der Abfrage vorkommenden Tabellen durchgeführt n wird über den Initialisierungsparameter optimizer_max_permutations gesetzt (Default 2000) Für jede Permutation werden verschiedene Pläne analysiert (Zugriffs- und Join-Methoden unter Berücksichtigung aller hints), und der mit den geringsten Kosten wird behalten Schließlich wird die kostengünstigste Permutation (und ihr Plan) genutzt Die Kosten basieren auf der Anzahl logischer Reads, verfügbarem Speicher, Prozessorauslastung werden aufgrund der Statistiken, die für die verschiedenen Objekte verfügbar sind, kalkuliert 12

14 RBO oder CBO RBO Wird nicht von Oracle empfohlen (kein Support mehr ab Oracle 10g) Neue Technologien (Bitmap, Hash Join, Partioning, ) werden nicht angewendet Erlaubt keine Hints auf Statement-Ebene CBO von Oracle empfohlen Je besser die Statistiken, desto besser der Ausführungsplan! 13

15 Eine kleine Historie Oracle 6: Erste Tuningerfolge Oracle 7: Cost-Based-Optimizer Oracle 8: Statistiken fälschen Oracle8i: Function-Based Index Oracle9i: Systemstatistiken Oracle 10g: Automatisches Tuning 14

16 Oracle 6: Erste Tuningerfolge SQL: Rule-Based Optimizer -14 definierte Regeln Optimale Ergebnisse nur durch optimale Programmierung Wichtige Entwicklungen: Extents Tablespaces mit mehreren Datafiles Row-level-locking PL/SQL Programmierung (Procedural Option) Parameter: row_level_locking db_block_buffer log_buffer Datenbankgröße: < 1 GB 15

17 Oracle 7: Cost Based Optimizer SQL: Data-Warehouse Anwendungen bedingen den intelligenten Optimierer Objektstatistiken als Bewertungsgrundlage Hohe Zeiten für Parsing (Permutationen) Wichtige Entwicklungen: Shared-Pool für die Wiederverwendung von Ausführungsplänen Bitmapped-Index Parallel Query Parameter: optimizer_mode shared_pool_size Datenbankgröße: 1 10 GB 16

18 Oracle 8: Statistiken fälschenf SQL: Statistiken können angepasst und gespeichert werden Parallelisierung durch Partitionierung Wichtige Entwicklungen: Partitionierung Index Organized Tables Reverse Key Indexing dbms_stats Package Parameter: optimizer_max_permutation db_file_multiblock_read_count Datenbankgröße: GB 17

19 Oracle8i: Function-Based Index SQL: Zwischenspeicherung von Ergebnissen in temporäre Tabellen Anwender können in Ressourcengruppen aufgeteilt werden Wichtige Entwicklungen: Locally Managed Tablespaces Online Index Reorganistion Query Rewrite Function Based Index Plan Stability Temporäre Tabellen Parameter: optimizer_index_cost_adj cursor_sharing Datenbankgröße: GB 18

20 Oracle9i: Systemstatistiken SQL: Bessere Ressourcennutzung durch Systemstatistiken Reproduzierbare Ergebnisse durch Flashback Query Wichtige Entwicklungen: Oracle Real Application Clusters Automatic Segment Space Management Multiple Blocksize UNDO-Tablespaces Native PL/SQL Compilation Index Simulation Parameter: sga_max_size pga_aggregate_target Datenbankgröße: GB 19

21 Oracle 10g: Automatisches Tuning SQL: Automatische Anpassung der Ressourcen für Buffer-Cache und Shared Pool Automatisches Monitoring aller Objekte für optimale Statistiken Wichtige Entwicklungen: Automatic Workload Repository (AWR) Automatic Database Diagnostic Monitor (ADDM) Automatic Storage Management (ASM) Online Shrink Automatic Memory Management Active Session History Report (ASH) Parameter: sga_target Datenbankgröße: GB 20

22 Was bietet das größ ößte Tuningpotential? V6 Umschreiben der Anwendung / Befehl Indizierung I/O Verteilung Datenbank / Instanz Parametrierung Reorganisation V7 Statistiken Hints V9 Real Application Clusters Systemstatistiken Unterschiedliche Blocksizes V10 feingranulare Statistiken 21

23 Erstellung von Statistiken Befehl ANALYZE Mit Oracle7 eingeführt Analysiert Tabellen und Indizes Keine Systemstatistiken Füllt Spalten chain_cnt, avg_space, avg_row_len Package dbms_utility analyze_schema analyze_database Führt den Befehl ANALYZE für mehrere Objekte aus Package dbms_stats Analysiert Objekt, Schema, Datenbank oder System 22

24 DBMS_STATS Package Erweiterte Analyse-Möglichkeiten für Partitionen, Subpartitionen, geclusterte Tabellen, lokale und globale Indizes Statistik-Gewinnung seriell oder parallel Nur Statistik-Werte für CBO werden ermittelt, chained_rows, average_space, unused_blocks werden nicht gepflegt 23

25 Automatische Statistiken Über DBMS_STATS-Package DBMS_STATS.GATHER_SCHEMA_STATS('JAHR', options => => 'GATHER AUTO'); DBMS_STATS.GATHER_DATABASE_STATS( options => => 'GATHER AUTO'); Erstellt neue Statistiken für Objekte, die sich um mehr als 10% geändert haben Voraussetzung: Option MONITORING für Tabellen gesetzt dbms_stats.alter_schema_table_monitoring('scott') dbms_stats.alter_database_table_monitoring(true) 24

26 Gespeicherte Statistiken Statistiken können über DBMS_STATS gespeichert, historisiert, ausgewertet und zurückgesetzt werden Prozeduren für Export, Import, Set der Statistiken Statistiken können somit gefälscht werden, um das Verhalten des CBO in einer Testdatenbank mit Datenmengen aus der Produktion simulieren zu können 25

27 Plan Stability Ausführungspläne werden als sog. Stored outlines gespeichert Konservieren von Plänen, um stabile Ausführungszeiten zu garantieren Stored Outlines können zwischen Systemen transportiert werden Unterschiedliche Kategorien von Stored Outlines möglich User OUTLN mit 2 Tabellen OL$ und OL$HINTS Parameter QUERY_REWRITE_ENABLED = TRUE 26

28 Zugriffsmethoden Oracle ermöglicht den Zugriff auf Tabellendaten auf drei Arten Lesen der gesamten Tabelle (Full Table Scan) Zugriff über Index B*Tree Index Bitmapped Index Function-Based Index Bitmapped Join Index Index Organized Table (IOT) Zugriff über die direkte Angabe einer Row-ID 27

29 Full Table Scan Die gesamte Tabelle wird durch sogenannte multiblock-reads gescannt, deren Größe (in Blöcken) durch den Parameter DB_FILE_MULTIBLOCK_READ_COUNT festgelegt wird Alle Blöcke unterhalb der HWM = High Water Mark werden gelesen Der Parameter beeinflusst den Cost Based Optimizer 28

30 B*Tree Index SQL> SELECT * FROM PERSONEN WHERE PERSNR = 4711; AA A PERSNR BLOCK A B PERSNR BLOCK PERSNR BLOCK AA BA AB BX B BX PERSNR ROWID PERSNR ROWID 1 b.aaa b.aaa.03 2 b.ae b.abc.06 Root-Block Branch-Block Leaf-Block PERSNR VORNAME NACHNAME 1 Hans Meier 147 Klaus Schmidt 4711 Trude Herr Table-Block 29

31 B*Tree Index Balanced Tree Index-Organisation Der Index wird, beginnend am Ursprung, blockweise gescannt, dann erfolgt der Zugriff auf die Tabellenblöcke Characteristika Speicherintensiv Speichert keine NULL-Werte Gute Performance bei Selektiven Auswahlbedingungen Zeilen mit gleichen Schlüsselwerten, die so weit wie möglich in gleichen Tabellenblöcken gruppiert sind 30

32 B*Tree Index Effizient für Daten mit hoher Kardinalität. Beispiel: Ein Index auf einer date-spalte Länge = 24 Byte 8Byte (Länge des Datentyps) + 10 Byte (Länge der Rowid) + 6 Byte (Kontrollinformation) Bei einer Blockgröße (DB_BLOCK_SIZE) von 8 Kbyte ergibt sich verfügbarer Raum von 8192 bytes pro Block Headergröße (zwischen 100 and 200 Bytes im Beispiel 192 Bytes angenommen) = 8000 Bytes, zu 75% gefüllt = 6000 Bytes Ein Block kann also 6000 / 24 = 250 Schlüssel beinhalten. Ein Baum mit einer Tiefe von 3 kann demzufolge 250 x 250 x 250 = Millionen Schlüssel verarbeiten. Um einen von 15 Millionen Werten zu ermitteln, genügen 3 I/O- Operationen im Index plus eine I/O-Operation pro Zeile in der Tabelle 31

33 B*Tree Index Ineffizient für: Einen Index auf der Primärschlüsselspalte einer kleinen Tabelle (z.b. 10 Zeilen) Einen Index auf einer Spalte mit wenigen unterschiedlichen Werten = niedrige Kardinalität (z.b. Geschlecht) Einen Index auf einer Spalte, in der oft Funktionen verwendet werden (z.b. upper(lastname)) Ein effizientes I/O-System mit Parallelisierungsmöglichkeiten (z.b. db_file_multiblock_read_count hoch) In diesen Fällen sollte der Optimizer keine Indizes verwenden 32

34 B*Tree Indexregeln Selektivität der Abfragen gewährleisten, die den Indexschlüssel verwenden: weniger als 5 bis 15% der Zeilen einer Tabelle als Ergebnis (Abhängig von der Datenverteilung in der Tabelle) Spaltenreihenfolge bei Verwendung zusammengesetzter Indizes beachten Keine Indizes bei kleinen Tabellen (außer unique- Indizes) Für unique-indizes PRIMARY KEY-oder UNIQUE Constraints verwenden Abfragen für die Verwendung von Indizes optimieren DML-Performanceeinflüsse beachten 33

35 Bitmapped Index Jeder Schlüsselwert wird als Bitmap-Segment gespeichert; der Zugriff auf Segmente erfolgt durch einen B-Tree-Index Der Index wird wie ein B-Tree gescannt, anschließend wird die Bitmap in ROWID's konvertiert Characteristika Weniger speicheraufwändig Speichert NULL-Werte Starker Einfluss auf DML-Operationen Effizient bei Kombinierten, nicht sehr selektiven Auswahlbedingungen Schnelle AND- und OR-Kombinationen über mehrere Indizes 34

36 Bitmapped Index Anwendungsregeln Mehr bei Abfragesystemen (OLAP, Datawarehouse) als bei Transaktionssystemen (OLTP) Indexspalten mit geringer Kardinalität werden bei mehreren Bedingungen durch AND und OR kombiniert Starker Performanceinfluss auf DML-Operationen Anlegen: SQL> CREATE BITMAP INDEX name ON (column_list) ; Spezielle Parameter CREATE_BITMAP_AREA_SIZE: Default-Wert = 8MB = OK BITMAP_MERGE_AREA_SIZE: Default-Wert = 1MB = OK 35

37 Function Based Index Ein B-Tree Index, auf das Ergebnis einer Funktion Erlaubt die effiziente Verarbeitung von SQL- Statements einschließlich der Verwendung von Funktionen in der WHERE-Klausel Voraussetzungen QUERY_REWRITE_ENABLED = TRUE (auf Instanz- oder Sitzungsebene) Statistiken für die Tabelle und den Index Costbased Optimizer Verhalten wie B*Tree Index Index kann bei Änderung der Funktion unusable werden 36

38 Index Organized Table (IOT) Die gesamte Tabelle wird im B-Tree Index des Primärschlüssels gespeichert Zugriff erfolgt wie beim B-Tree Index, jedoch ohne Sekundärstruktur Characteristika Keine ROWID Zusätzliche Indizes sind möglich Geringerer Platzbedarf Overflow-area Effizient bei Zugriff mit Bereichs- oder Gleichheitsbegrenzenden Eigenschaften des Primärschlüssels 37

39 Index Organized Table (IOT) Anwendungsregeln Eher für Tabellen geeignet, auf die allein über den Primärschlüssel zugegriffen wird Eher für Tabellen geeignet, deren Zeilengröße geringer ist als die halbe Blockgröße 38

40 Reverse Key Indexes Ein B-Tree-Index mit umgekehrter Anordnung der Bytes in jeder Schlüsselspalte Index wird wie ein normaler B-Tree gescannt Characteristika Benachbarte Werte liegen im Index weit auseinander Effizient bei Index auf Primärschlüssel oder Datumsfelder, da hier in der Regel immer ans Ende eingefügt wird Nachteile Keine Range-Scans möglich Anlegen CREATE INDEX name ON (columns_list) REVERSE; 39

41 Bitmapped Join Index Speichert die Rowid's einer Tabelle (fact table) mit der Spalteninformation einer anderen Tabelle (dimension table) Wird hauptsächlich in Data Warehouses verwendet CREATE BITMAP INDEX b_join_vertrieb ON ON DWH_KUNDEN(m.m_nachname) FROM dwh_kunden k, k, mitarbeiter m WHERE k.vertrieb = m.m_nr COMPUTE STATISTICS; 40

42 Handhabung von Indizes Beim Anlegen von Indizes zu beachten: Große SORT_AREA_SIZE Möglichkeiten der Parallelisierung nutzen (Vorsicht! SORT_AREA_SIZE gilt für jeden Prozess) nologging-option nutzen Speicherung in separatem Tablespace (IO-Verteilung) Administration: Tiefe eines Indexbaumes beobachten SQL> SELECT index_name, num_rows, blevel FROM dba_indexes WHERE blevel > 2; 2; 41

43 Beispiel SELECT * FROM FROM auftraege WHERE WHERE to_char(aufdatum,'dd.mm.yyyy') = ' ' Indizierung? CREATE INDEX INDEX idx_aufdatum ON ON auftraege (to_char(aufdatum,'dd.mm.yyyy')); Bessere Lösung? SELECT * FROM FROM auftraege WHERE WHERE aufdatum >= >= to_date(' ', 'DD.MM.YYYY') AND AND aufdatum < to_date(' ', 'DD.MM.YYYY')

44 Zugriffsmethoden Full Table Scan SELECT vorname, nachname FROM FROM personen WHERE WHERE ort ort = 'Köln'; Execution Plan Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE TABLE ACCESS (FULL) OF OF 'PERSONEN' 43

45 Zugriffsmethoden ROWID bekannt SELECT vorname, nachname FROM FROM personen WHERE WHERE rowid rowid = 'AAALWYAAGAAAJiiAAA'; Execution Plan Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE TABLE ACCESS (BY (BY USER USER ROWID) OF OF 'PERSONEN' 44

46 Zugriffsmethoden Unique B-Tree-Index SELECT vorname, nachname FROM FROM personen WHERE WHERE persnr = 4711; 4711; Execution Plan Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE TABLE ACCESS (BY (BY INDEX INDEX ROWID) OF OF 'PERSONEN' 2 1 INDEX INDEX (UNIQUE SCAN) SCAN) OF OF 'PK_PERSONEN' (UNIQUE) Eindeutiger B-Tree-Index PK_PERSONEN auf PERSONEN (persid) 45

47 Zugriffsmethoden Wertebereich oder Non-Unique B-Tree-Index SELECT vorname, nachname FROM FROM personen WHERE WHERE nachname = 'Ahrends'; Execution Plan Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE TABLE ACCESS (BY (BY INDEX INDEX ROWID) OF OF 'PERSONEN' 2 1 INDEX INDEX (RANGE SCAN) SCAN) OF OF 'IDX_NAME' (NON-UNIQUE) Einfacher B-Tree-Index IDX_NAME auf PERSONEN (nachname) 46

48 Zugriffsmethoden B-Tree-Index ohne Zugriff auf die Tabelle SELECT vorname, nachname FROM FROM personen WHERE WHERE nachname = 'Ahrends'; Execution Plan Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 INDEX INDEX (RANGE SCAN) SCAN) OF OF 'IDX_NAME' B-Tree-Index IDX_NAME auf PERSONEN (nachname, vorname) 47

49 Zugriffsmethoden Zugriff durch vollständigen B-Tree-Scan SELECT vorname, nachname FROM FROM personen WHERE WHERE vorname = 'Johannes'; Execution Plan Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 INDEX INDEX (FAST (FAST FULL FULL SCAN) SCAN) OF OF 'IDX_NAME' (NON-UNIQUE) B-Tree-Index IDX_NAME auf PERSONEN (nachname, vorname) 48

50 Zugriffsmethoden Zugriff durch Bitmap-Index auf einem einzelnen Wert SELECT vorname, nachname FROM FROM personen WHERE WHERE ort ort = 'Köln'; Execution Plan Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE TABLE ACCESS (BY (BY INDEX INDEX ROWID) OF OF 'PERSONEN' 2 1 BITMAP CONVERSION (TO (TO ROWIDS) 3 2 BITMAP INDEX INDEX (SINGLE VALUE) OF OF 'BIDX_ORT' Bitmap-Index BIDX_ORT auf PERSONEN (ort) 49

51 Zugriffsmethoden Zugriff durch Bitmap-Index auf mehreren Werten SELECT vorname, nachname FROM FROM personen WHERE WHERE ort ort = 'Köln' AND AND nachname = 'Ahrends'; Execution Plan Plan SELECT STATEMENT Optimizer=CHOOSE 1 0 TABLE TABLE ACCESS (BY (BY INDEX INDEX ROWID) OF OF 'PERSONEN' 2 1 BITMAP CONVERSION (TO (TO ROWIDS) 3 2 BITMAP AND AND 4 3 BITMAP INDEX INDEX (SINGLE VALUE) OF OF 'BI_ORT' 5 3 BITMAP INDEX INDEX (SINGLE VALUE) OF OF 'BI_NAME' Bitmap-Index BI_ORT auf PERSONEN (ort) Bitmap-Index BI_NAME auf PERSONEN (nachname) 50

52 Hints Optimizer-Anweisungen für ein Statement Änderung des Optimizer-Modus' für die Dauer der Abfrage (gilt für RBO und CBO) präzise Anweisungen an den Optimizer zur Ausführung eines Statements (gilt nur für CBO) Für SELECT, UPDATE, DELETE oder Subqueries Syntax Kommentar gefolgt von einem Pluszeichen (+) SELECT /*+ */ deviceid FROM device; Können kombiniert werden Tabellen-Alias muss im Hint verwendet werden Ein fehlerhafter Hint wird ignoriert 51

53 Wichtige Hints - Zugriff /*+ FULL(table) */ Zugriff über Full Table Scan /*+ INDEX(table [index, ]) */ Zugriff über Index /*+ APPEND */ Direct-Path Inserts möglich (Nologging-Option) Standard bei paralleler Verarbeitung 52

54 Wichtige Hints - Join /*+ ORDERED */ Join der Tabellen in der Reihenfolge der FROM-Klausel /*+ USE_NL(table1 [,table2, ]) */ Nested-Loop-Join (verschachtelte Schleifen) Angegeben werden die Tabellen, die an eine bereits existierende Ergebnissmenge angehängt werden sollen /*+ USE_MERGE(table1 [table2, ]) */ Tabellen werden nach Join-Kriterium sortiert und dann verglichen (Einstellung sort_area_size wichtig!) /*+ DRIVING_SITE(table) */ Ausführung auf einer bestimmten Seite (in verteilten Umgebungen) 53

55 Beispiel 54

56 Welches sind die wichtigsten Tools? V6 Explain Plan tkprof bstat / estat V$SQLAREA / V$SQLTEXT SQL*Plus autotrace + timing nst-skripte V7 Oracle Enterprise Manager V8 Statspack V9 V$SQL / v$sqlplan V10 ADDM AWR ASH Anwendungstracing (dbms_monitor) 55

57 Explainplan SQL> SQL> SELECT SELECT aufnr aufnr FROM FROM positionen positionen WHERE WHERE aufnr aufnr not not in in (SELECT (SELECT aufnr aufnr FROM FROM auftraegestorno); Execution Execution Plan Plan SELECT SELECT STATEMENT STATEMENT Optimizer=CHOOSE (Cost=740 (Cost=740 Card=49442 Card=49442 Bytes=395536) Bytes=395536) 1 0 NESTED NESTED LOOPS LOOPS (ANTI) (ANTI) (Cost=740 (Cost=740 Card=49442 Card=49442 Bytes=395536) Bytes=395536) 2 1 INDEX INDEX (FAST (FAST FULL FULL SCAN) SCAN) OF OF 'PK_AUFTRAGSNR' 'PK_AUFTRAGSNR' (UNIQUE) (UNIQUE) (Cost=75 (Cost=75 Card= Card= Bytes=598556) Bytes=598556) 3 1 INDEX INDEX (UNIQUE (UNIQUE SCAN) SCAN) OF OF 'PK_AUFTRAEGE' 'PK_AUFTRAEGE' (UNIQUE) (UNIQUE) (Cost=1 (Cost=1 Card= Card= Bytes=400788) Bytes=400788) Die Anzeige kann je nach verwendetem Tool leicht variieren, die Schlüsselwörter bleiben jedoch die selben 56

58 Einen Ausführungsplan verstehen Beim kostenbasierten Optimizer sind zusätzliche Informationen verfügbar (nur AUTOTRACE oder EXPLAIN PLAN) COST: geschätzte Kosten (Information vom Optimizer) CARD (CARDINALITY): Anzahl der geschätzen Zeilen BYTES: Anzahl der geschätzen Bytes 57

59 Anwendungstracing Tracing von Anwendungen Erstellt eine Tracedatei im Verzeichnis user_dump_dest ALTER ALTER SESSION SET SET SQL_TRACE = TRUE; TRUE; oder SID SID und und SERIAL# aus aus v$session ermitteln und und dann: execute dbms_system.set_sql_trace_in_session(sid,serial#,true); Tracedateien anschließend mit tkprof bearbeiten: tkprof <tracename> <outputdatei> explain=<benutzer>/<kennwort> [sys=no] [sort=<sortierung>] 58

60 SQL*Plus Autotrace Ausführung von Befehlen aus SQL*Plus Voraussetzung: PLAN-Table muss existieren Nur möglich, wenn keine Bindevariablen verwendet werden SET SET AUTOTRACE ON; ON; SET SET AUTOTRACE TRACEONLY; Erstellung eines Ausführungsplans, ohne ein Statement tatsächlich auszuführen EXPLAIN PLAN PLAN [ SET SET STATEMENT_ID = 'name' ] [ INTO INTO <MYPLANTABLE> ] FOR FOR <statement>; 59

61 SQL-Tuning - V$SQL_PLAN Enthält für noch im Cache befindliche Cursor den Ausführungsplan Spart EXPLAIN PLAN Kommando bzw. entsprechendes Werkzeug Größere Sicherheit für den richtigen Plan 60

62 SQL-Tuning - V$SQL_PLAN_STATISTICS Enthält für jedes Element des Ausführungsplans (V$SQL_PLAN) zugehörige Statistiken (DISK_READS, BUFFER_GETS, EXECUTIONS) Erstmals Kosten für Teilpläne! STATISTICS_LEVEL = ALL SELECT a.*, b.* b.* FROM v$sql_plan a, a, v$sql_plan_statistics b WHERE a.id = b.operation_id AND AND a.address = b.address AND AND a.address = '78425FBC' 61

63 Statspack und AWR Schema perfstat mit einem Satz von Statistik- Tabellen Fügt mit jeder Ausführung der Prozedur statspack.snap die momentanen Werte aus unterschiedlichen V$-Tabellen in die Statistiktabellen mit einer so genannten Snap-ID ein Auswertung von Zeiträumen zwischen zwei beliebigen Snap-Ids Einschränkung: Die Instanz darf zwischenzeitlich nicht neu gestartet worden sein! Schwellenwerte für Report können gesetzt werden AWR in Version 10g automatisch konfiguriert 62

64 Statspack Informationen Load Profile Ausnutzung der Instanz (Trefferraten, etc.) Wait Events SQL Instance Activity Tablespace IO File IO 63

65 AWR (Beispiel) 64

66 Parameter für f r PGA-Gr Größe e (alt) bitmap_merge_area_size = Bestimmt die Größe bei Bitmap-Merge hash_area_size = Bestimmt die Größe für Hash-Joins Default: 2 * sort_area_size sort_area_size = Bestimmt die Memory-Größe für allgemeine Sortierungen sort_area_retained_size = Memorybedarf nach einer Sortierung Default: sort_area_size Vorsicht: Jeder Prozess kann diese Ressourcen belegen! 65

67 Parameter für f r PGA-Gr Größe e (Neu) workarea_size_policy = MANUAL Bestimmt, dass ein gestimmter Workspace zur Verfügung gestellt wird Default abhängig von pga_aggreate_target, wenn dieser nicht gesetzt, dann MANUAL, sonst AUTO pga_aggregate_target = 0 Gibt die Gesamtgröße der zur Verfügung stehenden PGA an Alle Prozesse gemeinsam können diesen Speicherplatz ausnutzen Je mehr konkurrierende Prozesse, umso kleiner die PGA des Einzelnen Vorsicht: Andere PGA-Parameter haben keine Wirkung mehr! 66

68 Parameter für f r Optimizer optimizer_mode = CHOOSE Legt den Standardoptimizer für die Datenbank fest optimizer_features_enable = Gibt an, welche Optimizerspezifischen Funktionen genutzt werden können optimizer_index_cost_adj = 100 Legt die prozentualen Kosten für einen Indexzugriff fest. Ein Wert von 50 gibt an, dass ein Indexzugriff nur halb so teuer wie normalerweise ist. optimizer_max_permutations = 2000 Maximale Anzahl Permutationen, die für einen Join in Betracht gezogen werden Wenn optimizer_features_enabled < 9.0 =>

69 Sonstige Parameter query_rewrite_enabled = FALSE Grundvoraussetzung für neue Funktionalitäten wie z.b. Query Rewrite aber auch die Verwendung von Function-Based Indizes statistics_level = TYPICAL Gibt an, welche Statistiken für die Datenbank gesammelt werden timed_statistics = TRUE Es werden Statistiken mit Zeitangaben gesammelt Default abhängig von statistics_level: TRUE, wenn statistics_level = TYPICAL oder ALL, sonst FALSE timed_os_statistics = 5 Zeitintervall in Sekunden, nach denen Betriebssystemstatistiken gesammelt werden Default abhängig von statistics_level: 5, wenn statistics_level = ALL, sonst 0 68

70 Parameter für f Cursor-Sharing CURSOR_SHARING = EXACT Nur identische Statements werden "geshared" CURSOR_SHARING = FORCE Das System wandelt Literale in Bindevariablen um Bessere Ausnutzung des Sharedpools Vorsicht: kann in Oracle8i zu falschen Ergebnissen führen! CURSOR_SHARING = SIMILAR Wie FORCE, aber nur dann, wenn kein anderer Zugriffspfad gewählt werden würde (z.b. durch Histogramme) 69

71 Dynamischer Shared und Large Pool Shared und Large Pools können dynamisch vergrößert und verkleinert werden: ALTER SYSTEM SET SET SHARED_POOL_SIZE = 64M; ALTER SYSTEM SET SET LARGE_POOL_SIZE = 64M; Limitierungen: Die Größe ist ein Vielfaches der Granularität der Objekte Die gesamte SGA kann nicht größer werder als SGA_MAX_SIZE 70

72 Dynamischer Buffer Cache Der Buffer Cache kann dynamisch vergrößert oder verkleinert werden ALTER SYSTEM SET SET DB_CACHE_SIZE = 96M; Limitierungen: Vielfaches der entsprechenden db_block_size Die gesamte SGA kann nicht größer werder als SGA_MAX_SIZE DB_CACHE_SIZE kann nicht auf 0 gesetzt werden 71

73 Dynamische SGA Beispiel Initialisierungsparameter (init.ora): SGA_MAX_SIZE = 128M 128M DB_CACHE_SIZE = 96M 96M SHARED_POOL_SIZE = 32M 32M SQL> SQL> ALTER ALTER SYSTEM SET SET SHARED_POOL_SIZE = 64M; 64M; => => insufficient memory SQL> SQL> ALTER ALTER SYSTEM SET SET DB_CACHE_SIZE = 64M; 64M; SQL> SQL> ALTER ALTER SYSTEM SET SET SHARED_POOL_SIZE = 64M; 64M; => => insufficient memory error errormessage => => check check V$BUFFER_POOL, shrink shrinkmuss durchgeführt werden SQL> SQL> ALTER ALTER SYSTEM SET SET SHARED_POOL_SIZE = 64M; 64M; => => Statement processed. 72

74 Empfehlungen für f r Caches V$DB_CACHE_ADVICE V$SHARED_POOL_ADVICE V$PGA_TARGET_ADVICE V$MTTR_TARGET_ADVICE Beschreibung und Status in V$STATISTICS_LEVEL 73

75 Beispiel init.ora (1) db_name = JA102 JA102 service_names = JA102 JA102 db_block_size = control_files = ("/oradata1/ja102/control01.ctl", "/oradata2/ja102/control02.ctl", "/oradata1/ja102/control03.ctl") background_dump_dest = /app/oracle/admin/ja102/bdump user_dump_dest = /app/oracle/admin/ja102/udump core_dump_dest = /app/oracle/admin/ja102/cdump log_archive_start = true true log_archive_dest = /oradata3/ja102/archive/ log_archive_format = arch_%s.arc remote_login_passwordfile = EXCLUSIVE compatible = undo_management = AUTO AUTO undo_retention = undo_tablespace = UNDOTBS1 74

76 Beispiel init.ora (2) db_cache_size = db_file_multiblock_read_count = 8 java_pool_size = 0 large_pool_size = shared_pool_size = open_cursors = timed_statistics = true true job_queue_processes = 2 query_rewrite_enabled = true true processes = fast_start_mttr_target = log_buffer = log_checkpoint_timeout = 0 pga_aggregate_target = aq_tm_processes = 1 75

77 Vorausschauende Programmierung Markieren von Anwendungsteilen mit dbms_application_info 76

78 Anwendungstracing In der Anwendung: dbms_application_info.set_module( module_name => 'Verkaufsbericht (heute)' action_name => 'Initialisierung') Für einen speziellen Client: dbms_session.set_identifier (client_id => 'Lenz') Tracing aktivieren: dbms_monitor.serv_mod_act_trace_enable( service_name => 'SUN10G' module_name => 'Verkaufsbericht (heute)' action_name => 'Initialisierung') dbms_monitor.client_id_trace_enable('lenz'); 77