oracle real application testing solution test oracle db before moving production
Wir sind zum letzten Teil des Reihe von Oracle-Datenbanktests.
Bisher haben wir uns damit befasst Methoden zum Testen der Oracle-Datenbank. Wenn wir diesen Fokus fortsetzen, werden wir uns mit weiteren Details in Bezug auf Oracle Real Application Testing befassen.
Heute lernen wir Oracle Real Application Testing kennen - ein effektives Änderungssicherungssystem, das die Systemänderung in der Testumgebung selbst bewertet, bevor es in die Produktion eingeführt wird.
Dies ist die führende Lösung von Oracle, um die DB-Workload der realen Produktionsumgebung zu erfassen und auf t zu ersetzen ist Umwelt .
Wie bereits mehrfach erwähnt, müssen wir immer sicherstellen, dass wir die Datenbank in jeder möglichen Dimension testen, um Instabilitäten zu beseitigen und um sicherzustellen, dass in unserer Produktionsinstanz keine unvorhergesehenen Probleme auftreten.
Wir können kategorisieren Testen von Oracle Real-Anwendungen in zwei große Abschnitte:
- SQL Performance Analyzer
- Datenbankwiedergabe
Bevor wir fortfahren, beachten Sie bitte, dass für SQL Performance Analyzer und Database Replay eine zusätzliche Lizenz erforderlich ist, d. H., Die gegen eine zusätzliche Gebühr und eine Enterprise Edition-Option erhältlich ist.
Was du lernen wirst:
SQL Performance Analyzer
Die GUI, die für den Zugriff auf SQL Performance Analyzer und die Datenbankwiedergabe verwendet wird, ist Enterprise Manager (siehe unten):
Um auf SQL Performance Analyzer zuzugreifen, klicken Sie einfach auf den Link „SQL Performance Analyzer“
(Klicken Sie auf das Bild, um es vergrößert anzuzeigen.)
Mit SQL Performance Analyzer können wir die Auswirkungen von Änderungen am System auf die Leistung messen, die sich auf die Ausführung und Leistung von SQL auswirken können.
Sie sind äußerst nützlich in Fällen wie:
- Datenbank-Upgrade, Patches
- Konfigurationsänderungen am Betriebssystem - Software oder Hardware
- Änderungen der Oracle Optimizer-Statistik
- Benutzer- / Schemaänderungen
Es wird immer empfohlen, die SQL-Leistungsanalyse für einen Test oder einen Test auszuführen UAT (User Application Testing) System anstatt auf einem Produktionssystem. Da wir beim Testen der Auswirkungen der Leistungsänderung versehentlich die Benutzer beeinflussen könnten, die in der Produktionsinstanz ausgeführt werden. Durch Ausführen eines Tests wird außerdem sichergestellt, dass derzeit keine laufenden Prozesse in der Produktion manipuliert werden.
ZU Die grundlegende Übersicht über einen SQL Performance Analyzer-Workflow ist unten dargestellt:
Die SQL-Leistungsanalyse umfasst die folgenden Schritte.
Schritt 1)SQL-Workload erfassen
Bestimmen Sie die SQL-Anweisungen, die Teil Ihrer SQL-Workload sind, aus Ihrer Produktionsinstanz, die Sie analysieren möchten. Diese Arbeitslast sollte idealerweise die Arbeitslast darstellen, die Sie möglicherweise in Ihrer Produktion haben.
Wir erfassen diese Anweisungen in einem SQL-Optimierungssatz und geben diesen SQL-Optimierungssatz an den SQL Performance Analyzer weiter.
Da der Analyzer viele Ressourcen auf Ihrem System verbraucht, empfehlen wir immer, sie auf einem Test- oder UAT-System ausführen zu lassen. Um es auf einem Testsystem auszuführen, müssten wir den SQL Tuning-Satz, den wir bereits in der Produktion erstellt haben, in das Testsystem exportieren.
Schritt 2)Erstellen einer SQL Performance Analyzer-Aufgabe
Um den Analyzer auszuführen, müssen Sie zuerst eine SQL Performance Analyzer-Aufgabe erstellen. Diese Aufgabe ist nichts anderes als ein Repository, das alle Daten zur Analyse konsolidiert, die vom SQL Performance Analyzer ausgeführt werden. Wie bereits erwähnt, wird das SQL-Tuning-Set dem Analysator als Stimulans zugeführt.
Was ist ein Datenerfassungstool?
Schritt 3)SQL-Leistungsprüfung vor dem Ändern
Nachdem wir die SQL Performance Analyzer-Task und das SQL Tuning Set erstellt haben, müssen wir die Infrastruktur auf dem Testsystem aufbauen.
Bitte beachten Sie, dass wir, wenn wir ein System zum Testen verwenden möchten, sicherstellen müssen, dass es dem Produktionssystem in Bezug auf Hardware, Software und Speicher sehr ähnlich ist, damit wir eine ähnliche Umgebung replizieren können.
Sobald das Testsystem entsprechend konfiguriert ist, können wir die Voränderungsversion der Daten mit SQL Performance Analyzer erstellen.
Dies kann mithilfe von Enterprise Manager oder APIs (integrierte Verfahren) erreicht werden.
Schritt 4)SQL-Leistungstest nach Änderung
Der Post-Change-Test wird auf dem Testsystem durchgeführt, nachdem einige Änderungen am System vorgenommen wurden.
Sobald dies abgeschlossen ist, hätten wir zwei SQL-Versuche - einen Test vor und nach dem Wechsel zum Vergleich.
Ähnlich wie bei der SQL-Leistungsprüfung vor der Änderung können wir die SQL-Leistungsprüfung nach der Änderung mithilfe von Enterprise Manager oder APIs (integrierte Prozeduren) erstellen.
Schritt 5)Bericht erstellen
Nach dem Ausführen der Tests vor und nach dem Wechsel können die darin gesammelten Leistungsdaten verglichen werden, indem eine Vergleichsanalyse mit SQL Performance Analyzer ausgeführt wird.
Sobald diese Vergleichsaufgabe abgeschlossen ist, können wir einen Bericht erstellen, um die Leistung der SQL-Anweisung zu ermitteln, die Teil der Arbeitslast war, die wir testen wollten.
Durch Überprüfung des Berichts können wir die Leistung von SQL beurteilen und Schlussfolgerungen ziehen
Anweisungen und stellen Sie dann die Systemänderungen in der Produktion bereit.
Ebenso können wir verschiedene Workloads mit verschiedenen Systemänderungen testen und sicherstellen, dass wir jeden einzelnen testen, bevor wir sie in der Produktion implementieren.
Der oben dargestellte Workflow kann wie unten dargestellt grafisch dargestellt werden.
Datenbankwiedergabe
So führen Sie das Tool über Enterprise Manager aus:
(Klicken Sie auf das Bild, um es vergrößert anzuzeigen.)
Die Datenbankwiedergabe ermöglicht ein realistisches Testen von Systemänderungen, indem Ihre Produktionsumgebung im Wesentlichen auf einem Testsystem repliziert wird. Dazu wird eine gewünschte Arbeitslast auf dem Produktionssystem erfasst und auf einem Testsystem mit den genauen Ressourcenmerkmalen der ursprünglichen Arbeitslast wie SQL-Ausführung, Transaktionen, Extrakten und Prozeduren wiedergegeben.
Dies wird durchgeführt, um sicherzustellen, dass wir alle möglichen Auswirkungen von Änderungen berücksichtigen, einschließlich unerwünschter Ergebnisse wie Produktfehler, unangemessene Ergebnisse oder Leistungsregressionen.
Umfangreiche Analysen und Berichte helfen auch dabei, potenzielle Probleme zu identifizieren, wie z. B. fehlerhafte Umstände und Leistungsunterschiede.
Infolgedessen können Unternehmen im Umgang mit Änderungen sicher sein und den Gesamterfolg des Systemwechsels lukrativ beurteilen. Dies wird das Risiko erheblich reduzieren, wenn wir die Änderungen in der Produktion umsetzen möchten. Änderungen sind unvermeidlich und wenn wir sicherstellen, dass wir jeden Aspekt dieser Änderung von allen Stufen aus testen, wird die Produktion robuster und stabiler.
Ein grundlegender Workflow für die Datenbankwiedergabe sieht wie folgt aus:
Von der Datenbankwiedergabe unterstützte Änderungen sind:
- Oracle-Datenbank-Upgrades, Software-Patches
- Benutzer / Schema, Datenbankinstanz Parameter wie Speicher, E / A.
- Hardware- / Softwareänderungen an RAC-Knoten (Real Application Cluster)
- Betriebssystemänderungen, Betriebssystem-Patches
- CPU, Speicher, Speicher
Mit Database Replay können wir verschiedene Auswirkungen möglicher Änderungen am System testen, indem wir die praktische Belastung eines tatsächlichen Produktionssystems auf einem Testsystem wiedergeben, bevor es dem ersteren ausgesetzt wird. Die Arbeitsbelastung in der Produktion wird über einen quantitativ festgelegten Zeitraum überwacht, analysiert und aufgezeichnet. Diese Daten werden im Laufe der Zeit aufgezeichnet und zur Wiedergabe der Arbeitslast auf Testsystemen verwendet.
Auf diese Weise können wir die Auswirkungen der Arbeitslast erfolgreich testen, bevor wir Änderungen implementieren, die sich nachteilig auf die Produktion auswirken könnten.
Der Workflow ist wie folgt:
Schritt 1) Workload-Erfassung
Wir zeichnen alle Anfragen von Kunden in Dateien auf, die als 'Capture-Dateien' im Dateisystem (Speicher) bezeichnet werden. Diese Dateien enthalten alle wichtigen Informationen zu den Clientanforderungen wie SQL, Bindungen, Prozeduren und Transaktionsinformationen. Diese Dateien können dann in jedes System exportiert werden, falls wir sie auf einem anderen System wiedergeben möchten.
Schritt 2)Workload-Vorverarbeitung
Nachdem wir die Informationen in den „Capture-Dateien“ erfasst haben, müssen wir sie vorverarbeiten. In diesem Schritt erstellen wir Metadaten, die eine Beschreibung aller Daten enthalten, die für die Wiedergabe der Arbeitslast erforderlich sind.
Da dieser Schritt eine große Menge an Ressourcen aus dem System verbraucht, wird empfohlen, neben der Produktion auf einem anderen System zu arbeiten, auf dem die Last wiedergegeben werden kann. Falls Sie kein anderes System zum Testen haben und diese in der Produktion ausführen möchten, stellen Sie sicher, dass Sie sie außerhalb der Stoßzeiten ausführen, damit die Benutzer und Prozesse, die in der Produktion ausgeführt werden, nicht betroffen sind.
Schritt 3)Workload-Wiedergabe
Jetzt können wir sie auf dem Testsystem wiedergeben. Zu diesem Zeitpunkt spielen wir alle Transaktionen, Kontexte, Prozeduren und SQLs ab, die ursprünglich während der Erfassungsphase erfasst wurden, und sammeln Daten, während jeder Prozess diesen Übergang durchläuft.
Schritt 4)Berichte erstellen
Ähnlich wie beim Performance Analyzer können Sie auch Berichte erstellen und anzeigen, um jeden der von Ihnen ausgeführten Tests zu vergleichen.
Abschließend bieten wir einige kurze Tipps zum Testen der Datenbankwiedergabe:
- Verwenden Sie nach Möglichkeit ein identisches Testsystem
- Testen Sie jeweils eine Änderung, um die Auswirkungen zu verstehen
- Stellen Sie sicher, dass Sie mit den Standardwiedergabeoptionen beginnen und gegebenenfalls Änderungen vornehmen, die Ihren Anforderungen entsprechen.
- Vergewissern Sie sich vor der zweiten Wiedergabe, dass Sie alle Testaspekte verstanden haben
- Stellen Sie sicher, dass Sie Ihre Testergebnisse speichern und alle erforderlichen Änderungen / Testaktionen dokumentieren
- Stellen Sie sicher, dass während eines der Testläufe keine andere Arbeitslast oder Benutzer das System verwenden
Fazit:
Stellen Sie bei verschiedenen Aspekten und verschiedenen Methoden des Oracle-Datenbank- und Anwendungstests immer sicher, dass Sie so häufig und so gründlich wie möglich testen. Verstehen Sie die Anwendung und die Benutzerumgebung, bevor Sie Änderungen vornehmen oder neue Parameter in die Produktion einführen.
Literatur-Empfehlungen
- Beste Software-Test-Tools 2021 (QA Test Automation Tools)
- Unterschied zwischen Desktop-, Client Server-Tests und Web-Tests
- So testen Sie die Oracle-Datenbank
- Testhandbuch für die Sicherheit von Webanwendungen
- Anwendungstests - Grundlagen des Softwaretests!
- Installieren Sie Ihre Anwendung auf dem Gerät und starten Sie den Test von Eclipse aus
- Testen von Primer eBook Download
- Tutorial für zerstörende Tests und zerstörungsfreie Tests