Der nächste Schritt zu professionellen Service- und Softwaretests

Reality Check
Kommentare

Eine der großen Herausforderungen für Unternehmen ist es, bei der wachsenden Auswahl an Lösungen und Diensten, die sie online zur Verfügung stellen, die Anwendungsqualität zu wahren. Mit der steigenden Anzahl an Upgrades und Patches wächst auch der Bedarf an professionellen Softwaretests. In Bezug auf Cloud-Lösungen gewinnt die Servicequalität – neben der Softwarequalität – immer mehr an Bedeutung. Die Frage ist: Wie kann sichergestellt werden, dass die Anwendungsqualität den aktuellen Kundenanforderungen entspricht? Real Application Testing hält hier einige Lösungen parat.

Unternehmen investieren immense Summen in neue Anwendungen, um ihren Kunden bessere und kostengünstigere Dienste zu liefern. Schlechte Softwarequalität kann diese Investitionen jedoch gefährden. Studien haben gezeigt, dass mehr als 40 Prozent der Softwareanwendungen mit kritischen Defekten in produktiven Umgebungen zu finden sind. Um diese Mängel in der Produktion zu beheben, bedarf es im Verhältnis zur Entwicklungsphase des hundertfachen Aufwands. In Kundenumfragen zeigt sich eine Korrelation zwischen dem Umfang der durchgeführten Tests und der Kundenzufriedenheit bezüglich der betreffenden Anwendung. Unternehmen, die über vergleichsweise viele formalisierte Prüfungen in den Bereichen Funktionalität, Zuverlässigkeit, Effizienz, Benutzbarkeit, Wartbarkeit und Änderbarkeit verfügen, erzielen bessere Ergebnisse als Unternehmen, die nicht oder nur wenig formalisiert testen. Deshalb gewinnt heute das Application Quality Management immer mehr an Bedeutung – um die Businessagilität und vereinbarte Servicelevels zu unterstützen, aber auch um Kosten und Risiken zu reduzieren. Das Testen und Prüfen von Anwendungen und Systemen gehört zu den Königsdisziplinen in der IT. Die Einführung von Systemen ohne genügende und richtige Prüfung führt immer zu einer langen Leidensphase für Anwender und für die IT-Verantwortlichen.

Typische Herausforderungen im Bereich der Softwaretests

Aufgrund steigender Kundenanforderungen werden Softwaretests komplexer und teurer. Aus diesem Grund sehen sich Testmanager und Testingenieure oft mit folgenden Herausforderungen konfrontiert:

  • Es besteht die Notwendigkeit, die Anwendungen auf Basis der tatsächlich vorherrschenden Produktionsverhältnisse (z. B. Workload, Datenvolumen in der Datenbank, konkurrierende Anforderungen, Benutzeraktivitäten/Interaktion etc.) zu prüfen. Diese Testanforderungen sind jedoch schwer auf Grundlage klassischer Testtechniken im Testumfeld zu erfüllen, und die Durchführung von Anwendungstests auf Produktionsumgebungen kann aus Sicherheits- und Stabilitätsgründen nicht realisiert werden.
  • Aktuelle Prozessanalysen zu Testaktivitäten in verschiedenen IT-Projekten mit unterschiedlichen Durchlaufzeiten aus verschiedenen Branchen zeigen einen steigenden Zeit- und Ressourcenbedarf an. Diese Erkenntnis liegt in zwei Faktoren begründet:
    • Im Vergleich zu früheren Zeiten müssen QS-Prozesse heute Antworten auf deutlich mehr Qualitätsmerkmale liefern. Das bedeutet, dass der Testaufwand deutlich zunimmt.
    • Analysen der letzten Jahre zeigen auch, dass die Komplexität der Fehlersituationen zunimmt. Hierdurch steigt der Bedarf an mehr Testzyklen und Analyseaufwand.

Die beste Prüfung ist somit meist die, die am nächsten an die realen Anwendungsfälle und Lastprofile heranreicht. Nicht umsonst baute kürzlich ein renommierter Automobilhersteller auf mehreren Kilometern eine der schlechtesten Straßen der Republik als Teststrecke für das firmeneigene Testcenter nach. Nichts ist realer als die Realität.
Das ist auch das Grundprinzip und die Idee hinter Real Application Testing: Hierbei werden alle relevanten Parameter aus der Produktion aufgezeichnet und auf die Testumgebung übertragen, die dann Tests in produktionsähnlichen Situationen möglich macht.

Einführung in das Oracle Application Quality Management

Über Jahre hat Oracle Testwerkzeuge speziell für Oracle-Datenbank- und Siebelanwendungen entwickelt. Oracle bietet in der aktuellen Produktversion 12C des Enterprise Managers verschiedene Testtools mit erweitertem Funktionsumfang zu Real Application Testing an. Diese Tools gehören zu den Application-Quality-Management-Lösungen, auf die über die Oracle Enterprise-Manager-Benutzeroberfläche zugegriffen werden können. Diese Funktionen bieten High Quality Testing auf allen Anwendungsebenen beziehungsweise -schichten und helfen Unternehmen, die Anwendungsqualität und -leistung zu bestimmen, Kosten zu reduzieren und die Einhaltung der Kundenanforderungen sicherzustellen.
Die Oracle-Testlösungen bieten eine einzigartige Kombination von Testfunktionen, die sich in drei Themenbereiche strukturieren lassen:

  • Testen von Infrastrukturänderungen: Das Real Application Testing wurde für Veränderungen an Datenbankinfrastrukturen entworfen, indem es aktuelle Workloads aus der Produktion verwendet, um in der Testumgebung die Datenbankperformance zu prüfen.
  • Testen von Änderungen in Softwareanwendungen: Die Application Test Suite unterstützt komplette End-to-End-Tests über automatisierte Funktional- und Lasttests. Die spezifizierten Tests lassen sich über Testmanagementwerkzeuge verwalten und ausführen.
  • Verwaltung von Testdaten: Das Data Masking Pack hilft, vertrauliche und personalisierte Daten zu anonymisieren, um Sicherheits- und Compliance-Ziele zu erreichen. So lassen sich Daten aus der Produktion als Testdaten in Testumgebungen nutzen, ohne hierbei Datenschutzrichtlinien zu verletzen.

Die Application Testing Suite (ATS) repräsentiert eine umfassende Lösung zum Testen von Oracle-Anwendungen wie E-Business Suite, Siebel, Fusion, JD Edwards, Peoplesoft und Hyperion. Sie ermöglicht die Realisierung zuverlässiger und robuster Skripte, wobei deren Erstellung im Verhältnis zu vergleichbaren Testsystemen nur die halbe Zeit beansprucht. Der Gesamtaufwand im Testen wird um ca. 25 Prozent reduziert. Der Grund für den reduzierten Aufwand liegt in der Fokussierung auf Oracle-Plattformen. Das integrierte Framework ist speziell auf die verschiedenen Oracle-Anwendungen ausgerichtet und erlaubt es mit einer deutlich geringeren Anzahl an Kommandos, automatisierte Testprozesse zu realisieren. In der Oracle Application Testing Suite gibt es drei separat zu lizenzierende Produkte:

  • Oracle Test Manager: Dieser ist für die Dokumentation und Verwaltung der Testfälle, Testanforderungen, Testplanung und die Fehlerverwaltung verantwortlich. Der Oracle Test Manager bietet Unterstützung für manuelle und automatisierte Tests für verschiedene Teststufen von den Komponenten- bis zu den Systemintegrationstests.
  • Oracle Functional Testing: Das Werkzeug dient zur Automatisierung funktionaler Tests von Webanwendungen, Oracle-Anwendungen und Webservices.
  • Oracle Load Testing: Das Tool führt automatisierte Last- und Performancetests von Webanwendungen, Oracle-Anwendungen sowie Datenbank- und Web Services durch.

Aufmacherbild: conceptual sign with words reality check ahead caution warning over dark blue sky von Shutterstock / Urheberrecht: RedDaxLuma

[header = Real Application Testing]

Real Application Testing

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 aufzuzeichnen und in einer existierenden Testumgebung abzuspielen. Somit bietet sich diese spezielle Testdesigntechnik, die Ähnlichkeiten mit Real Life Test hat, besonders bei Datenbankupgrades, Patch-Anwendungen und Konfigurationsänderungen im Datenbankumfeld an.
Abb. 1: Real Application Testing Module

Real Application Testing enthält drei Lösungen zum Testen von Anwendungen 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 Performancestatistiken
  • Application Replay ist für das automatisierte Testen von Datenbank- und Webanwendungen sowie Web Services geeignet.
  • Database Replay dient der effektiven Prüfung von Systemveränderungen in Testumgebungen. Hierzu werden Workloads, die 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. Im Folgenden werden sie genauer betrachtet.

SQL Performance Analyzer

Der Fokus von SQL Performance Analyzer (SPA) liegt auf der detaillierten Statementanalyse eines definierten SQL Workloads. Ein SQL Workload besteht dabei aus SELECT-Statements beziehungsweise DML-Statements, die ü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 gemessene Kenngrößen, wie zum Beispiel die „elapsed time“, bewerten. In der Folge kann ein Tuningprozess 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 aufwändigen 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 es aber sicherlich auch, die Ergebnisse des SQL Tuning Advisors zu berücksichtigen. Dieser liefert eine Reihe von Empfehlungen zu SQL-Profilen, 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 Anwendungsserver bis auf die Festplatte, indem die Produktionslast auf ein Testsystem übertragen wird. Dies erlaubt automatisiertes Testen innerhalb einer Testumgebung unter realistischen beziehungsweise produktionsnahen Bedingungen. Änderungen wie Serverupgrades, Hardwareupdates, Betriebssystem- oder Konfigurationsänderungen können auf diese Weise innerhalb von Testumgebungen geprüft werden. Hierbei liefert das Tool wichtige Aussagen über mögliche Auswirkungen, die 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.


Abb. 2: Die Prinzipschritte des Database Replay

Das Datenbase-Replay-Verfahren ist in vier Schritten durchzuführen:
Workload Capture:
Das Capture zeichnet die Workload-Daten 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 die Analyseaufwände im Problemfall nach dem Abspielen reduzieren. 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 die 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 Datenbankrelease 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 dem sich die Aufzeichnungen befinden. Danach folgt ein Vorbereitungsschritt, in dem 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 gibt erste Informationen zu der Performance im Vergleich zum Capture oder einem weiteren Replay
  • AWR Difference Report
  • ASH Report

[ header = Einige Praxisbeispiele]

Einige Praxisbeispiele

Im Folgenden zeigen einige Beispiele aus der Projektpraxis, wie Real Application Testing wichtige Informationen über die Qualität von Datenbank- und Webanwendungen sowie Web Services liefert, um richtige Entscheidungen zur Produktivsetzung zu treffen.


Aufgabe
: Eine Produktionsumgebung mit einer älteren Datenbankversion soll 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 Performanceprobleme oder durch Codeänderungen in der neuen Version verursachte Fehler entstanden sind.
Methode
: Zunächst sollten Performanceprobleme, die 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.

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, die 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 Fehlerfall 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 Tuningaufgaben in Einzelschritte mit nachfolgender Validierung vereinfachen sich in diesen Fällen die Analyseaktivitäten.
  • Die Tuningratschläge sind zu implementieren und die betreffenden SPA-Tests auszuführen, bis alle SQL-Wiederholungen in einem iterativen Prozess aufgelöst sind.

Nachdem alle SQL-Wiederholungen aufgelöst wurden, kann Database Replay initiiert werden. Hierbei ist zu empfehlen, zunächst mit kurzen Replays zu starten und diese später 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 zu gewährleisten, dass der Sicherungszeitpunkt des Back-ups 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 so genanntes SCN oder System Change Number. Immer dann, 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, die 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, die 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 Synchronisationsmodi ausgeführt werden. Der geeignete Modus kann mithilfe der Validation-Application-Skripte 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-Set-up oder neu auftretenden Problemen aufgrund Veränderungen am 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.

[header = Konsolidierung und Validierung neuer Hardware]


Aufgabe:
In vielen Rechenzentren von Unternehmen und Konzernen sieht man heute häufig folgendes Szenario: Es gibt viele – meist hundert oder mehr – Oracle-Datenbanken auf unzähligen Servern verteilt, die die Daten für Anwendungen verwalten. Ferner kommt nicht auf allen Servern das gleiche Betriebssystem zum Einsatz, noch stammen die Server aus der gleichen Hardwarefamilie. Oft laufen verschiedene Versionen der Datenbankmanagementsysteme innerhalb des Rechenzentrums, auf denen jeweils ein Teil der Datenbanken residieren. Das gesamte Umfeld ist somit schwierig zu verwalten.
So liegt es nahe, dass das IT-Management die Menge von Datenbanken in einer standardisierten Plattform konsolidieren will. Das Ziel sollte es hierbei sein, die Anzahl der Datenbanken als auch die hierzu benötigten Server deutlich zu reduzieren. In der Folge reduziert sich der Wartungs- und Administrationsaufwand im Rechenzentrumsbetrieb.
Methode
: Das erste Ziel ist es, eine kosteneffiziente Hardware zu finden, die den Lastanforderungen aus der Produktion genügt und darüber hinaus noch Leistungsreserven bietet. Auf Basis dieser Anforderungen kann man von Hardwareherstellern problemlos Angebote zu verschiedenen Lösungsoptionen bekommen. Die Frage ist jedoch: Wie kann sinnvoll bestätigt werden, ob die Behauptungen des Herstellers tatsächlich auf das konkrete Umfeld zutreffen? Und welche der angebotenen Plattformen stellt sich als die beste Alternative dar? Wäre vielleicht das kostengünstigste Angebot ausreichend, da die betreffende Hardwarelandschaft die Lastanforderungen ausreichend erfüllt? Reine Ermittlung und Vergleiche der Performancewerte einzelner Systeme helfen nicht wirklich weiter, da letztlich das konkrete IT-Umfeld und das Lastverhalten unberücksichtigt bleiben. Real Application Testing liefert jedoch die notwendigen Aussagen, da in einer Testumgebung mithilfe echter Last und Datenvolumen aus der Produktion die Eignung der verschiedenen Hardwarealternativen überprüft werden kann.
Um Leistungseinbußen im SQL-Umfeld zu vermeiden, wird SPA zur Identifikation potenzieller Leistungsverschlechterungen eingesetzt. Das heißt, hier ist der gleiche Ansatz wie in Beispiel 1 – konkret sind dies die Maßnahmen des ersten Abschnitts – auszuführen. Nachdem die Fragen bzgl. möglicher Leistungseinbußen beantwortet sind bzw. etwaige Leistungsschwächen beseitigt wurden, kann die Arbeitsauslastung der Hardware mithilfe des Tools Database Replay geprüft werden. Alle Datenbankanalysen werden mithilfe von AWR durchgeführt. Deren Berichte liefern alle Details zu Datenbankzeiten. Daneben sollte man während der gesamten Untersuchung auch die OS-Statistiken im Auge behalten:

  • Die erste Replay-Iteration dient lediglich dazu zu prüfen, ob der entwickelte Testlauf keine großen Fehler enthält. Diese sollten zuerst behoben werden, bevor der eigentliche Test beginnt, um belastbare Ergebnisdaten zu erhalten. Die Replay-Funktion bietet eine Reihe von Parametern, die das Systemverhalten beeinflussen. In Bezug auf das konkrete System beziehungsweise die Datenbankanwendung können die optimalen Einstellungen variieren. Das heißt, es gibt keine Goldene Regel hierzu. Bevor also die eigentliche Vorprüfung oder die nachfolgenden Tests beginnen, ist Replay über geeignete Parameterwahl an das konkrete System anzupassen. Hierbei sind vor allem die Parameter sync, think_time und connect_time zu berücksichtigen, worüber das Datenvolumen beim Replay pro Zeiteinheit beziehungsweise der Replay-Modus gesteuert werden kann.
  • Nach erfolgreicher Vorprüfung kann der erste Test gestartet werden. Hierbei wird mit der vom Hersteller empfohlenen Hardwarekonfiguration begonnen. Vor den Tests sind nochmals die Replay-Parameter zu prüfen.
  • Der aufgezeichnete Workload wird auf jeder Plattform abgespielt, um jegliche Abweichung zur Produktion festzustellen. Es werden die zehn wichtigsten Performanzaussagen, wie zum Beispiel CPU, I/O oder Zeitbedarf aus den AWR Reports, für die Analyse und Bewertung ausgewählt. Der AWR Report dokumentiert für jede Konfiguration alle relevanten Informationen beziehungsweise Messwerte zu Zeit- und Ressourcenverbrauch zu allen wichtigen Hardware- und Datenbankkomponenten.
  • Aufgabe 1/Identifizierung des CPU-Engpasses: Hierbei wird das Abspielen der Workloads mehrfach wiederholt. Dabei wird die Anzahl der verfügbaren CPUs schrittweise verringert. Dabei ist es wichtig, über den AWR die Wartezeiten zu ermitteln. Mit dieser Methode kann die Minimalkonfiguration eines Systems ermittelt werden, die für einen erfolgreichen Betrieb benötigt wird.
  • Aufgabe 2/Plattformskalierbarkeit: Der aufgezeichnete Workload wird hierbei mit dem SCALEUP_MULTIPLIER ausgeführt. Der SCALEUP_MULTIPLIER multipliziert die Benutzeranzahl und die Nur-Lese-Operationen von jeder Shadow Session. Daneben kann man aber auch die connect_time und think_time verringern, um eine höhere Last zu simulieren. Die Änderung der SCALEUP_MULTIPLIER (sinnvoll sind hier Werte von 2, 4 oder 8) hilft, die Skalierbarkeit für jede Konfiguration zu ermitteln. Diese Methode ermittelt die Plattform mit dem besten Preis-Leistungs-Verhältnis.
  • Aufgabe 3/Verringerung der Datenbankanzahl durch Serverkonsolidierung: Hierbei ist zu prüfen, ob mehrere Anwendungen in derselben Datenbank koexistieren können. Diese Überprüfung kann mithilfe des so genannten „Consolidated Replay“ erfolgen. Damit ist es möglich, mehrere Workloads verschiedener Anwendungen beziehungsweise Datenbanken auf der gleichen Datenbank einzuspielen. Dies kann in folgenden Schritten durchgeführt werden:
    • Aufzeichnung der SQL Tuning Sets für die betreffenden Datenbanken, die zu konsolidieren sind.
    • Ausführen der SQL-Performance-Analyzer-Leistungsanalyse für die betreffenden Datenbanken, die zu konsolidieren sind, um SQL-Wiederholungen zu identifizieren.
    • Aufzeichnen des interessanten Zeitbereichs eines Workloads von jeder Datenbank, die zu konsolidieren wäre.
    • Zunächst wird jeder Workload isoliert abgespielt, um etwaige Performanzprobleme oder Fehler zu beseitigen.
    • Ausführung eines Consolidated Replays: Nach jeder erfolgreichen Iteration beziehungsweise Beseitigung aller Probleme und Fehler in einem aufgezeichneten Workload wird besagte Aufzeichnung an das Abspielschema angefügt. Die Leistungswerte des Servers und der Datenbank werden dabei überwacht und bewertet. Der Replay Report zeigt neue Fehler oder Performanzprobleme auf, die während der Wiedergabe auftreten. Diese sind dann natürlich zu beseitigen. Ist dies unmöglich, so wird hierdurch angezeigt, dass sich die betreffende Datenbank der zuletzt hinzugefügten Workload-Aufzeichnung nicht mit den anderen Datenbanken konsolidieren lässt.

Ergebnisse: Mit diesem Ansatz kann rasch ermittelt werden, welche der Plattformen das beste Preis-Leistungs-Verhältnis bietet. Darüber hinaus kann die Frage beantwortet werden, welche Risiken bei einer Konsolidierung von Anwendungen zu beachten sind. Die Tests zeigen ferner auf, welche Anwendungen auf derselben Datenbank residieren können, ohne sich gegenseitig zu stören. Des Weiteren liefern die Tests Informationen über den zukünftigen Ressourcenbedarf. Gerade bei Konsolidierungen, in denen Datenbanksysteme zusammengefasst werden, sind diese Informationen besonders wichtig.


Aufgabe
: Ein großer Webshop kann seine Tabellenstatistiken nicht mehr aktualisieren, seitdem das Erneuern der Statistiken zu einigen SQL Regressionen und geringerer Systemperformance führte. Das System läuft also seit Langem mit veralteten Statistiken. So reduzierte sich die Systemleitung während der letzten Monate. Nun müssen neue Statistiken erzeugt werden, um die Performance zu erhalten. Bei dieser Maßnahme könnten aber neue Performanceprobleme auftreten.
Ansatz
: Seit der Oracle-Datenbankversion 11g R1 können Statistiken im so genannten „Pending Mode“ gesammelt werden. Das bedeutet, dass neue Statistiken erzeugt, aber die entsprechenden Informationen nicht im Optimizer verwendet werden: Sie werden nicht veröffentlicht.
Der SQL Performance Analyzer (SPA) kann Statistiken im Pending Mode verwenden, um die Leistung des Datenbanksystems zu überprüfen. Der Enterprise Manager 12c enthält eine Benutzeroberfläche zur Steuerung des SQL Performance Analyzers. Hierüber lassen sich neue Statistiken einfach überprüfen. Da SPA nicht die Datenbankinhalte verändert, besteht keine Gefahr, dass bei der Überprüfung der Produktionsumgebung deren Leistung reduziert wird. Die folgenden Schritte müssen durchgeführt werden:

  • 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, die unterschiedliche Lastsituationen repräsentieren.
  • Die neuen Statistiken werden im Pending Mode aufgezeichnet.
  • Nun wird der SPA Workflow „Optimizer Statistics“ in der Produktionsumgebung ausgeführt.
  • Mithilfe des SPA Reports werden die SQL-Regressionen identifiziert.
  • Die betreffenden SQL-Anweisungen werden nun optimiert. Hierbei bietet der Tuning Advisor zusätzliche Einblicke bezüglich SQL-Profile, neuer Indizes oder neu angelegter Statistiken. Wenn diese Maßnahmen keine sinnvollen Ergebnisse liefern, so kann der alte Plan in das SQL Plan Management eingefügt werden.
  • Nach der Optimierung werden die SPA-Tests erneut ausgeführt. Hierbei sollte stets nur ein Optimierungsschritt – und nicht mehrere Schritte – zwischen zwei Prüfungen durchgeführt werden. So lassen sich im Fehlerfall 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 Tuningaufgaben in Einzelschritte mit nachfolgender Validierung vereinfachen sich in diesen Fällen die Analyseaktivitäten.
  • Die Tuningratschläge sind zu implementieren und die betreffenden SPA-Tests auszuführen, bis alle SQL-Wiederholungen in einem iterativen Prozess aufgelöst sind.
  • Im Rahmen der Optimierung ist stets zu prüfen, ob nicht an anderer Stelle durch die Veränderungen Leistungseinbußen entstanden sind. Wenn am Ende alle Anforderungen erfüllt sind und alle Optimierungspotenziale genutzt wurden, so kann die neue Statistik veröffentlicht werden.

Ergebnisse: Durch die Maßnahmen ist es gelungen, die SQL-Anweisungen zu optimieren und auf dieser Basis neue Statistiken zu etablieren. So können negative Folgen auf businesskritische Systeme aufgrund veralteter Statistiken ausgeschlossen werden.

Schlussfolgerungen

Die Gewährleistung von Qualität und Leistung auf Unternehmensanwendungen erfordert die Etablierung eines umfassenden Qualitätsmanagements. Dies bedeutet auch, umfassende Prüfungen auf allen Ebenen vor der eigentlichen Überführung in die Produktion vorzunehmen. Hierbei sind Anwendungs- und Infrastrukturtests sowohl bei Neuentwicklungen als auch bei Updates durchzuführen. Umfassende Tests auf hohem Niveau müssen hierbei auch die realen Betriebsbedingungen berücksichtigen können, damit deren Aussagen eine gute Basis für die Entscheidung darstellen, ob eine Anwendung für die Produktion freigegeben werden kann. Um die Effizienz zu maximieren, ist es wichtig, auf ein effektives Testframework zurückgreifen zu können: Hierüber lassen sich Tests sinnvoll planen, verwalten und auch automatisiert ausführen.
Der Oracle Enterprise Manager bietet ein umfassendes Set von Qualitätsmanagementlösungen, wie die Application Testing Suite, das Real Application Testing und das Data Masking Pack. Diese Oracle-Testtools sind vor allem auf das Oracle-Datenbankumfeld abgestimmt und liefern wichtige Informationen, die mit anderen Testwerkzeugen entweder gar nicht oder nur mit erheblich höherem Aufwand zu ermitteln wären. Ferner ermöglichen die Werkzeuge qualitativ hochwertige und sichere Tests mit geringem Umgebungsrisiko beziehungsweise geringem Risiko ungewollter Änderungen bei den Anwendungen.

Real Application Testing hat sich schon vielfach in verschiedenen Testkonstellationen bewährt. Steht ein geplanter Wechsel oder das Einspielen neuer Patches an, wird Real Application Testing bei performancekritischen Anwendungen eingesetzt. So können Probleme frühzeitig aufgedeckt und gelöst werden. Weitere Einsatzgebiete sind Tests beim Plattformwechsel oder einige Lasttests. Bemerkenswert ist, dass – trotz der umfangreichen und detaillierten Testergebnisse im Datenbankumfeld – keine aufwändigen und komplizierten Testvorbereitungen und Testspezifikationen durchzuführen sind.

Aus diesen Gründen sollten sich Entwickler und Testingenieure mit den Oracle-Testtools vertraut machen, sofern Oracle-Datenbanken in der betreffenden Umgebung eingesetzt werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -