Oracle 12c - Das umfassende Handbuch

21.4

SQL Performance Analyzer

533

Im vorliegenden Beispiel wurde der Replay nach circa 45 Minuten über den Enter-

prise Manager abgebrochen. Obwohl der Workload Client das Signal empfangen

hat, wurden die Threads nicht beendet, die Sessions liefen in der Datenbank wei-

ter. Ein erneuter Versuch scheiterte mit der Fehlermeldung, dass aktuell kein

Workload Replay-Prozess läuft. Die Replay Sessions wurden manuell gekillt.

Nach Abschluss des Replay-Prozesses kann ein Vergleichsbericht erstellt werden.

Der Bericht liefert einige grundlegende Statistiken und vergleicht Ergebnisse zwi-

schen Capture und Replay. Zusätzlich können Sie die AWR-Statistiken für das

Replay exportieren. Klicken Sie dazu auf den Button im Enterprise Manager. Alter-

nativ können Sie in SQL*Plus die folgende Prozedur ausführen:

Bei einem Vergleich des Replay-Prozesses mit echten Clients konnte festgestellt

werden, dass das Verhalten sowie die Performance-Werte der Datenbank sehr ähn-

lich waren. Die Wiedergabe des Workloads war in diesem Fall sehr originalgetreu.

Database Replay ist ein sehr nützliches Feature, und es ist erfreulich, dass Oracle

diesen pragmatischen Weg beschreitet, um die Auswirkungen von Veränderungen

in einer komplexen Umgebung zu testen. Im vorliegenden Fall waren sowohl das

Zeitverhalten als auch die Abstimmung der Transaktionen sehr realistisch, vergli-

chen mit tatsächlichen Clients. Es wäre wünschenswert, die Filtermöglichkeit für

den Capture-Prozess zu erweitern und weitere Replay-Optionen zur Verfügung zu

haben. Ein Abbruch des Replay-Prozesses sollte besser funktionieren und die Ses-

sions der Threads der Replay Clients beenden.

21.4 SQL Performance Analyzer

Während mit Database Replay das Verhalten kompletter Workloads unter verän-

derten Bedingungen getestet werden kann, stellt der SQL Performance Analyzer

eine Funktionalität zur Verfügung, mit deren Hilfe das unterschiedliche Verhalten

von SQL-Anweisungen herausgefiltert werden kann. Ein Bericht stellt den Ein-

fluss auf die Performance nach den Änderungen dar. Gleichzeitig stellt der SPA

für die betroffenen Statements

sowie Empfehlungen zur Optimierung zur Verfügung. Es können Maßnahmen

getroffen werden, um die negativen Auswirkungen auf die Performance durch die

geplanten Änderungen abzuwenden.

SQL> BEGIN

2 DBMS_WORKLOAD_REPLAY.EXPORT_AWR(31);

3 END;

4 /

PL/SQL procedure successfully completed.

Kapitel 21

Real Application Testing

534

Abb. 21.5: Der Ablauf des Performance Analyzers

Egal, ob Sie das Real Application Testing für ein Datenbank-Upgrade, Änderungen

in Betriebssystem und Infrastruktur oder für Änderungen seitens der Applikation

einsetzen, die Vorgehensweise ist immer dieselbe:

1. Benutzen Sie den Capture-Prozess von Database Replay zum Sammeln des

aktuellen Workloads in einem SQL Tuning Set (STS) auf dem Produktions-

system.

2. Im nächsten Schritt werden die SQL-Anweisungen des STS auf einem System,

das sich im Zustand vor der geplanten Änderung befindet, ausgeführt und die

Ergebnisse wie Ausführungsplan oder Laufzeit gespeichert. Die Ausführung

erfolgt im Gegensatz zu Database Replay sequentiell, d.h. sie repräsentiert kei-

nen realen Workload mit Überlagerungen und Abhängigkeiten. Sie können das

STS wahlweise auf dem Produktionssystem oder dem Testsystem durchführen.

Wenn ein Testsystem mit dem Zustand vor den geplanten Änderungen zur Ver-

fügung steht, sollte der Schritt dort erfolgen, um die Zusatzbelastung der Pro-

duktion zu vermeiden.

3. Implementieren Sie anschließend auf dem Testsystem die Änderungen.

21.4

SQL Performance Analyzer

535

4. Messen Sie die Performance des SQL Tuning Sets auf dem geänderten System.

Der SPA führt alle Anweisungen sequentiell aus und analysiert die Auswirkun-

gen, die durch die Änderungen entstanden sind.

5. Der SPA erstellt einen Bericht mit den identifizierten Auswirkungen und stellt

die Ausführungspläne und die Performance in einem Vorher/Nachher-Ver-

gleich gegenüber.

6. Optimieren Sie SQL-Anweisungen, die infolge der Änderungen Performance-

Probleme verursachen. Hierfür stehen Ihnen Features wie der SQL Tuning Advi-

sor oder SQL Plan Baselines zur Verfügung.

21.4.1 Eine SQL-Anweisung analysieren

Wie üblich können Sie für die einzelnen Schritte alternativ SQL*Plus oder den

Oracle Enterprise Manager benutzen. Zuerst ist es notwendig, ein SQL Tuning Set

zu erstellen. Das STS kann als ein Datenbankobjekt betrachtet werden, in dem ein

oder mehrere SQL-Anweisungen zusammen mit dem Ausführungsplan, Bindeva-

riablen, der Anzahl von Ausführungen sowie weiteren Informationen erfasst wer-

den. Es enthält keinen repräsentativen Workload über einen Zeitraum, sondern

speichert sequentiell einzelne SQL-Anweisungen zusammen mit ihrem Erschei-

nungsbild im Workload. SQL-Anweisungen können aus verschiedenen Quellen

wie dem AWR, dem aktuellen SQL Cache der Datenbank oder anderen Tuning

Sets geladen werden.

Mit dem folgenden Prozeduraufruf erstellen Sie ein SQL Tuning Set:

Tipp

Während die Upgrades in früheren Versionen vielerorts noch zu unliebsamen

Überraschungen in Form von Verschlechterungen der Performance und einer

Erhöhung des Ressourcenverbrauchs geführt haben, können so gelagerte Prob-

leme bei einem Upgrade auf Oracle 12c vermieden werden. Der SPA kann SQL

Tuning Sets auf Oracle 11g erfassen und anschließen unter Oracle 12c analysie-

ren und optimieren. Damit werden die Upgrades auf die Version 12c wesentlich

störungsfreier laufen, und es wird bei vielen Betreibern und Anwendern eine

bessere Bereitschaft für den Release-Wechsel vorhanden sein.

SQL> BEGIN

2 DBMS_SQLTUNE.CREATE_SQLSET(sqlset_name => 'SPA Test MITP', description =>

'STS fuer SPA Test');

3 END;

4 /

PL/SQL-Prozedur erfolgreich abgeschlossen.

Listing 21.9: Ein SQL Tuning Set erstellen