Real Application Testing – Teil 2 von 7

Eines der Highlights innerhalb der Oracle Application Quality Management Lösungen ist das Real Application Testing.

Wie bereits erwähnt bietet Real Application Testing eine einfache Lösung, um Testabläufe zu vereinfachen und Systeme mit realen Applikationslasten zu testen. Hierbei handelt es sich  – ganz einfach formuliert – um ein Werkzeug für die Datenbank, das einen Workload aufzeichnet und in einer Testumgebung wieder abspielen kann.

Genau genommen muss Real Application Testing nicht extra installiert werden, denn es ist bereits in der Oracle Datenbank verfügbar und kann über PL/SQL aufgerufen werden. Daneben können Real Application Testing Funktionen oder die Enterprise Manager Benutzeroberfläche aufgerufen werden. Ohne zusätzlichen Aufwand – wie beispielsweise dem Einsatz spezieller Skriptsprachen – ist es möglich eine Last oder einen SQL Workload aufzeichnen und in einer existierenden Testumgebung abzuspielen.

Somit bietet diese spezielle Test Design Technik, welche Ähnlichkeiten zum Real Life Test hat, besonders bei Datenbank Upgrades, Patch Anwendungen und Konfigurationsänderungen im Datenbankumfeld an.

Real Application Testing beinhaltet drei Lösungen zum Testen von Abwendungen und Systemen:

• SQL Performance Analyzer (SPA) zur Bewertung der Auswirkungen von Systemänderungen auf SQL-Reaktionszeiten durch die Ermittlung von Abweichungen in den SQL-Ausführungsplänen und Performance-Statistiken
• Application Replay ist für das automatisierte Testen von Datenbank- und Web-Anwendungen sowie Webservices geeignet
• Database Replay dient der effektiven Prüfung von Systemveränderungen in Testumgebungen. Hierzu werden Workloads, welche in Produktivumgebungen aufgezeichnet wurden, in der Testumgebung abgespielt, um die Auslastung auf dem Testsystem zu bestimmen beziehungsweise die Gesamtwirkung in Bezug auf Systemveränderungen zu bewerten

Alle drei Lösungen bieten zusammen eine umfassende und flexible Testtoolplattform zur End-to-End Prüfung von Systemlandschaften, welche im Folgenden genauer betrachtet werden:

SQL Performance Analyzer

Der Fokus von SQL Performance Analyzer (SPA) liegt auf der detaillierten Statement Analyse eines definierte SQL Workloads. Ein SQL Workload besteht dabvei aus SELECT Statements beziehungsweise DML Statements, welche über ein SQL Tuning Set (STS) zur Verfügung gestellt werden. Der SQL Workload wird dabei zweimal abgespielt: Einmal vor und einmal nach der Veränderung. Somit lassen sich Auswirkungen von Systemveränderungen über verschiedene gemessenen Kenngrößen, wie zum Beispiel der „elapsed time“,  bewerten. In der Folge kann ein Tuning Prozess mithilfe des SQL Tuning Advisors oder SQL Plan Baselines durchgeführt werden. An dieser Stelle sei erwähnt, dass der SQL Tuning Advisor über das Oracle Tuning Pack zuvor zu installieren ist.

SPA ist komplett automatisiert und vereinfacht somit die Durchführung von Testprozessen. Nach den Tests werden die DML Statements automatisch zurückgerollt. So entfallen die sonst üblichen wie auch aufwendigen Vorbereitungen im Datenbankbereich für den nächsten Testlauf.

SPA bietet auch eine Reihe von Auswertungen an. Im SPA-Bericht werden die Auswirkungen in Bezug auf die durchgeführten Systemveränderungen erläutert.  Interessant ist aber sicherlich auch die Ergebnisse des SQL Tuning Advisors zu berücksichtigen. Dieser liefert eine Reihe von Empfehlungen zu SQL Profile, Statement Änderungen, Statistiken oder alternativen SQL Plänen.

Application Replay

Das Oracle Application Replay Pack bietet Testautomatisierung über die Middle-Tier oder basierend auf  HTTP Requests und ermöglicht so realistische Tests auf jeder Ebene vom Anwendungs-Server bis auf die Festplatte, indem die Produktionslast auf einem Testsystem übertragen wird. Dies erlaubt automatisiertes Testen innerhalb einer Testumgebung unter realistischen beziehungsweise produktionsnahen Bedingungen. Änderungen wie Server-Upgrades, Hardwareupdates, Betriebssystem- oder Konfigurationsänderungen können innerhalb von Testumgebungen geprüft werden. Hierbei liefert das Tool wichtige Aussagen über mögliche Auswirkungen, welche sich auf die Verhältnisse in der Produktion übertragen lassen.

Database Replay

Das Database Replay Werkzeug ermöglicht das Abspielen von Datenbanktransaktionen in einer Testumgebung, deren Transaktionsdaten zuvor aus einer anderen Umgebung aufgezeichnet wurden.

Das Datenbase-Replay-Verfahren ist in vier Schritten durchzuführen:

• Workload Capture: Das Capture zeichnet die Workloaddaten auf dem Produktionssystem  auf. Es handelt sich hierbei um einen einfach zu initiierenden Prozess, der nur wenig Overhead auf dem Produktionssystem erzeugt. Es ist hierbei ratsam die Aufzeichnungszeit auf ein bis zwei Stunden zu limitieren. So lassen sich mehrere Tests durchführen und es reduziert die Analyseaufwände im Problemfalle nach dem Abspielen.Die Größe der Capture Dateien wird maßgeblich durch die Anzahl der verschiedenen Statements, die Verwendung von LOBs und Bulk Binds oder beispielsweise durch die Anzahl der Datenbankverbindungen und der Parallelisierung bestimmt. Über das Filtern nach User, Instance ID oder Services beispielsweise kann die Größe der Capture Dateien beeinflusst werden.
• Workload Processing: Das Workload Processing bereitet die Daten einmalig als Vorbereitung für das nachfolgende Replay auf. Die Verarbeitungsdauer ist abhängig von der Menge und Komplexität der Captures. Interessant ist noch, dass das Workload Processing nicht zwingend auf dem Testsystem erfolgen muss.Wichtig ist allerdings, dass auf dem betreffenden System das gleiche Datanbank-Release wie auf dem Testserver vorhanden ist. Somit lassen sich die verschiedenen Phasen parallelisieren. Der Workload Analyzer kann parallel zur Vorbereitung angestoßen werden. So kann das Werkzeug bereits Auffälligkeiten der Captures während der Datenaufbereitung anzeigen.
• Workload Replay: Das Replay besteht aus mehreren Schritten. Zuerst muss angegeben werden, wo das Workload Replay Tool die aufgezeichneten Daten zum Abspielen findet. Hierzu muss ein logisches Verzeichnis festgelegt werden, in welchem sich die Aufzeichnungen befinden. Daran folgt ein Vorbereitungsschritt, in welchem die Abspielart festgelegt wird. Dann wird der aufgezeichnete Workload mithilfe spezieller Workload Replay Clients (WRC) abgespielt.Bevor man jedoch mit dem Replay beginnt, sollte man über dessen Art nachdenken. Per default ist ein COMMIT-synchrones Abspielen festgelegt. In Abhängigkeit des Workload Charakters oder der definierten Testziele kann es jedoch ratsam sein, von den Defaulteinstellungen abzuweichen; zum Beispiel mit synchronization FALSE. Hierzu ist im nachfolgenden Praxisteil ein entsprechendes Beispiel aufgeführt.
• Analyse und Reporting: Das Modul stellt umfangreiche Berichte in TEXT-, HTML- oder XML-Format mit detaillierten Analyseinformationen zum Aufnahme- und Wiedergabeprozess dar. Hierbei werden Fehler oder Abweichungen in den Daten, die während der Wiedergabe auftreten, im Bericht dokumentiert.Folgende Reports werden angeboten und können sowohl über die grafische Benutzeroberfläche des Oracle Enterprise Managers als auch auf Kommandozeilenebene aufgerufen werden:
  • Workload Analyzer Report (AWR): Dieser Bericht zeigt Merkmale und Charakteristiken der Capture-Dateien vor dem Replay auf
  • Replay Report: Der Bericht liefert erste Informationen  zu Replay-Statistiken, Top-Events, Workload-Profil und Divergenzen
  • Divergence Report: Dieser Bericht listet die Divergenzen im Detail auf
  • Compare Period Report: Dieser Bericht liefert gibt erste Informationen zu der Performance im Vergleich zum Capture oder einem weiteren Replay
  • AWR Difference Report
  • ASH Report