Menu

Testing mit Oracle Database Replay - so funktioniert's

Von: Ulrike Schwinn

In letzter Zeit häufen sich bei mir Anfragen zum Thema Oracle Real Application Testing. Zahlreiche Gründe wie beispielsweise Einführung von Multitenant, die Änderung des zugrundeliegenden Betriebssystems, Wechsel der gesamten Server Plattform wegen Anschaffung neuer Hardware spielen dabei eine Rolle - und besonders natürlich auch bei einem Wechsel in die Cloud. Dabei ist es natürlich immer besser den eigenen Workload testen können statt mit einem synthetischen Workloadgenerator wie zum Beispiel dem Oracle Swingbench zu arbeiten.

Generell ist allerdings zu beachten: Zieht man den Einsatz von Real Aplication Testing in Betracht sollte es dabei immer um eine Einschätzung des Workload Verhaltens innerhalb der Oracle Datenbank gehen. Komponenten wie Application Server, verwendete Middleware oder Client Software können nämlich beim Testen mit Real Application Testing nicht berücksichtigt werden.

Schon vor Jahren haben wir einige Blogsposts und ein Dojo zu dem Thema verfasst - die Links dazu finden sich am Ende dieses Artikels. Obwohl schon viele Projekte mit Real Application Testing durchgeführt worden sind, gibt es immer noch viele Kunden, die noch nie etwas von Real Application Testing gehört haben. Und als vor einigen Wochen ein Kunde zu mir sagte: "Real Application Testing ist ein cooles Oracle Feature, warum haben wir noch nie etwas davon gehört", habe ich mich entschlossen noch einmal einen Überblicksartikel über die Technologie zu geben und den Ablauf beispielhaft zu skizzieren.

Bei Real Application Testing handelt es sich – ganz einfach formuliert – um ein Werkzeug für die Datenbank, das einen Workload aufzeichnen und in einer Testumgebung wieder abspielen kann. Der Ausdruck Werkzeug ist dabei etwas irrefü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 Oracle Enterprise Manager oder PL/SQL beziehungsweise SQL-Aufrufe. Keine weitere Installation oder spezielles Skripting ist erforderlich. Wie bei Partitionierung, Komprimierung, Edition Based Redefinition und andere Techniken in der Oracle Datenbank steht Oracle Real Application Testing out-of-the-Box in jeder Oracle Datenbank Installation zur Verfügung und ist sogar in den Oracle Database Cloud Umgebungen kostenfrei verwendbar.

Grundsätzlich gibt es Real Application Testing in den zwei Ausprägungen - Database Replay (kurz DB Replay) und SQL Performance Analyzer (kurz SPA). Beide können unabhängig voneinander verwendet werden, sind allerdings auch eine gute Ergänzung. So kann es sinnvoll sein, zuerst die SQL Performance mit SPA zu überprüfen und danach erst den gesamten Workload mit DB Replay unter Berücksichtigung aller konkurrierenden Zugriffe zu testen. Oder auch umgekehrt: bei der Aufzeichnung von DB Replay den SQL Workload mitaufzuzeichnen und danach separat mit SPA zu evaluieren und zu tunen.

Die Durchführung von DB Replay erfolgt dabei grundsätzlich in 3 Schritten:

  • der Aufzeichnung (auch Capture) im Produktivsystem
  • dem einmaligen Processing (auf dem Ziel(Test) Server)
  • und den Replays auf dem Testsystem mit der zugehörigen Auswertung der Reports.

Die Idee dabei ist, nicht nur einen einzigen Replay durchzuführen, sondern pro Änderung auf dem Testsystem weitere Replays zu generieren, die dann miteinander verglichen werden können. Capture/Replay Vergleiche sollen im Wesentlichen nur dazu dienen, die generelle Machbarkeit zu verifizieren. Für ein "hartes" Performance Benchmarking ist es erforderlich, Replays auf den zu evaluierenden Konfigurationen/Plattformen zu vergleichen.

Zur Ausführung kann entweder die graphische Oberfläche über Enterprise Manager Cloud Control oder der Linemode mit PL/SQL Packages verwendet werden. Die Infrastruktur für DB Replay besteht dabei hauptsächlich aus den beiden Packages DBMS_WORKLKOAD_CAPTURE und DBMS_WORKLOAD_REPLAY sowie die zugehörigen Data Dictionary Views und einer Client Software WRC - verfügbar in der Oracle Datenbank Software oder auch separat als Instant Client von OTN downloadbar. Die vollständige Funktionalität der Packages und Data Dictionary Views lässt sich im Handbuch (hier 19c) in den entsprechenden Kapiteln nachlesen unter:

Über die Jahre gab es immer wieder einige interessante Erweiterungen in DB Replay. So ist es beispielsweise möglich einen Capture und Replay in einer Pluggable Database durchzuführen. Auch ist es möglich die Replay Dateien verschlüsselt abzulegen. In folgenden Abschnitten wird ein exemplarischer Ablauf an einem einfachen Beispiel skizziert um den generellen Umgang mit DB Replay vorzustellen. Weitere Funktionen können in den Beschreibungen nachgelesen werden.

1. Schritt: Die Aufzeichnung (Capture)

Auf dem Capture System wird eine Aufzeichnung in ein leeres logisches Verzeichnis (Directory) der Datenbank durchgeführt. Das Capture ist dabei ein Prozess, der nur wenig Overhead auf dem Cature System erzeugt. Das Capture sollte nicht zu lange dauern, ein Workload von circa ein bis zwei Stunden ist eine gute Empfehlung. Prinzipiell besteht die Möglichkeit einen Filter zum Beispiel nach User, Instance Id oder Services zu setzen, damit nicht alle Operationen aufgezeichnet werden und man weniger Capture-Dateien erhält. Typische Filter schliessen beispielsweise Enterprise Manager und RMAN Aktivitäten aus. Capture Filter können dabei ein- oder ausgeschlossen werden. Ob ein Filter als INCLUSION oder EXCLUSION Filter verwendet wird, wird dann beim Capture Start festgelegt.

Filtering ist optional und gilt auch nur für die aktuelle Aufzeichnung. Die Überprüfung kann über die View DBA_WORKLOAD_FILTERS erfolgen. Übrigens kann man auch im Nachhinein beim REPLAY spezielle Filter verwenden um nur einen Teil der Aufzeichnung abzuspielen. Typische Beispiele für Filter wären dann ... 

execute DBMS_WORKLOAD_CAPTURE.ADD_FILTER(fname=>'ORACLE MANAGEMENT SERVICE (DEFAULT)', fattribute=>'Program', fvalue=>'OMS');
execute DBMS_WORKLOAD_CAPTURE.ADD_FILTER(fname=>'ORACLE MANAGEMENT AGENT (DEFAULT), fattribute=>'Program', fvalue=>'emagent%');
execute DBMS_WORKLOAD_CAPTURE.ADD_FILTER(fname=>'M_RMAN', fattribute=>'Module', fvalue=>'rman%');

Danach kann das Aufzeichnen mit einem einzigen Aufruf iniitiert werden. Es gibt bestimmte Restriktionen bzgl. der Kommandos, die aufgezeichnet werden. Diese sollte man vorab im Handbuch überprüfen. Die Abhängigkeit von externen Services wie Database Links, Webservices usw. muss ebenfalls berücksichtigt und abgeklärt werden. Starten Sie ausserdem den Capture bei geringer Last um möglichst wenige In Flight-Transaktionen zu erhalten. Am besten wäre natürlich die Möglichkeit die Datenbank herunterzufahren, was in den meisten Umgebungen allerdings keine Option darstellt. 

 
execute DBMS_WORKLOAD_CAPTURE.START_CAPTURE(name=>'&capturename', dir=>'CAPDIR', default_action=>'EXCLUDE');

Das Argument DEFAULT_ACTION (INCLUDE oder EXCLUDE) gibt beim Aufruf an, ob Capture Workloadfilter (falls vorhanden) als INCLUSION oder EXCLUSION Filter verwendet werden. Die Verwendung von EXCLUDE bedeutet in unserem Fall, dass die drei Filter als EXCLUSION Filter angewendet werden d.h. OMS, EMAGENT und RMAN Operation nicht aufgezeichnet werden. Das logische Directory CAPDIR muss leer sein und über ausreichend Platz verfügen, um die aufgezeichneten Dateien zu speichern. Wenn keine Zeitspanne beim Aufruf angegeben wurde- wie in unserem Fall, wird der Capture folgendermassen beendet: 

 execute DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE()

Die Capture-Dateien sind dabei binär und unabhängig vom Betriebssystem, so dass der Test auf unterschiedlichen Plattformen möglich ist. Während eines Workload-Captures werden dabei eine Vielzahl von Informationen wie Connections Strings, SQL-Text und Bind Values gespeichert. Möchte man diese Informationen verschlüsselt ablegen, kann dies während des Captures zusätzlich über den Parameter ENCRYPTION angegeben werden.

Zur letzten Aktion auf dem Capture System gehört dann der Export des zugehörigen AWR Snapshots. Damit werden auch noch die Performance Daten im Capture Directory gespeichert. 

-- Auslesen von Capture Id und AWR Export Status aus DBA_WORKLOAD_CAPTURES
-- danach Export 
execute DBMS_WORKLOAD_CAPTURE.EXPORT_AWR(capture_id =>'CAPDIR')

Danach werden alle Dateien aus dem Directory CAPDIR auf das Testsystem kopiert.

Zur Beurteilung des Capture Laufs kann man einerseits die View DBA_WORKLOAD_CAPTURES abfragen - übrigens ist dies schon während des Captures möglich - oder einen Report mit der DBMS_WORKLOAD_CAPTURE.REPORT Funktion generieren. Es werden dabei interessante Informationen über die Charakteristiken des Captures wie zum Beispiel Dauer und Größe, Anzahl User Calls und Transaktionen etc. ausgegeben. 

SQL> SELECT id, start_scn, status, errors, awr_exported, dbtime_total,
            transactions_total, capture_size/1024/1024 CAPSIZE_MB, user_calls_total, user_calls_unreplayable 
     FROM dba_workload_captures; 

  ID START_SCN      STATUS      ERRORS AWR_EXPORTED DBTIME_TOTAL TRANSACTIONS_TOTAL CAPSIZE_MB USER_CALLS_TOTAL USER_CALLS_UNREPLAYABLE 
---- -------------- --------- -------- ------------ ------------ ------------------ ---------- ---------------- -----------------------
  23 13821838964905 COMPLETED    28833 YES           53929939800             386655 1275.49682 8563239          432574

Ein Capture Report über die Funktion REPORT steht dabei in TEXT- oder HTML-Format zur Verfügung. 

set pagesize 0 long 30000000 longchunksize 1000
select DBMS_WORKLOAD_CAPTURE.REPORT(capture_id=>&id, format=>'TEXT') from dual;

--Ausgabe
Database Capture Report For ORCL

DB Name         DB Id    Release     RAC Capture Name               Status
------------ ----------- ----------- --- -------------------------- ----------
ORCL          1258625022 11.2.0.3.0  NO  T_TEST                   COMPLETED


                   Start time: 15-Jan-19 12:39:26 (SCN = 310491322)
                     End time: 15-Jan-19 13:10:56 (SCN = 310494735)
                     Duration: 31 minutes 30 seconds
                 Capture size: 82.82 KB
             Directory object: RAT
               Directory path: /home/oracle/rat_test1
      Directory shared in RAC: TRUE
                 Filters used: 4 EXCLUSION filters

Captured Workload Statistics                      DB: ORCL  Snaps: 45621-45622
-> 'Value' represents the corresponding statistic aggregated
      across the entire captured database workload.
...

Die Capture Skripte sind hier zum Download.

2. Schritt: Das Processing der Capture Dateien

Im zweiten Schritt muss ein Processing der Capture Dateien in Vorbereitung für das Replay durchgeführt werden. Diese Operation transformiert die Capture Daten in ein abspielbares Format. Sie ist ein einmalig und muss auf dem Zielsystem erfolgen. 

execute DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE(capture_dir => '&dir');

Das Processing Skript kann hier geladen werden .

3. Schritt: Das Abspielen (Replay)

Um einen Replay durchzuführen, ist zuvor die Erstellung eines Testsystems nötig. Wichtig ist dabei, dass die Datenbank auf dem Capture und Replay System den gleichen Konsistenzzustand haben. Verwenden kann man dazu RMAN, Data Guard, Flashback Database, Snapshot Standby, Data Pump usw. Flashback Database in Kombination mit einem sogenannten "Guaranteed Restore Point" ist beispielsweise eine einfache Möglichkeit die Datenbank wieder schnell zurückzusetzen.

Nun kann der Replay initialisiert werden. Dazu wird ein Replay Name vergeben und das Directory, in dem sich die kopierten Daten aus der Aufzeichnung befinden, bekanntgegeben. 

execute DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY(replay_name=>'&Replay_name', replay_dir=>'&DIR');

Danach wird mit einem Prepare Kommando, die Charakteristik des Replays festgelegt. Das Replay kann in Oracle Database 19c in den unterschiedlichen Synchronisierungvarianten TIME und SCN ablaufen. Die Synchronisierung TIME (clock based) in Oracle Database 19c basiert dabei auf der Zeit, in der die Aktion während des Captures stattgefunden hat. Die Synchronisierung SCN (Defaulteinstellung) hingegen basiert auf der Commit Zeit während des Captures; die Commit-Reihenfolge bleibt hierbei erhalten. Genaueres kann man dazu im Handbuch erfahren.
Hinweis: Die Parameter und die Defaultwerte für die Synchronisierung sind dabei je nach Datenbank Release unterschiedlich. Bitte konsultieren Sie das entsprechende Handbuch für die passende Einstellung.
Möchte man gleichzeitig dazu ein SQL Tuning Set mitaufzeichnen, kann dies über den Parameter CAPTURE_STS festgelegt werden. 

execute DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY(synchronization => 'TIME', capture_sts => TRUE);

Wie sieht es mit einer Skalierung des Ablaufs aus? Lässt sich das Timing verändern bzw die Statement Ausführung erhöhen? Weitere Parameter wie CONNECT_TIME_SCALE (Default 100) und THINK_TIME_SCALE (Default 100) sind für die Skalierung von Connection beziehungsweise Think Time zuständig. Über eine Verringerung dieser Parameter kann der aufgezeichnete Workload dann mit unterschiedlicher „Geschwindigkeit“ ablaufen. Ausserdem kann der Parameter SCALE_UP_MULTIPLIER zur Erhöhung der Statement Ausführung (natürlich nur SELECT Kommandos) verwendet werden.

Nun sind alle Vorbereitungen getroffen und die Clients(WRC) werden gestartet - entweder auf dem Server selbst oder auf einer zusätzlichen Client Maschine. Die WRC Software findet sich entweder im $ORACLE_HOME/bin oder kann als Instant Client Software von OTN geladen werden. 

[oracle@by19c ~]$ wrc help=yes
Workload Replay Client: Release 19.3.0.0.0 - Production on Tue Apr 21 08:31:52 2020
Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

FORMAT:
=======
  wrc [user/password[@server]] [MODE=mode-value] KEYWORD=value
Examples:
=========
  wrc  REPLAYDIR=.
  wrc  scott/tiger@myserver REPLAYDIR=.
  wrc  MODE=calibrate REPLAYDIR=./capture
The default privileged user is: system

Mode:
=====
wrc can work in different modes to provide additional functionalities.
The default MODE is REPLAY.

Mode        Description
----------------------------------------------------------------
REPLAY          Default mode that replays the workload in REPLAYDIR
VERSION         Print the wrc version
CALIBRATE       Estimate the number of replay clients and CPUs
                needed to replay the workload in REPLAYDIR
...

Um Auskunft über die Anzahl der Clients zu erhalten, bietet sich die Nutzung des WRC Programms selbst oder die Durchführung der Funktion DBMS_WORKLOAD_REPLAY.CALIBRATE an. 

wrc user/password@ replaydir= mode=calibrate

Danach erfolgt der Start der Workload Replay Clients. 

wrc user/password@ replaydir= mode=REPLAY
wrc ...
wrc ...

Nun kann der Replay durchgeführt werden. Die View DBA_WORKLOAD_REPLAYS gibt dabei zu jeder Zeit Auskunft über den Stand des Replays. 

execute DBMS_WORKLOAD_REPLAY.START_REPLAY();

Nachdem der Replay beendet ist, kann mit den Auswertungen begonnen werden.

Skripte für den Replay finden sich hier zum Download.

4. Schritt: Die Auswertung

Erste Informationen zum Replay kann man ähnlich wie beim Capture über eine Data Dictionary View - hier DBA_WORKLOAD_REPLAYS - selektieren, die auch schon während des Laufs verwendet werden kann. Es gibt allerdings auch spezielle DB Replay Berichte und natürlich auch die Möglichkeit über einen zugehörigen AWR Report weitere Informationen zu erhalten. Alle Reports lassen sich im Linemode als TEXT- oder HTML-Format generieren. Besonders hervorzuheben sind dabei der Replay und der Compare Period Report, die bei der Auswertung hilfreich sind. Der Compare Period Report ist häufig sogar ausreichend um Schlüsse über die Machbarkeit und die Gesamtperformance zu ziehen. Eine nachgelagerte Analyse mit einem AWR Report bzw. einem AWR Difference Report bestätigt in der Regel die Ergebnisse aus dem Compare Period Report und kann noch weitere Details zur Performance geben.

Normalerweise startet man mit dem Replay Report. Dieser gibt Informationen zu den Einstellungen des Replay Laufs (wie z.B. Synchronisation, Skalierung etc.), Replay Statistiken (wie Anzahl User Calls und DB Time), Top-Events, Workload-Profile und Divergenzen. Eine grosse Anzahl von Divergenzen können auf grobe Verstöße und Probleme beim Abspielen hinweisen und sollten weiter untersucht und beseitigt werden. Ein Replay Report kann folgendermassen erzeugt werden. 

set pagesize 0 long 30000000 longchunksize 1000
col tt format a120
select DBMS_WORKLOAD_REPLAY.REPORT(replay_id=>&replayid, format=>'HTML') tt from dual;

Folgendes Beispiel zeigt einen kurzen Ausschnitt aus einem Replay Report.

Eine weitergehende Analyse kann nun mit dem Compare Period Report durchgeführt werden. Voraussetzung ist dabei der Import des Capture AWRs mit der Funktion IMPORT_AWR, die die Capture Id und ein Staging Schema benötigt. 

DECLARE 
 dbid NUMBER; 
 BEGIN 
  dbid := DBMS_WORKLOAD_REPLAY.IMPORT_AWR(CAPTURE_ID=>&captureid, STAGING_SCHEMA =>'&schema');
END;
/

Der Compare Period Report liefert nun einen guten Überblick über die Gesamtperformance im Vergleich (z.B. Capture mit Replay1, Replay1 mit Replay2 usw.) und gibt entscheidende Hinweise über die Performance-Unterschiede. Es werden Optimizer- und Memory-Einstellungen, wichtige Initialisierungsparameter, Performance-Statistiken und Top Statements miteinander verglichen und zusätzlich einige Hardware-Statistiken wie I/O- oder CPU-Nutzung ausgegeben. Zudem gibt er eine Bewertung zu den Divergenzen ab - LOW bedeutet dabei zum Beispiel vernachlässigbarer Divergenzanteil.

Ähnlich wie beim Replay Report wird das Package DBMS_WORRKLOAD_REPLAY dazu verwendet - hier mit der Funktion COMPARE_PERIOD_REPORT. Notwendig sind dabei die aktuelle Replay Id und die Vergleichs Replay Id. Falls wir den Capture mit dem Replay vergleichen ist die Replay Id NULL. 

variable ergebnis clob
begin
 DBMS_WORKLOAD_REPLAY.COMPARE_PERIOD_REPORT(
 replay_id1 => &replayid,
 replay_id2 => null,
 format     => 'HTML',
 result     => :ergebnis);
end;
/
set heading off set long 100000 set pagesize 0
spool comparereport.html rep
print ergebnis
spool off

Folgendes Beispiel zeigt einen kleinen Ausschnitt aus einem Compare Period Report.

Möchte man darüberhinaus noch weitere detaillierte Informationen über die einzelnen Performance-Metriken erhalten, kann man zum Schluss noch einen AWR Difference Report hinzuziehen oder einzelne AWR Reports generieren.

Skripte zur Generierung von DB Replay Reports finden sich hier zum Download.

Fazit

An dieser Stelle sollen noch einige Erfahrungen mit DB Replay und SPA geschildert werden, die wir in mehreren ausgewählten Projekten gemacht haben. Die Technologie wurde dabei für unterschiedlichste Zwecke wie Plattformwechsel, Migration, Upgrade, Architekturwechsel oder Patch-Test verwendet. Die Zeit zum Erstellen eines Testsystems mit Backup, Upgrade, Migration und die Wahl der Methode zum Zurücksetzen müssen natürlich bei der Planung der Tests immer berücksichtigt werden. Nach einer anfänglichen Lernkurve, um sich mit dem Werkzeug vertraut zu machen, wurde in jedem Projekt schnell deutlich, wie gering der Testaufwand mit Real Application Testing ist und welche Vorteile ein solcher Test hat. Er kann Sicherheit und Vertrauen für Migrationen/ Upgrade bringen, für ein besseres Verständnis der eigenen Applikationen sorgen oder auch die entscheidenden Argumente für einen Plattform- oder Architekturwechsel liefern. So ist Real Application Testing auch ein äusserst wertvolles Mittel beim anstehenden Wechsel in die Cloud.

Dieser Ablauf zeigt beispielhaft wie der rote Faden eines DB Replay Prozedere aussehen kann. Weitere Varianten der Skripte lassen sich aus dem Handbuch ableiten. Folgende Links können dazu hilfreich sein.

 

Zurück zur Community-Seite
 

Visit the Oracle Blog

 

Contact Us

Oracle

Integrated Cloud Applications & Platform Services