Datenbankadministration WS 2012/13: Performance-Monitoring und -Tuning

Transkript

1 Datenbankadministration WS 2012/13: Performance-Monitoring und -Tuning Prof. Dr. K. Küspert, Dipl.-Math. K. Büchse, Dipl.-Inf. A. Göbel Friedrich-Schiller-Universität Jena 09. Januar 2013

2 Gliederung Motivation 1 Motivation 2 3 Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten 4 Lock Escalation

3 Struktur Motivation 1 Motivation 2 3 Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten 4 Lock Escalation

4 Motivation Tuning

5 Tuning von Datenbankmanagmentsystemen Wahl von Konfigurationsparametern Anlegen von Zugriffspfaden Optimierungsstufen

6 Wichtig! Motivation in unseren Aufgaben: nur einfache Szenarien Wirkungsweise von Parametern entkoppelt betrachtet in der Praxis: heterogene Anwendungen Zusammenspiel der Vielzahl von Parametern entscheidend kein Universalrezept für Performance-Tuning!

7 Performance-Beurteilung direkte Zeitmessung (db2batch) Monitoring: Beobachtung ermittelbarer Leistungsgrößen DB2: Monitor/Snapshot-Funktionalität

8 Struktur Motivation 1 Motivation 2 3 Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten 4 Lock Escalation

9 Motivation Ziele hohe Zugriffsrate auf Buffer Pool Plattenzugriffe vermeiden

10 Buffer Pool Hit Ratio (BPHR) BPHR = 1 D p+i p D l +I l Anzahl der Datenleseoperationen: D p... physisch D l... logisch Anzahl der Indexleseoperationen: I p... physisch I l... logisch

11 BPHR-Steigerung durch Größenänderung eines Bufferpools Ausgangspunkt Tabellen WORK.ORDERED und WORK.RANDOM Programm workload zur Lasterzeugung (entsprechende Dateien finden sich im Verzeichnis db2i00/src) Vorgehensweise schrittweise Buffer Pool IBMDEFAULTBP erhöhen workload auf beiden Tabellen laufen lassen snapshots machen BPHR berechnen

12 BPHR-Steigerung durch Größenänderung eines Bufferpools Ausgangspunkt Tabellen WORK.ORDERED und WORK.RANDOM Programm workload zur Lasterzeugung (entsprechende Dateien finden sich im Verzeichnis db2i00/src) Vorgehensweise schrittweise Buffer Pool IBMDEFAULTBP erhöhen workload auf beiden Tabellen laufen lassen snapshots machen BPHR berechnen

13 Ziel effizientere Verarbeitung von SQL-Anfragen Hintergrund automatische Verteilung der Daten auf mehrere physische Rechner parallele Verarbeitung möglich Nutzer kann (eingeschränkt) Datenverteilung beeinflussen Entscheidung richtet sich nach Anfragelast Eigenschaften des physischen Rechners

14 Hinweise zur Aufgabe nur ein physischer Rechner vorhanden Arbeit mit logischen Partitionen vor dem Anlegen einer neuen Partition: $ echo "iibm04 $USER"> /.rhosts Partitionen auch als nodes bezeichnet

15 Struktur Motivation Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten 1 Motivation 2 3 Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten 4 Lock Escalation

16 Tuning von Query-Ausführungsplänen Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten Hintergrund: Arbeitsweise des SQL-Optimierers Abschätzung der Ausführungszeiten verschiedener Zugriffspläne mithilfe statistischer Daten Wahl desjenigen Plans mit geringster Ausführungszeit (Schätzwert!) Statistiken entscheidend für Performance!

17 Ermittlung von Anfrageplänen Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten auf der Kommandozeile: Tool db2expln Bsp: $ db2expln -d admin -g -i -t -q "select * from work.ordered where idx > 1000"

18 Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten Schätzung und Messung von Ausführungszeiten Szenario vorgegebener Anfragemix mithilfe von Indizes kann Anfragezeit verkürzt werden hier: zwei Indizes mit jeweils max. zwei Attributen mit db2batch Ausführungszeiten ermitteln

19 Struktur Motivation Lock Escalation 1 Motivation 2 3 Tuning von Query-Ausführungsplänen Schätzung und Messung von Ausführungszeiten 4 Lock Escalation

20 Lock Escalation Motivation Lock Escalation Hintergrund: Sperren im Mehrbenutzerbetrieb zur Vermeidung von Problemen wie lost update Phantomproblem u.v.m. Problem: Sperren vs. Performance Sperreskalation Sperre wird auf gröberes Sperrgranulat ausgedehnt weniger Aufwand beim Sperren ABER: mehr Daten gesperrt

21 Lock Escalation Motivation Lock Escalation Hintergrund: Sperren im Mehrbenutzerbetrieb zur Vermeidung von Problemen wie lost update Phantomproblem u.v.m. Problem: Sperren vs. Performance Sperreskalation Sperre wird auf gröberes Sperrgranulat ausgedehnt weniger Aufwand beim Sperren ABER: mehr Daten gesperrt

22 Sperreskalation im DB2 Lock Escalation entscheidende Parameter: LOCKLIST MAXLOCKS falls Sperreskalation erfolgt: in Datei db2diag.log Informationen darüber

23 Fragen? Motivation Lock Escalation