Oracle 12c - Das umfassende Handbuch

523

Kapitel 21

Real Application Testing

Real Application Testing wurde in Oracle 11g eingeführt. Es besteht aus den Kompo-

nenten »Database Replay« und »SQL Performance Analyzer« (SPA). Mit der ständig

wachsenden Funktionalität und der damit verbundenen Komplexität steigen eben-

falls die mit dem Change Management verbundenen Probleme. Für komplexe und

große Datenbanken sind die Auswirkungen, die durch Upgrades, Patches oder

Änderungen in der Applikation entstehen, immer schwerer vorhersehbar. Mit Real

Application Testing liefert Oracle ein Produkt, mit dem solche Probleme reduziert

und gleichzeitig die Kosten im Testumfeld gesenkt werden können.

Mit Database Replay kann der Administrator einen realen Workload auf einem

Produktionssystem aufzeichnen und realistisch auf einem Testsystem abspielen.

Dabei spielt es keine Rolle, durch welche Clients der Workload erzeugt wird. Die

Erfassung erfolgt an zentraler Stelle in der Datenbank, sodass keine Aktivität am

Capture-Prozess vorbeigeht. Mit Database Replay können die Auswirkungen von

folgenden Änderungen getestet werden:

쐽 Upgrades, Patches und Parameteränderungen der Datenbank.

쐽 Änderung der Datenbankarchitektur wie Konvertierung auf Real Application

Clusters oder Einsatz von Automatic Storage Management.

쐽 Upgrades, Patches und Migrationen auf Hardware- oder Betriebssystemebene.

쐽 Änderungen der Infrastruktur in den Bereichen Storage und Netzwerk.

쐽 Upgrades und Änderungen seitens der Applikation.

Zusätzlich können mit dem Einsatz von Database Replay die Kosten für die Test-

infrastruktur gesenkt werden. Der Aufwand für das Duplizieren und die Wartung

der Applikationsinfrastruktur entfällt. Für Middleware-Komponenten wie Applica-

tion und Webserver muss keine Hardware vorgehalten werden. Auch die Zeiten

für die Systemeinführung können mit dem neuen Feature verkürzt werden.

Systemanpassungen, die eine Veränderung von SQL-Ausführungsplänen zur

Folge haben, können einen signifikanten Einfluss auf Performance und Verfüg-

barkeit der Datenbank haben. Datenbankadministratoren opfern viel Zeit, um

ineffiziente SQL-Anweisungen herauszufiltern und zu optimieren. Mit jedem

Change Request besteht die Gefahr, dass neue Problemfälle hinzukommen. Der

SQL Performance Analyzer kann Performance-Probleme lokalisieren, die durch

Veränderungen in der Datenbank und deren Umgebung entstehen. Er liefert

Kapitel 21

Real Application Testing

524

detaillierte Auskünfte über die Einflüsse von Änderungen auf den Ausführungs-

plan und die Optimizer-Statistik, indem er die SQL-Anweisung vor und nach der

Änderung vergleicht.

Der SPA ist in ein Framework, bestehend aus SQL Tuning Set (STS), SQL Tuning

Advisor und SQL Plan Management. Er automatisiert und vereinfacht den auf-

wendigen manuellen Prozess der Analyse des Einflusses von Änderungen in

komplexen Workloads. Mit seiner Hilfe können Ausführungspläne in einer Test-

umgebung ausgewertet und optimiert werden.

Mithilfe des SQL Performance Analyzers kann ein Vergleichsbericht erstellt wer-

den, der den Gesamt-Workload vor und nach den Änderungen gegenüberstellt.

Dabei berücksichtigt der SPA die Anzahl der Ausführungen einer SQL-Anwei-

sung. So kann ein Statement, das eine kurze Laufzeit hat, aber sehr häufig ausge-

führt wird, einen größeren Einfluss auf die Performance des Systems haben, als

eine lang laufende SQL-Anweisung, die nur einmal ausgeführt wird. Durch diese

Vorgehensweise werden SQL-Anweisungen erkannt, die einen negativen Einfluss

auf die Performance nach den Änderungen ausüben würden. Für die Optimie-

rung der Ausführungspläne stehen der SQL Tuning Advisor und das neue Feature

SQL Plan Baselines zur Verfügung.

Database Replay besteht aus den folgenden Komponenten:

쐽 Workload Capture

쐽 Workload Preprocessing

쐽 Workload Replay

쐽 Analyse und Berichte

Die Komponenten entsprechen der Vorgehensweise des Prozesses. Im ersten

Schritt werden die Workload-Daten auf dem Produktionssystem gesammelt. Der

»Workload Capture-Prozess« ist in der Lage, alle an die Datenbank gestellten Anfra-

gen einzufangen. Dabei spielt es keine Rolle, von welchem Client oder von welchem

Rechner die Anfragen gestellt werden. Das Einsammeln der Workload-Daten an

zentraler Stelle in der Datenbank hat den Vorteil, dass selbst komplexe Architektu-

ren abgedeckt werden können, ohne dass Rücksicht auf die Vielfalt der angebunde-

nen Applikationen genommen werden muss. Hintergrundprozesse und Aktivitäten

des Database Schedulers werden beim Sammeln nicht berücksichtigt. Die gesam-

melten Workload-Daten werden auf das Testsystem übertragen.

Die gesammelten Workload-Daten müssen durch das Preprocessing laufen. Dabei

werden die Capture-Dateien in Replay-Dateien umgewandelt. Gleichzeitig werden

alle Metadaten erzeugt, die für den Replay-Prozess benötigt werden. Dies ist eine

einmalige Aktion für jeden Satz von Capture-Dateien. Da das Preprocessing zeit-

aufwendig ist und einen erhöhten Ressourcenverbrauch nach sich zieht, sollte es

auf dem Testsystem ausgeführt werden.

Kapitel 21

Real Application Testing

525

Der Workload Replay-Prozess spielt den aufgezeichneten Workload auf der Test-

datenbank ab. Dabei werden alle Anforderungen der Clients in identischen

zeitlichen Abständen, mit demselben Locking-Verhalten sowie identischen Abhän-

gigkeiten der Transaktionen wiedergegeben. Der Replay-Prozess verwendet soge-

nannte Replay Clients, um den Workload identisch wiederzugeben. Mithilfe eines

Calibration Tools kann die notwendige Anzahl von Replay Clients vor dem Abspie-

len des Workloads bestimmt werden. Um alle Anforderungen des Replay-Prozes-

ses erfüllen zu können, muss die Testdatenbank in ihrer logischen Struktur im

vom Workload betroffenen Umfeld identisch zur Produktionsdatenbank sein.

Nach Abschluss des Replay-Prozesses stellt Oracle eine ausführliche Analyse- und

Berichtsfunktionalität für die Capture- und die Replay-Phase zur Verfügung. In

einer Zusammenfassung werden die wichtigsten Informationen wie aufgetretene

Fehler oder unterschiedliche Ergebnisse aus der SQL-Anweisungen zusammen-

geführt. Weiterhin werden Vergleichsstatistiken zum Beispiel über verbrauchte

Servicezeit, aktive Sessions und User Calls zur Verfügung gestellt. Für eine weiter-

führende Analyse können AWR-Statistiken herangezogen werden.

Abb. 21.1: Die Database Replay-Architektur