Performance-Stabilisierung mit Einsatz von SQL Plan Baselines

Performance-Stabilisierung mit Einsatz
von SQL Plan Baselines

Performance-Stabilisierung mit Einsatz von SQL Plan Baselines

© OPITZ CONSULTING Deutschland GmbH 2013

Seite 1

Performance-Stabilisierung
mit Einsatz von SQL Plan Baselines

Katja Werner
Senior Consultant
OPITZ CONSULTING GmbH

Nürnberg, 19.11.2013


Seite 2

Mission

Märkte

Wir entwickeln gemeinsam mit allen
Branchen Lösungen, die dazu führen, dass
sich diese Organisationen besser entwickeln
als ihr Wettbewerb.

 Branchenübergreifend
 Über 600 Kunden

Unsere Dienstleistung erfolgt
partnerschaftlich und ist auf eine langjährige
Zusammenarbeit angelegt.

29%
Handel / Logistik /
Dienstleistungen

29%
Industrie / Versorger /
Telekommunikation

42%
Öffentliche Auftraggeber / Banken und
Versicherungen / Vereine und Verbände

Leistungsangebot

Eckdaten

 Business IT Alignment
 Business Information Management
 Business Process Management
 Anwendungsentwicklung
 SOA und System-Integration
 IT-Infrastruktur-Management

 Gründung 1990
 400 Mitarbeiter
 9 Standorte

<Präsentationstitel – bitte im Folienmaster ändern>

© OPITZ CONSULTING GmbH 2012

Seite 3

Agenda
1. Der Anfang

2. Etwas Theorie
3. Der Weg zu stabiler Performance
4. SQL Plan Baselines in der Praxis
5. Und noch etwas Praxis – Testcases
6. Am Ziel



Seite 4

1

Der Anfang



Seite 5

Herausforderung

 Als Datenbankadministrator beim Kunden
 "Die Performance ist schlecht"



Seite 6

Ursachenforschung

Ist die
Performance
immer
schlecht?


Nein. Letzte
Woche war gut.
…
... Ist mal
besser. Und mal
schlechter.


Seite 7

2

Etwas Theorie



Seite 8

Wie entsteht der Explain Plan?

Query
Transformer

Estimator

Plan
Generator

Bester Explain Plan



Seite 9

Was denken Sie?
Warum sind die Explain Plans so schlecht?

A) Oracle kanns nicht besser.

B) Cost based Optimierung hat noch nie
funktioniert.
C) Richtige Antwort.



Seite 10

Warum sind die Explain Plans so „schlecht“?
C) Richtige Antwort(en):
 Bindevariablen in Verbindung mit unterschiedlich
großen Datenmengen
 Funktionen/Prozeduren im Code
 Viele Joinmöglichkeiten
 Veraltete Statistiken
 Ungünstige Einstellungen



Seite 11

Möglichkeiten zur Stabilisierung

Hint

Stored
Outline

SQL
Profile

SQL Plan
Baseline



Seite 12

3

Der Weg zu
stabiler Performance



Seite 13

Fragen

 Wieviel Statements sind betroffen?
 Was für Statements sind betroffen?
 Was will ich wie stabilisieren?



Seite 14

Der Weg zu stabiler Performance
Datensammlung (DBA_HIST_SQLSTAT)

Analyse (wechselnde Explain Plans, lang laufende
SQL-Statements/Geschäftsprozesse)

Priorisieren, Stabilisierungsmaßnahme(n) festlegen


Seite 15

Anzahl unterschiedlicher Explain Plans
Für alle Statements
auf der DB

40 15

1
2
>2
700



Seite 16

Klassifizierung von SQL Statements
 „Normales“ Statement:
select * from employee where id=99;
 Literalstatements:
select * from employee where name=‘SCOTT‘;
select * from employee where name=‘MUELLER‘;
select * from employee where name=‘HUGO‘;
 Statements mit Bindevariablen:
select * from employee where name=:var1;


Seite 17

Unterschiedliche Explain Plans pro
Statement“art“
Literalstatements
(ca. 100)

Einfache
Statements
(ca. 100)

1
2
>2

BindevariablenStatements (ca. 550)


Seite 18

Fazit für vorliegende Datenbank
 Kaum Statements mit Literalen
 Viele Statements mit Bindevariablen
 Insgesamt ca. 50 Statements, die stabilisiert werden
könnten

 SQL Plan Baselines sollen eingesetzt werden
 Große und kleine Datenmengen testen



Seite 19

4

SQL Plan Baselines
in der Praxis



Seite 20

Das ist eine SQL Plan Baseline
ALL_ROWS
DB_VERSION('11.2.0.3')
OPTIMIZER_FEATURES_ENABLE('11.2.0.3')
USE_NL(@"SEL$F5BB74E1" "C"@"SEL$2")
USE_NL(@"SEL$F5BB74E1" "A"@"SEL$2")
LEADING(@"SEL$F5BB74E1" "B"@"SEL$2"
"A"@"SEL$2" "C"@"SEL$2")
INDEX(@"SEL$F5BB74E1" "C"@"SEL$2"
("PROMOTIONS"."PROMO_ID"))
INDEX(@"SEL$F5BB74E1" "A"@"SEL$2"
("PRODUCTS"."PROD_ID"))
……


Seite 21

Voraussetzungen
 Enterprise Edition
 Bei Nutzung von SQL Tuning Sets: Tuning + Diagnostic
Pack
 OPTIMIZER_USE_SQL_PLAN_BASELINES=TRUE
 Ab Oracle 11g



Seite 23

Rechte für Baselines
 ADMINISTER SQL MANAGEMENT OBJECT
Zum vernünftig arbeiten können:

 SELECT ANY DICTIONARY
 CREATE TABLE + Quota
 CREATE, ALTER SESSION

 Evtl. Rechte auf Applikationsschemata
 Evtl. ADVISOR


Seite 24

Wo bekomme ich SQL Plan Baselines her?
Automatisches Laden, wenn:
 OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE

Manuelles Laden aus:
 SQL Tuning Set
 Cursor Cache
 Stored Outline
 Import aus anderen Datenbanken
 AWR (nur über SQL Tuning Set)


Seite 25

Export und Import von Baselines
 Erstellen einer Stagingtabelle:
DBMS_SPM.CREATE_STGTAB_BASELINE
 Befüllen der Stagingtabelle:
DBMS_SPM.PACK_STGTAB_BASELINE
 Export/Import und dann wieder entpacken:
DBMS_SPM.UNPACK_STGTAB_BASELINE



Seite 26

Wie entsteht der Explain Plan mit Baselines?

Query
Transformer

Estimator

SQL Plan
Baseline

Plan
Generator

Bester Explain
Plan

SQL Plan History


Seite 27

Wie entsteht der Explain Plan mit Baselines?
 Vorhandene SQL Plan Baseline:

 Vorhandene SQL Plan Baseline und vom Optimizer
entwickelter Alternativplan:



Seite 28

Wird meine Baseline genutzt?

 V$SQL.SQL_PLAN_BASELINE für aktuell laufende
Statements
 DBA_SQL_PLAN_BASELINES.LAST_EXECUTED (nicht
immer zuverlässig)



Seite 29

Lessons Learned
 Baseline wirkt für gesamte Datenbank
 dbms_xplan.display_sql_plan_baseline
 Laden per Tracefile – SQL Tuning Set nicht möglich

 Für Join von Tabelle mit Collection CAST-Operator
nutzen
 Retentiontime
 Automatisch gesammelte Baselines erst beim 2.
Ausführen
 DBA_SQL_PLAN_BASELINES.LAST_EXECUTED


Seite 30

5

Und noch etwas
Praxis - Testcases



Seite 31

Ursachenforschung

Ist die Wo sind die
Wurde Testergebnisse?
der
Performance
Prozess
immer
Konkrete
getestet?
schlecht?
Daten, Laufzei
ten, Explain
Plans,
…?


Nein. Letzte
Woche war gut.
Häh?
…
Ja. Performance
war wunderbar.
... Ist mal
Ne. Das haben wir
besser. Und mal
nicht mehr.
schlechter.


Seite 32

Ziel von Testcases

 Nachvollziehbarkeit: Was wurde getestet und wie
waren die Ergebnisse?
-> Vergleich zwischen Gestern und Heute
 Wiederholbarkeit: Wie sind die Ergebnisse, wenn ich
den Test erneut durchführe?



Seite 33

Was gehört zu einem Testcase?

Dokumentation:
 Welcher konkrete Geschäftsprozess?
(Beispiel: Rechnungserstellung für Telefonnummer
0172-2048790 für die Monate 01-03/2013)

 Start- und Endezeitpunkt des Prozesses
 SQL Tuning Set für alle SQLs
 AWR-Report für genau diesen Zeitraum
Skripts


Seite 34

Umsetzung der Testcases
 Erstellung zusammen mit Fachbereich für konkret (!!!)
definierte Geschäftsprozesse
 Immer dieselben Datenmengen pro Testcase
 Für viel und wenig Daten
 Messung gesamter Prozesse, nicht einzelner SQL
Statements


Seite 35

Best Practice
 Modulnamen verwenden
 Shared Pool und Buffer Cache leeren
 SQL Tuning Sets
 AWR-Snapshots vor und nach Testlauf
 Große sowie kleine Datenmengen
 Testdatenmenge möglichst langlebig wählen
 Tuningmaßnahmen im Releaseplan einplanen



Seite 36

Woran festmachen, ob die Performance besser
ist?
Testumgebung:
 Testcases ablaufen lassen
 Laufzeiten messen
 Vergleichen und evtl. Unschärfen auswerten
Produktion
 Vergleiche der Prozesslaufzeiten mit Testcases



Seite 37

Unschärfen
 Ressourcen, die nicht nur von Testdatenbank allein
genutzt werden (Storage, Netzwerk, CPU)
Bei Vergleich zwischen Test und Produktion:
 Prozesse laufen in Produktion nicht isoliert
 Unterschiedliche abgefragte Datenmengen
 Unterschiedliche Hardware
AWR-Reports, SQL Tuning Sets und Laufzeiten helfen bei
der Beurteilung


Seite 38

6

Am Ziel



Seite 39

Die Kür – SQL Plan Baselines + Testcases
Produktion

Test/Entwicklung

1. Statementauswahl

2. Testcase

4. Kontrolle

Abnahme


3. Baseline/
Tunen


Seite 40

Erkenntnisse fürs weitere DBA-Leben

1. Tune nicht nur. Stabilisiere!
2. Klassifiziere deine Statements nach Art und Anzahl
und du kennst die Datenbank!
3. Priorisiere!
4. Nutze Testcases für Vergleiche und Wiederholbarkeit!



Seite 41

Am Ziel!

Ist die
Performance
immer noch
schlecht?

Nein. Ist super.
Immer! Stabil!
Testcases
haben wir auch
…
… zum Vergleich bei:
- Problemen
- Upgrades
- Codeänderungen



Seite 42

Fragen und Antworten



Seite 43

Kontakt
Katja Werner
Senior Consultant

OPITZ CONSULTING Deutschland GmbH
Standort München
Weltenburger Straße 4 | 81677 München
Tel. +49 (89) 68 00 98-1466
katja.werner@opitz-consulting.com

youtube.com/opitzconsulting
@OC_WIRE
slideshare.net/opitzconsulting
xing.com/net/opitzconsulting



Seite 44

Performance-Stabilisierung mit Einsatz von SQL Plan Baselines

Recommended

Recommended

More Related Content

More from OPITZ CONSULTING Deutschland

More from OPITZ CONSULTING Deutschland (20)

Performance-Stabilisierung mit Einsatz von SQL Plan Baselines