Real Application Testing – Teil 3 von 7: in der Praxis

Einige Praxisbeispiele

Im Folgenden erläutern einige Beispiele wie Real Application Testing in der Praxis wichtige Informationen über die Qualität von Datenbank- und Webanwendungen sowie Webservices liefert, um richtige Entscheidungen zur Produktivsetzung zu treffen.

Beispiel 1: Datenbankupgrade auf die nächste Version

Aufgabe

Eine Produktionsumgebung mit einer älteren Datenbankversion sollte auf die aktuelle Version angehoben werden. Somit ist es wichtig, die zugesagten Leistungs- und Qualitätsanforderungen nach dem Upgrade weiterhin zu erfüllen. Andernfalls drohen entweder ungeplante Ausfälle oder reduzierte Serviceverfügbarkeiten.

Lösung

Die daraus resultierenden Fragen können mit dem  SQL Performance Analyzer in Kombination mit dem Database Replay Tool behandelt und beantwortet werden. Es muss geprüft werden, ob Leistungsverschlechterungen beziehungsweise Performance-Probleme oder – durch Codeänderungen in der neuen Version verursachte – Fehler entstanden sind.

Methode

Zunächst sollten Performance-Probleme, welche aus Planänderungen resultieren, ermittelt werden. Jede neue Datenbankversion kann Veränderungen innerhalb des Optimizers im Vergleich zur Vorgängerversion beinhalten. Dies kann dazu führen, dass einige SQL Statements in suboptimale Pläne aufgelöst werden.

1) Zunächst ist es wichtig die Leistungsschwächen zu bestimmen, bevor konkurrierende Tests mittels Database Replay ausgeführt werden. Folgende Schritte sind somit als erstes durchzuführen:

  • Das SQL Tuning Set (STS) aus der Produktion wird aufgezeichnet. Hierbei wird empfohlen, mehrere STS aus verschiedenen Geschäftszeiten aufzuzeichnen wie z.B. normale Bürozeiten, Nachtbetrieb und Monatsende, welche unterschiedliche Lastsituationen repräsentieren.
  • Die  SPA Tests werden am besten gegen eine Kopie der Produktion ausgeführt, um eine Baseline aufzusetzen.
  • Die Datenbank wird auf die neue Version angehoben.
  • Die  SPA Tests werden auf der angehobenen Datenbank nochmals ausgeführt.
  • Innerhalb des SPA Berichts sind nun die wiederholt vorkommenden SQL Anweisungen zu identifizieren.
  • Betreffende SQL-Anweisungen sind zu optimieren. Hierzu ein Tipp: der Tuning Advisor liefert zusätzliche Informationen über SQL Profile oder neue Indizes. Sollten diese Maßnahmen nicht helfen, so kann mithilfe von SQL Plan Management auf den alten Plan zurückgestellt werden.
  • Nach der Optimierung werden die SPA Tests wieder ausgeführt. Hierbei sollte stets nur ein Optimierungsschritt – und nicht mehrere Schritte – zwischen zwei Prüfungen durchgeführt werden. So lassen sich im Fehlerfalle schneller die Ursachen ermitteln. Selbst ein einziger Tuningschritt bzgl. einer SQL Anweisung kann zu unbeabsichtigten, negativen Effekten bei anderen SQL Anweisungen führen. Durch die konsequente Zerlegung der Tuning Aufgaben in Einzelschritte mit nachfolgender Validierung vereinfachen sich in diesen Fällen Analyseaktivitäten.
  • Die Tuning Ratschläge sind zu implementieren und die betreffenden SPA Tests auszuführen, bis alle SQL Wiederholungen in einem iterativen Prozess aufgelöst sind.

2)  Jetzt, nachdem alle SQL Wiederholungen aufgelöst wurden, kann Database Replay initiiert werden. Hierbei ist zu empfehlen, zunächst mit kurzen Replays zu starten und später diese schrittweise zu verlängern.

  • Für den betreffenden Zeitraum ist zunächst der Workload auf der Produktion aufzuzeichnen.
  • Zuvor ist es jedoch ratsam eine Sicherung der Datenbanken des Produktionssystems vorzunehmen. Hierbei ist sicherzustellen, dass der Sicherungszeitpunkt des Backups so gewählt wird, dass nach einer notwendigen Datenrücksicherung die Daten wieder dem Zeitpunkt kurz vor dem Beginn der Workload Aufzeichnungen entsprechen. Der Capture Report enthält ein sogenanntes SCN oder System Change Number. Immer, wenn ein Commit abgesetzt wird, wird der SCN hochgesetzt. Diese Informationen werden in Blockheaders, Logfiles und Control Files gespeichert. Sobald die Datenbank heruntergefahren wird, sollten alle Artefakte konsistent sein. Andernfalls muss die Datenbank wiederhergestellt werden.
  • Der Workload Capture Prozess speichert die Workload Daten des Produktionssystems, welche nachfolgend auf dem Testsystem abgespielt werden sollen.
  • Die gesicherten Workload Daten sind im Workload Analyzer zu überprüfen. Dieses Tool prüft die aufgezeichneten Workload Daten auf etwaige Fehler, welche in der Folge auch von dem Werkzeug behoben werden.
  • Die gesicherte Datenbank aus der Produktionsumgebung wird nun auf der Testumgebung wiederhergestellt.
  • Die Wiedergabe der Workload Daten ist zu starten. Die Wiedergabe kann mit verschiedenen Synchronisationsmodis ausgeführt werden. Der geeignete Modus kann mithilfe der Validation Application Scripts ermittelt werden.
  • Die Testergebnisse sind nach der Wiedergabe zu prüfen. Hierzu kann der Replay Report, Compare Period Report, ADDM (Automatic Database Diagnostic Monitor)  und der Standard AWR (Automatic Workload Repository) Report zur Analyse von Fehlern benutzt werden.

Es ist nicht ungewöhnlich, dass nach dem ersten Replay Fehler protokolliert werden.  Die Gründe hierfür liegen oft in nicht korrektem System Setup oder neu auftretende Probleme aufgrund Veränderungen an dem System. Das Upgrade eines Datenbanksystems ist hierunter natürlich auch zu verstehen. Das System ist Schritt für Schritt im Rahmen eines iterativen Prozesses zu optimieren und nach der zuvor beschriebenen Methode zu prüfen, bis das Ergebnis zufriedenstellend ist.

Das könnte Sie auch interessieren

Bleiben Sie informiert:

its-people hilft Ihnen...

Weitere Blogthemen: