Logo Oracle Deutschland   DBA Community  -   (zuletzt ergänzt August 2012)
Real Application Testing Teil 1: Database Replay
von Ulrike Schwinn, Oracle Deutschland B.V. & Co. KG

Real Applicaton Testing steht seit Oracle Datenbank Version 11g als neue Option der Datenbank zur Verfügung. Es handelt sich dabei um ein Werkzeug für die Datenbank, das einen Workload aufzeichnen und in einer Testumgebung wieder abspielen kann. Der Ausdruck Werkzeug ist dabei etwas irre führend, da keine zusätzliche Installation einer separaten Werkzeug-Software für Real Application Testing notwendig ist. Die Nutzung erfolgt wie üblich über die Standardwerkzeuge Enterprise Manager oder PL/SQL bzw. SQL Aufrufe.

Welche Idee steckt dahinter? Ohne zusätzlichen Aufwand – wie Einsatz von speziellen Script Sprachen usw.- ist es möglich, eine Last bzw. einen SQL Workload aufzuzeichnen und in einer existierenden Testumgebung abzuspielen. Somit bietet sich Real Application Testing besonders an bei Datenbank Upgrades, Patch Anwendungen, Konfigurationsänderungen wie zum Beispiel der Umstieg auf RAC oder ASM, Änderungen an Datenbank Sizing Parameter, Änderungen an der Hardware Plattform, am Betriebssystem oder an der Storage, um nur einige Beispiele zu nennen. Folgende Fragestellungen sind dabei typisch: Funktioniert meine Applikation weiterhin wie gewohnt nach dem Upgrade auf ein neues Datenbank Release, nach dem Wechsel auf eine neuen Hardware oder nach Einspielung von Patches? Bleibt die SQL Statement Performance erhalten? Wie wirkt sich die Last gemäss I/O, CPU, Memory Metrik auf das neue System insgesamt oder gar pro Statement aus?

Um diese Fragen zu beantworten, will ich im Folgenden einen Überblick über die Technologien geben, über Voraussetzungen aufklären, die Ergebnisse einordnen und für die praktische Nutzung Skripte zum Download zur Verfügung stellen. Real Application Testing beinhaltet zwei unabhängige sich ergänzende Lösungen, die je nach Charakteristik der Applikation bzw. Art der Analyse zum Einsatz kommen können. Es handelt sich dabei um Database Replay und um den SQL Performance Analyzer. Auch hier wie bei vielen Produkten oder Features ist der Name bezeichnend für den Charakter und die Eigenschaften der beiden verschiedenen Funktionalitäten.

Um einen besseren Überblick zu gewährleisten, gliedert sich der Artikel in folgende Abschnitte:

Real Application Testing: 2 Komponenten in Kürze

Database Replay (kurz DB Replay) zeichnet den gesamten Workload unter Berücksichtigung aller konkurrierenden Zugriffe auf und führt eine Analyse bezogen auf die Gesamtlast der Datenbank durch. Das bedeutet, dass alle Datenbank Calls (Ausnahmen im Application Testing Handbuch) somit auch PL/SQL Calls usw. im Workload enthalten sind. Der Ablauf sieht drei Verarbeitungsschritte vor: das Aufzeichnen auf dem Produktionssystem, eine spezielle Verarbeitung auf dem Testsystem und das eigentliche Abspielen auf dem Testsystem. Dabei gibt es allerdings folgende Einschränkungen zu beachten: Das Aufzeichnen (auch Capture) kann auf 9i, 10g und 11g Datenbanken, das Abspielen (auch Replay) hingegen nur auf 11g Datenbanken stattfinden. Des weiteren ist es notwendig ein passendes Datenbank Testsystem - am besten SCN genau - zur Verfügung zu stellen, damit der Replay nicht allzu viele Divergenzen produziert. Zudem sollte ein Mechanismus wie Flashback mit entsprechenden Restore Points implementiert werden, um mehrere Tests auf dem System durchzuführen.

Der folgende Screenshot zeigt einen Auszug aus einem Replay Report.


Für eine größere Ansicht auf das Bild klicken.

Der Fokus von SQL Performance Analyzer (kurz SPA) liegt auf einer detaillierten Statement Analyse eines definierten SQL Workloads. Ein Workload besteht dabei aus SELECT Statements bzw. auch aus DML Statements (im Moment nur über den Package Aufruf), die über ein SQL Tuning Set (kurz STS) zur Verfügung gestellt werden. Der SQL Workload wird dabei zweimal abgespielt - vor der Veränderung und nach einer Veränderung - und dabei werden einige wichtige Statistiken gesammelt. Das Ergebnis ist ein detaillierter Analyse Vergleich (vor und nach der Veränderung) der einzelnen Statements gemessen an verschiedenen Metriken beispielsweise Elapsed Time (der Default), Buffer Gets, CPU Zeit, I/O Zeit, Optimzer Costs etc. Berechnet werden alle Metriken bei der Ausführung, angezeigt wird der Report in der Hauptsache bzgl. einer Metrik zum Beispiel Elapsed Time. Möchte man hingegen eine andere Metrik zum Vergleich heranziehen, muss nur noch ein Report generiert werden. Zusätzlich geben die Analyse Berichte natürlich auch an, welche Statements wichtig (relevant) für den Workload sind (siehe NET Impact on Workload), wie die alle Metriken pro Statement (in der Übersicht) ausfallen, ob Ausführungspläne „gekippt“ sind und wie die Ausführungspläne im Detail aussehen. Möchte man nun ein Tuning anschliessen, ist dies einfach möglich durch die Integration des SQL Tuning Advisors oder der SQL Plan Baselines. Vorteil dieser Methode ist die einfache Handhabung und die Verfügbarkeit. Da keine DML-Statements die Testumgebung verändern - DML Statements werden automatisch zurück gerollt - ist kein Zurücksetzen nach dem Test erforderlich. Zudem kann die Analyse auch schon für 9i Datenbanken erfolgen.

Der folgende Screenshot zeigt ein Beispiel eines SPA-Reports.


Für eine größere Ansicht auf das Bild klicken.

Soweit die Einordnung der beiden Produkte! Da die beiden Produkte unabhängig voneinander verwendet werden können und um den Umfang dieses Artikels nicht zu sprengen, wird der Artikel in zwei Teilen aufgeteilt. Wir starten in diesem Teil mit Database Replay, das zudem eine gute Integration in den SQL Performance Analyzer besitzt. Informieren Sie sich über die Lizenzierung des Produkts. Real Application Testing ist eine zusätzliche Option der Datenbank. Möchte man das vollständige Report bzw. Tuning Framework nutzen,ist zusätzlich die Lizenzierung von Diagnostics und Tuning Pack notwendig. Mehr dazu finden Sie auch im Licensing Guide.

DB Replay im Überblick

Wie funktioniert nun DB Replay? Dazu ist folgendes Drei-Schritt-Verfahren nötig:
  1. Das Capture stellt die Aufzeichnung auf dem Produktionssystem dar.
  2. Das sogenannte Workload Processing ist die einmalige Aufbereitung der Dateien, um das nachfolgende Replay vorzubereiten.
  3. Das Replay ist dann das Abspielen auf dem Testsystem.
Auf dem Produktionssystem wird das sogenannte Capture in ein leeres logisches Verzeichnis (Directory) der Datenbank durchgeführt. Nutzt man das Capture in Version 10g, muß vorab der dynamische Parameter PRE_11g_ENABLE_CAPTURE eingeschaltet werden. Das Capture ist ein sehr einfach zu initiierender Prozeß, der nur wenig Overhead auf dem Produktionssystem erzeugt. Starten sollte man mit einem kurzen Workload von ca. 1 Stunde, um mehrere Tests durchführen zu können oder um Probleme beim Abspielen besser bewerten zu können. Das soll nicht heißen, daß nicht auch Workloads von mehreren Stunden oder über die Dauer eines Tages machbar sind.

Hier schließt sich direkt die Frage nach dem Umfang der Capture Dateien an. Eine eindeutige Antwort darauf gibt es nicht, das hängt von der Anzahl der Datenbank Connections, der unterschiedlichen Statements, der Parallelisierung usw. ab. Am Besten führt man ein kurzes 10 minütiges Testcapture zu Peakzeiten durch und rechnet das Ergebnis hoch. Weniger Capture Dateien kann man durch das Filtern - zum Beispiel nach User, Instance Id oder Services - beim Capture Lauf erhalten. Dabei kann man einschließende oder ausschließende Filterkriterien definieren. So kann man sich beispielsweise über den Einsatz von Services nur auf einige wenige Applikationsserver konzentrieren oder aber bestimmte DB User wie SYS oder SYSMAN ausschließen. Die Capture Dateien sind dabei binär und Betriebssystem unabhängig, so daß der Test auf unterschiedlichen Plattformen möglich ist. Abgeschlossen wird dieser Vorgang durch einen AWR Export, um nach dem Replay einen AWR Difference Report produzieren zu können. Aufgezeichnet werden übrigens auch Fehler, die sich während des Captures ereignen. Diese sind in der Regel vernachlässigbar.

Das anschließende Processing muß nur einmal durchgeführt werden. Dabei werden die Capture Dateien analysiert und auf das Abspielen vorbereitet. Wenn graphisch gearbeitet wird, sollte man unbedingt parallel dazu den Workload Analyzer anstoßen. Er gibt darüber Auskunft, welche Auffälligkeiten und Charakteristiken der Capture Load aufweist. Die Linemode Variante wird in den Skripten (siehe unten) zur Verfügung gestellt und sollte nach dem Processing manuell gestartet werden.

Der folgende Screenshot zeigt einen Ausschnitt aus einem Workload Analyzer Report.


Für eine größere Ansicht auf das Bild klicken.

Das Replay hingegen besteht aus mehreren Schritten. Zuerst werden ein Name und das logische Directory, in dem sich die Dateien befinden, bekannt gegeben. Dann wird ein Prepare durchgeführt, das über die Abspielart entscheidet. Abgespielt wird der Workload mit speziellen Clients - den sogenannten Workload Replay Clients (wrc). Die Anzahl der zu startenden Clients wird vorab über eine Kalibrierung festgelegt. Der Default ist ein COMMIT synchrones Abspielen und eine 1 zu 1 Abbildung der Think und Connection Time. Da die Abspiel-Logik einer eigenen Orchestrierung (auch Regelwerk) folgt, kann in Abhängigkeit von der Workload-Characteristik und des Test-Ziels von diesem Default abgewichen werden. So kann zum Beispiel Transaktions-asynchron abgespielt werden und die Think bzw. die Connection Time variiert werden. Um eine einfache Integration in den SPA zu gewährleisten, ist es übrigens möglich, ein STS während des Replays oder gar während des Captures anzustoßen.

Die drei Schritte sind einfach in der graphischen Oberfläche zu nutzen. Intuitiv wird man zu den entsprechenden Schritten geführt.

Häufig stellt sich die Frage, ob der Anwender DBA Privilegien zur Nutzung von DB Replay benötigt. Dies ist nicht erforderlich. Folgende Privilegien reichen zur Nutzung aus:
  • EXECUTE für die Packages DBMS_WORKLOAD_CAPTURE und DBMS_WORKLOAD_REPLAY
  • CREATE ANY DIRECTORY
  • CREATE SESSION
  • SELECT_CATALOG_ROLE
  • BECOME USER
  • ADMINISTER SQL TUNING SET
Folgender Screenshot zeigt die Implementierung in Enterprise Manager Cloud Control.


Für eine größere Ansicht auf das Bild klicken.

In Testumgebungen steht allerdings seltener eine graphische Oberfläche zur Verfügung. Daher wird im nächsten Schritt die Linemode Variante vorgeführt.

DB Replay im Linemode

Um den Rahmen des Tipps nicht zu sprengen, haben wir die DB Replay Skripte für Capture, Processing und Replay-Nutzung mit den entsprechenden zusätzlichen Optionen für Sie zusammengestellt und hier zum Download zur Verfügung gestellt. Ein Readme, das schrittweise abgearbeitet werden kann, führt Sie durch die Anwendung der einzelnen Skripte. So läßt sich beispielsweise das Capture in der einfachsten Variante mit einem einzigen Kommando durchführen. Hier ein kleiner Auszug aus dem Readme:
Real Application Testing Skripte Stand August 2012
Autorin: Ulrike Schwinn

I) Voraussetzung

1) RAT Option überprüfen: OPTION.sql
2) Falls nicht gelinkt, dann 
$ chopt enable rat

3) Backup durchführen

II) Rechner 1: Durchlauf auf der CAPTURE Seite

-1) (falls 10g) PRE_11g_ENABLE_CAPTURE=TRUE Parameter setzen
0) (Optional) Directory leeren
1) Directory überprüfen             - Skript: DIR.sql
2) (Optional) Filter setzen         - Skript: CAPTUREFILTER.sql 
3) Capture einschalten              - Skript: CAPTURESTART.sql
4) (Optional) Capture stoppen       - Skript: CAPTUREFINISH.sql
5) Capture überprüfen               - Skript: CAPTUREMONITOR.sql
6) AWR Export durchführen           - Skript: EXPORTAWR.sql
...


In der Regel handelt es sich bei der Verwendung um die Packages DBMS_WORKLOAD_CAPTURE und DBMS_WORKLOAD_REPLAY. Die wichtigsten Views sind DBA_WORKLOAD_CAPTURES und DBA_WORKLOAD_REPLAYS. DBA_WORKLOAD_CAPTURES gibt die START SCN, die Anzahl der aufgezeichneten Calls aus und spiegelt den Stand des Captures wider. Die View DBA_WORKLOAD_REPLAYS gibt Informationen über den Stand der Replays.

An dieser Stelle soll noch kurz auf die Reports eingegangen werden, da diese für die Bewertung des Replay-Laufs ausschlaggebend sind. Alle Reports lassen sich im Linemode generieren und stehen häufig in TEXT, HTML oder gar XML Format zur Verfügung. Einfacher zu erzeugen sind diese natürlich über die graphische Oberfläche. Folgende Reports sind dabei möglich und liefern unterschiedliche Bewertungsmaßstäbe:
  • Workload Analyzer Report zeigt Merkmale und Charakteristiken der Capture Dateien vor dem Replay (siehe Abschnitt oben) auf.
  • Replay Report gibt erste Informationen zu Replay Statistiken, Top Events, Workload Profil und Divergenzen.
  • Divergence Report listet die Divergenzen im Detail.
  • Compare Period Report gibt erste Informationen zu der Performance im Vergleich zum Capture oder einem weiteren Replay.
  • AWR Difference Report gibt detaillierte Statistiken zur Performance aus.
Konzentrieren Sie sich zuerst auf den Replay Report und den Divergence Report, damit Sie einen Überblick über das Ergebnis erhalten.Falls zu große Diskrepanzen bestehen, sollten Sie das Backup bzw. ihre Testumgebung überprüfen. Danach können Sie sich der Performance Analyse widmen. Dazu ist die AWR Datei des Captures nötig, die in einem zusätzlichen Schritt importiert wird (siehe Readme). Der Compare Period Report liefert einen guten Überblick über den Zustand der Performance und fokussiert auf die wichtigsten Performance relevanten Informationen. Der AWR Report bzw. der AWR Difference Report rundet diese Informationen in einem letzten Schritt ab.

Der folgende Screenshot zeigt einen Auszug aus einem Compare Period Report.


Für eine größere Ansicht auf das Bild klicken.

10 Tipps für den Einsatz von Real Application Testing

Im Folgenden werden einige Tipps aufgelistet, die Sie unbedingt vor dem Beginn des Einsatzes von DB Replay und SPA beachten sollten.
  1. Bevor man startet, sollte man sich unbedingt die My Oracle Support Note 560977.1 ansehen, um unter Umständen notwendige Patches einzuspielen. Dies gilt für das Quell- und Zielsystem sowie für die Database Replay Clients (auch WRC).

    Des weiteren sollte überprüft werden, ob Real Application Testing auch wirklich installiert worden ist. Dies geschieht über die View v$option. Der VALUE sollte dabei auf TRUE stehen.
    SQL> select parameter,value from v$option 
     where parameter like 'Real Application Testing';

PARAMETER                 VALUE
------------------------- ------------------
Real Application Testing  TRUE
    Falls dies nicht der Fall ist, kann ab Oracle 11g Release 2 mit dem Linemode Werkzeug CHOPT schnell Abhilfe geschaffen werden, wie das folgende Beispiel zeigt. Die Datenbank muss dazu allerdings gestoppt werden. 
    $ chopt enable rat
  2. Tunen Sie vor dem Replay zuerst die Applikation mit SPA. Sie ersparen sich dadurch unter Umständen lange Abspielzeiten bzw. eine umständliche Ursachenforschung, falls das Replay nicht performant abläuft.
  3. Überprüfen Sie, ob Ihr Capture Workload auch keine "non supported Features" beinhalten wird (siehe Application Testing Handbuch).
  4. Überprüfen Sie Ihr Testsystem auf Vollständigkeit (Datenbank-User, Datenbanktabellen usw.). Abgespielt wird nämlich immer, auch wenn Daten nicht korrekt bzw. unvollständig sind. Allerdings werden dadurch sehr viele Fehler entstehen.
  5. Planen Sie ausreichend Zeit für das Replay und die Nutzung verschiedener Replay Optionen (SCN, OFF, OBJECT_ID) ein.
  6. Fahren Sie (wenn möglich) vor dem Capture die Datenbank herunter, um möglichst wenige sogenannte in-flight (noch offene) Transaktionen zu haben, die nicht aufgezeichnet werden können.
  7. Nutzen Sie (Guaranteed) Restore Points für das DB Replay, um wieder einfach zu ihrem Testausgangspunkt zurückzukehren. Sorgen Sie dann allerdings dafür, daß ausreichend Platz für Flashback und Archive Log Dateien zur Verfügung steht.
  8. Verwenden Sie vor dem Abspielen die Informationen aus dem Workload Analyzer Report - entweder über die graphische Oberfläche (ab 11.2.0.2) oder über den Linemode Aufruf (siehe auch Skript Download).
  9. Überlegen Sie, wie Sie mit externen Quellen wie DB Links, External Tables, URLs etc. umgehen - ob Sie diese zur Verfügung stellen können oder nicht.
  10. Begrenzen Sie die Capture Dauer auf wenige Stunden. Ideal sind 1 bis 2 Stunden.

Neu: Consolidated Database Replay

Gibt es die Möglichkeit, mehrere Workloads von verschiedenen Servern auf einem Rechner abzuspielen? Typische Beispiele sind Szenarios, in denen man feststellen möchte, ob eine Konsolidierung erfolgreich sein wird. Als zentrales Verwaltungssystem sammelt Oracle Enterprise Manager Cloud Control 12c viele Daten hinsichtlich der Nutzung von IT-Ressourcen und nutzt diese Informationen als Planungsgrundlage für Konsolidierungsprojekte im sogenannten Consolidation Planner. Dieser ist im Plug-in "Oracle Chargeback and Capacity Planning" enthalten. Unabhängig davon stellt DB Replay mit der neuen Technologie Consolidated Database Replay eine Möglichkeit zur Verfügung, ein Replay mehrerer Capture Workloads vom gleichen Server oder von verschiedenen Servern durchzuführen. So können Konsolidierungsprojekte verifiziert und Probleme und Engpässe vorab beseitigt werden.

Welche Voraussetzungen sind dazu notwendig? Die Datenbank Version des Servers muss mindestens 11.2.0.2 sein. Zusätzlich ist ein Patch für das Replay System erforderlich (siehe MOS Note 1453789.1). Das Capture System bleibt allerdings unverändert; eine Aufzeichnung kann ab der Version 9.2.0.8 erfolgen. Bevor der Replay gestartet werden kann, sollten, wie schon mehrfach erwähnt, die Applikationsdaten des Capture System mit dem Startpunkt der Aufzeichnung übereinstimmen. Eine weitere Voraussetzung ist die Trennung der unterschiedlichen Capture Workloads in unterschiedliche Schemas. Dies bedeutet, dass vor dem Replay die einzelnen Schemas auf dem Zielsystem "restored" werden müssen. Es liegt in der Natur der Sache, dass auch die Processing Dateien in unterschiedlichen Directories liegen. Für das Replay müssen diese Directories allerdings in ein gemeinsames Verzeichnis kopiert werden. Um diese Aktionen zu ermöglichen, wurde das Package DBMS_WORKLOAD_REPLAY durch einige Prozeduren erweitert. Das weitere Vorgehen beim Replay gleicht ansonsten dem Verfahren wie oben beschrieben. Skripte und eine Dokumentation zum gesamten Ablauf finden sich in der MOS Note 1453789.1.

Informationen und Links

Folgende Tipps und Links können hilfreich sein:Mehr zu diesem Thema bzw. zu weiteren Themen rund um die Datenbank lesen Sie in den nächsten Ausgaben ...

Zurück zur Community-Seite