Ganzheitliche Optimierung

Größe: px

Ab Seite anzeigen:

Download "Ganzheitliche Optimierung"

Hartmut Julius Schulze
vor 5 Jahren
Abrufe

1 Ganzheitliche Optimierung Tuning im Anwendungskontext Thomas Klughardt Senior Systems Consultant

2 Nützliche Tools und Lösungen Aber keine Plattform Lösungsbereiche DATENBANK MANAGEMENT WINDOWS SERVER MANAGEMENT PERFORMANCE MONITORING IDENTITY & ACCESS MANAGEMENT DATEN- SICHERUNG WORKSPACE MANAGEMENT PLATTFORMEN PHYSICH I VIRTUELL I CLOUD Pg. 1

3 Ganzheitliche Optimierung Agenda Warum müssen wir tunen? Wie arbeitet die Oracle Instanz? Ein paar Grundlagen Wie werden Statements ausgeführt? Schritte zur Optimierung Performance Analyse Performance Optimierung Zusammenfassung Pg. 2

4 Warum müssen wir tunen? Relationale Datenbanken skalieren nicht. CAP Theorem Oder Brewer s Theorem nach Eric Brewer DBPedias.com Pg. 3

5 Wie arbeitet die Oracle Instanz Oracle arbeitet in Blöcken Oracle arbeitet in Blöcken Daten und Indizes liegen in Blöcken IO Operationen passieren auf Blöcken Oracle Blöcke vielfache von Dateisystem Blöcken Sonst laufen IO Operationen suboptimal vs. Caching macht die Daten verfügbar Pg. 4

6 Optimierter Datenspeicher Caching ist lebenswichtig Speicher IOs sind viel schneller als Festplatten IOs Festplattenzugriff -> Millisekunden Speicherzugriff -> Nanosekunden Faktor Millionen Unterschied Beispiel: eine Sekunde reine Speicherzugriffe entsprechen einer Million Sekunden Plattenzugriffe Eine Million Sekunden = 11,5 Tage Riesenunterschied eine Sekunde oder fast zwei Wochen Pg. 5

7 Oracle Instanz Architecture Source: Oracle Database Concepts Pg. 6

8 Shared SQL Area Caching ist Wichtig Geparste Statements Caching ist auch hier wichtig Hard-Parsen ist viel Arbeit Hard-Parsen bedeutet: 1. Das Statement zu lesen, Syntax check durchführen 2. Tabellen und Spaltendefinitionen prüfen - Data Dictionary Lookups (Rekursive Statements) 3. Shared Locks erzeugen Definitionen festsetzen 4. System und Objektprivilegien prüfen 5. Ausführungsplan bauen 6. Statement in den Cache laden 7. Eventuell an andere Instanzen verteilen Pg. 7

9 Der Ausführungsplan Statistiken sind wichtig Beschreibt den tatsächlichen Datenzugriff Mehrere Alternativen werden generiert, die beste ausgeführt Basiert auf den Statistiken Default: 2000 Permutationen OPTIMIZER_MAX_PERMUTATIONS Statistiken sollten aktuell sein Schlechte Statistiken -> schlechter Ausführungsplan Statistiken sammeln ist ein Change! (Features wie Plan Stability können etwas helfen) Pg. 8

10 Hit Ratios Caching ist wichtig Buffer Cache Cache für Daten und Index Blöcke Die Hit Ration sollte so hoch wie möglich sein OLTP Systems > 95% Für OLAP Systeme meist niedriger Shared Pool Cache für geparste Statements (Cursor) Soft Parse Ratio sollte nahezu 100% betragen (für OLTP Systeme) Oder werden Literale verwendet? Bindevariablen sind besser! Pg. 9

11 Hit Ratios Statspack oder AWR Toad Statspack Browser Pg. 10

12 Vorsicht, Falle Automatisches Memory Management und Literale memory_target Eingeführt in 11g, Automatic Memory Management Gefährlich in Verbindung mit Literalen Der Shared Pool wird größer Der Buffer Cache wird kleiner Lösung: Set db_cache_size Definiert jetzt die Minimalgröße des Buffer Cache Pg. 11

13 Wie werden Statements ausgeführt? Zugriffspfade Join Algorithmen

14 Explain Plan in SQL*Plus Pg. 13

15 Explain Plan in Toad Pg. 14

16 Zugriffspfade Tabellen und Indizes Pg. 15

17 Full Table Scan Pg. 16

18 Index Unique Scan Pg. 17

19 Index Range Scan Pg. 18

20 Index Full Scan Pg. 19

21 Index Fast Full Scan Pg. 20

22 Indizes und IO Kosten Wie selektiv ist ein Index? Benötige ich auch Tabellen Blöcke? Index Range Scans und Index Full Scans kosten üblicherweise mehr IOs als Full Table Scans. Aber liefern die Ergebnisse schneller Vermeiden eventuelle Sortierungen Indizes müssen bei DMLs gepflegt werden! Das hat Auswirkungen auf andere User/Sessions. Pg. 21

23 Join Operationen Nested Loop Join Sort Merge Join Hash Join Pg. 22

24 Schritte zur Optimierung Performance Analyse Performance Optimierung

25 Performance Analyse Wait Events Korrelieren mit der Anwendungsperformance Die Anwendung ist langsam Und wir haben dominierende Wait Events Wait Event Statistiken v$ Performance Views AWR / ADDM (OEM Diagnostic Pack) Spotlight (Echtzeit) Performance Analysis (Historische Daten) Trace Files Vorsicht, Tracing beeinflusst die Performance Pg. 24

26 Performance Analyse Wait Events Pg. 25

27 Performance Analyse Parsed Statements (Shared Pool) Sortiert nach Buffer Gets Pg. 26

28 Performance Analyse Statements nach Wait Events Trace Files Pg. 27

29 Performance Analyse Die häufigsten Wait Events db_file_sequential_read Single Block Reads db_file_scattered_read Multiblock Reads Free Buffer keine freien Blöcke im Cache Buffer Busy (> 1%) Zu viele Operationen auf Block Latch Free Warten auf Latch / Semaphore Log buffer space Warten auf freien Log Buffer Log File Switch Switches zu langsam Archiving? Log file sync Warten bis Logs auf Platte sind Pg. 28

30 Performance Analyse Was haben wir getan? Ressourcenengpässe identifiziert. Global auf Datenbankebene Heruntergebrochen auf Sessions/User/Anwendungen Wir haben problematische Statements gefunden. Die die knappen Ressourcen benötigen. Jetzt können wir optimieren. Pg. 29

31 Performance Optimierung Offensichtlich problematische Statements Erster Schritt: Ausführungsplan Offensichtlich: Kartesische Produkte Schwächen im Datenmodell? Hohe Kosten? Entwickler schulen Wie wird auf Daten zugegriffen? Wie funktioniert so eine Instanz? Pg. 30

32 Performance Optimization Optimizer hints Hinweise an die Datenbank Nur ein Hinweis, nicht bindend /*+ ALL_ROWS */ /*+ FIRST_ROWS(integer) */ /*+ INDEX(table_name index_name) */ /*+ FULL(table_name) */ Funktioniert wie ein Kommentar Syntax Fehler? Hint wird ignoriert Pg. 31

33 Performance Optimization Verbessern nicht so offensichtlich problematischer Statements Versuchen das Statement anders zu schreiben Kann anderen Ausführungsplan erzeugen Versuchen Konvertierungsfunktionen zu vermeiden Die können verhindern, dass sinnvolle Indizes greifen Alternativ: Erzeugen von funktionalen Indizes SQL Optimierungstools können hier helfen Oracle Tuning Advisor (OEM Tuning Pack) Quest SQL Optimizer Pg. 32

34 Performance Optimization Nichts hilft? Bessere Hardware Viele Platten statt großer Platten Mehr Schreib/Leseköpfe => Mehr IO Durchsatz Mehr Speicher hinzufügen Größere Caches, mehr Blöcke können gecached werden Schnellere CPUs, höhere BUS Gewschwindigkeit Schnelleres Arbeiten Das ist teuer und löst nicht das eigentlich Problem Pg. 33

35 Zusammenfassung Was haben wir gesehen? Relastisch sein Datenbanken skalieren nicht unbegrenzt Das Problem muss analysiert werden. Abläufe müssen bekannt sein. Zugriffe müssen bekannt sein Analyse ist wichtig, um zielgerichtet zu optimieren. Das Thema ist sehr umfangreich Das hier war nur ein Überblick Pg. 34

36 Toad User Konferenz in München Pg. 35

37 Welche Fragen haben Sie? Pg. 36

Ähnliche Dokumente

Ich liebe es, wenn ein Plan funktioniert

Ich liebe es, wenn ein Plan funktioniert Der Ausführungsplan Thomas Klughardt Senior Presales Consultant 16.11.2011 Quest Software 60 Büros 3 HQs Nord-/ Mittel-/ Südamerika Europa Asien / Pazifik 3600+