Der Vortrag zeigt auf, wie Risikominimierung bei Änderungen im Oracle Datenbank-Umfeld betrieben werden kann. Es wird ein allgemeiner Überblick über mögliche Änderungen gegeben, sowie auf das Werkzeug Real Application Testing eingegangen. Zudem werden Stolperfallen und mögliche Probleme aufgezeigt. Diesen Beitrag präsentierte OPITZ CONSULTING Berater Simon Dickmeiß im Rahmen der Special DOAG Interest Group Database am 12. Oktober 2010 in Frankfurt/Kaiserei.

1. DOAG SIG DatabaseReal Application Testing

2. Simon Dickmeiß, ConsultantOPITZ CONSULTING Gummersbach GmbH RisikominimierungbeiÄnderungen imOracle Datenbank-Umfeld Ein Vortrag beim Treffen der Special Interest Group Database der DOAG,Frankfurt/Kaiserlei, 12.Oktober 2010 Real Application Testing

4. Agenda Einführung Real Application Testing – Überblick Verfügbarkeit / Verwendung Gegenüberstellung von SQL Performance Analyzer und Database Replay Real Application Testing – Architektur Architektur / Workflows / Schnelleinstiegfür Database Replay und SQL Performance Analyzer Vorbereitungen zur Durchführung von Tests / Hinweise zur Benutzung Praxisbeispiel Zusammenfassung / Bewertung

5. Warum Software testen…? “A clever person solves a problem. A wise person avoids it.” Albert Einstein (1879-1955)

6. Änderung und Risiko 1

7. Grund für Veränderung …?! Neue Features Anforderung durch Produkte von Drittanbietern Bessere Performance und Skalierbarkeit Desupport der „alten“ Version Strategiewechsel, z. B. Plattform Kundenanforderung ... usw.

8. Änderungen im Oracle Datenbank-Umfeld Portierung / Migration von Applikationen Datenbank- / Datenmigration, Konvertierung, Upgrade Server-, Applikations- und RDBMS-Konsolidierung Wachstum (Größe der Datenbank) Workload steigt (Anzahl der Anwender) Neue Architektur (Verfügbarkeit) Installation von Patches Parameteränderungen … usw.

9. Business-Anforderungen Anforderungen: Schnelle Einführung neuer Technologien Niedrigere Kosten Ohne (geringe) Risiken für den Betrieb Höhere Testqualität Hemmnisse für Veränderungen: „Unmöglicher“ Auftrag „Never change a running system“-Attitude Hoher Testaufwand Unvorhersehbarkeit von Auswirkung und Risiko einer Änderung Sorge um die Stabilität der Applikation? Schlechte Erfahrungen in der Vergangenheit? Qualitative und umfassende Test sind zu kostenintensiv?

10. Änderungen vs. Anforderungen Anforderungen: Ununterbrochenen, sicheren, zuverlässigen Betrieb garantieren so viele Änderungen durchführen, wie es notwendig erscheint, um aktuelle und zukünftig erwartete Anforderung abzudecken so wenige Änderungen wie möglich durchführen, um den Umfang und das Risiko der Migration zu verringern alten Code so wenig wie möglich abändern, um Risiken zu minimieren alten Code soweit abändern, dass er die Migration unterstützt möglichst große Flexibilität ermöglichen, um zukünftige Änderungen zu erleichtern mögliche negative Auswirkungen der Änderungen minimieren den Nutzen moderner Technologien und Methoden maximieren

11. Mögliche Risiken Anwendung funktioniert gar nicht mit der neuen Plattform, Datenbank-Release etc. Teile der Anwendung funktionieren nicht. Performance ist deutlich schlechter, nicht-funktionale Anforderungen können nicht erfüllt werden. Ausfall des Systems … Testen!!!

12. Theorie: Ziel von Performancetests Was ist das Ziel von Performancetests? Mit der Durchführung von Performancetests soll sichergestellt werden, dass nicht-funktionale Anforderungen (wie z. B. Varianz von Antwortzeiten, Stabilität, Skalierbarkeit) an eine Kombination aus Software und Hardware von der gewählten Systemarchitektur erfüllt werden. Von besonderer Bedeutung sind Performancetests bei der Entwicklung von Individual-Software oder beim Einsatz neuer Technologien, da hier in der Regel keine Vorkenntnisse zum Performance-Verhalten vorliegen. Performance-Tests sollten als Bestandteil der QS / des QM verstanden werden.

13. Theorie: Arten von Tests „Performancetest“ Überprüfen, ob eine gewählte Systemarchitektur die nicht-funktionalen Anforderungen erfüllt „Lasttest“ oder „Stresstest“ Fehler aufdecken, die im funktional orientierten Systemtest/Integrationstest nicht gefunden wurden Erfüllung nicht-funktionaler Anforderungen für den Produktivbetrieb nachweisen, z. B. geforderte Antwortzeiten sowie Mengenverarbeitungen Überprüfen, wie eine Systemarchitektur auf eine ungeplante Überlast reagiert „Benchmark“ Vergleich von verschiedenen Systemarchitekturen in Hinblick auf die nicht-funktionalen Anforderungen

14. Kategorisierung von Werkzeugen

15. Ziel von Performancetests bei Änderungen Identifizierung der Performanceprobleme vordem Produktivgang Mögliche Probleme frühzeitig erkennen und beseitigen Architektur unter realistischen Bedingungen prüfen Leistungsfähigkeit des Systems ermitteln Zusammenspiel aller Komponenten testen Risiken minimieren!!!

16. Überblick – Real Application Testing 2

17. Überblick – Real Application Testing Neue Datenbankoption verfügbar nur mit Enterprise Edition Bestandteile: Database Replay (DB Replay) SQL Performance Analyzer (SPA) Funktionalität des SQL Tuning Set (STS) ist zwischen Real Application Testing Option und EM Tuning Pack geteilt Neue Funktionalitäten benötigten Packs: Diagnostic Pack für DB Replay Tuning Pack für SPA

18. Verfügbarkeit des Real Application Testing Verfügbarseit Oracle Database 11.1.0.6 Database Replay - Capturing verfügbarmit Patch-Sets 9.2.0.8, 10.2.0.4 / 5, 11.1.0.6 / 7, 11.2.0.1 (Für 10.2.0.4 muss der Parameter pre_11g_enable_capture gesetztwerden) SPA Capturing erhältlichalsEinzel-Patch für 9.2.0.x und 10.2.0.2 / 3 / 4 / 5 Replay nur in 11gR1 verfügbar Patchinformationen und KombinationenimMetalink: Real Application Testing Now Available for Earlier Releases (Doc ID 560977.1)

19. Verwendung des Real Application Testing Einfachster Weg DB Console 11.1 bzw. Grid Control 10.2.0.5 Database Replay Paket DBMS_WORKLOAD_CAPTURE Capture funktioniert in 9.2.0.8, 10.2.0.2/3/4/5 ,11.1.0.x und 11.2.0.x Paket DBMS_WORKLOAD_REPLAY Wiedergabe funktioniert in 11.1.0.x und11.2.0.x SQL Performance Analyzer (SPA) Paket DBMS_SQLTUNE und DBMS_SQLPA Sammeln von Statements in : 9.2.0.x und 10.1. 0.x mit sql tracing 10.2.0.2/3/4/5 ,11.1.0.x und 11.2.0.x aus dem cursor cache Auswertung und Vergleich funktioniert mit: 10.2.0.2/3/4/5 ,11.1.0.x und11.2.0.x

20. Zusammenfassung: SPA vs. DB Replay

21. Architektur 3

22. SQL Performance Analyzer – Architektur Import STS Erstellen von STS und Aufzeichnen der Statements Referenzausführung Erstellen der Staging Tabelle (DBMS_SQLTUNE.CREATE_STGTAB_SQLSET) Testsysten Produktionssystem Implementierung Änderung Analysieren Report Export der Tabelle SQL Text Bind Variable Ausführungspläne Ausführungsstatistik

23. Workflow des SQL Performance Analyzer Auf der Produktionsseite: Erstellen eines STS Exportieren des STS Auf der Testseite: Importieren des STS Aufruf von SPA für den ersten Test (auch trial) Aufruf von SPA für den zweiten Test nach Änderung Analyse gemäß Metriken und Ausführungsplänen Nutzung der vorgefertigten Workflows:

24. Architektur des Database Replay Preprocessing Workload Aufzeichung Replay Dateien & Metadaten Vorbereitung System Flashback Shutdown - Startup Restricted Produktionssystem Testsysten Initialisieren Replay Capture Start Replay Report Vorbereiten Unrestricted Workload Daten Bind-Variablen Zeitlicher Ablauf Abspielen Analysieren Capture Ende

25. Workflow des Database Replay Auf der Produktionsseite: Optional: Setzen eines Initialisierungsparameter für 10.2.0.4 Optional: Filter setzen Capture Start und Ende durchführen Exportieren des AWR (Diagnostics Pack erforderlich) Auf der Testseite: Captured Workload zur Verfügung stellen Preprocessing (einmalig) Optional: Current SCN für Flashback Database ermitteln Durchführen des Replays: Optional: Replay Filter setzen Kalibrieren und Ausführen der Testtreiber (Workload Replay Clients (WRC)) Analyse der Berichte (z. B. Fehler-, Datendivergenz- und Performanzdivergenz)

26. Capture Restriktionen des Database Replay Direct path load (imp/exp) MTS / Shared Server (funktioniert in 11.2) Oracle Streams und Advanced Replication (funktioniert in 11.2) Non-PL/SQL based AQ Flashback-Abfragen Verteile Transaktionen

27. Real Application Testing – 11gR2 New Features Exadata Simulation (ohne Hardware) Compare Period Report (übersichtlichere Vergleiche) Compare SQL Tuning Sets (Vergleich STS bei Capture/Replay) Synchronization Controls (Replay Filter, Concurrency) SPA Support für Active Data Guard Umgebung Database Replay SQL Performance Analyzer Integration Database Replay Timeout Funktion Database Replay Workload Analyzer

28. Database Replay – Step by Step (1) Optional: Filter setzen Bestehende Filter DBA_WORKLOAD_FILTERS begin dbms_workload_capture.add_filter ( fname => 'user_salapati', fattribute => 'USER', fvalue => 'salapati‘ ); end; / begin dbms_workload_capture.delete_filter( 'user_salapati'); end; /

29. Database Replay – Step by Step (2) create directory ratdir as '/oracle/ratdata/'; grant read, write on DIRECTORY ratdir to public; begin dbms_workload_capture.start_capture (name => '2008Jan', dir => ‘RATDIR', duration => NULL); end; / Capture Start Laufende Capture-Vorgänge DBA_WORKLOAD_CAPTURES Prüfen des Workloads DBMS_WORKLOAD_CAPTURE.GET_CAPTURE_INFO Ohne Duration DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE

30. Database Replay – Step by Step (3) Preprocessing begin dbms_workload_replay.process_capture (capture_dir => 'RATDIR'); end; / begin dbms_workload_replay.initialize_replay(replay_name => 'TADT01', replay_dir => 'RATDIR'); end; / begin dbms_workload_replay.prepare_replay(synchronization => true , think_time_scale=> 2); end;

31. Database Replay – Step by Step (4) wrc system/password mode=calibrate REPLAYDIR=. wrc system/password REPLAYDIR=. begin dbms_workload_replay.start_replay; end; / Durchführen des Replays Optional: Replay-Filter setzen Kalibrieren und Ausführen der Testtreiber (Workload Replay Clients (WRC)) Report über Replay DBMS_WORKLOAD_REPLAY.GET_REPLAY_INFO

32. Vorbereitungen zur Durchführung von Tests Testplan aufstellen und Fachbereich mit einbeziehen Installation der letzten Patches auf der Testplattform Bugs für Option und Plattform ausfindig machen Oracle 11gR2 Upgrade Companion (Note 785351.1) Für Oracle Applications wie z. B. EBS, Siebel, PSFT oder JDE sind gesonderte Patches erforderlich Note 463263.1: Für allgemeine Fehler beim Replay Note 760402.1: Für langsam laufende Skripte beim Database Replay

33. Vorbereitungen zur Durchführung von Tests (2) Für Capture ein separates I/O System verwenden Platzbedarf durch kurzen Test schätzen (Platzbedarf von Workload-Art abhängig, keine Faustformel) Den Anwendern Performanceeinbußen während Aufzeichnung mitteilen (von Workload-Art abhängig) Überprüfung auf externe Referenzen, die auf produktive Systeme verweisen (externe Tabellen, DB-Links etc.) Downtime für produktive Umgebung einplanen (Neustart) Synchronisation der Systemzeiten (Timestamp, Root) Nutzen des Advisors für die Replay Clients

34. Vorbereitungen zur Durchführung von Tests (3) Gleicher Characterset auf Testsystem Überprüfen auf invalide Objekte (Produktion und Test) Auf mögliche Beschränkungen prüfen Das Zieldatenbank-System muss inhaltlich auf den Status zum Beginn der Aufzeichnung hergestellt werden Es werden SYSDBA-Rechte benötigt Für Grid Control werden die Host-Zugangsdaten benötigt Nutzung von AWR nur bei lizensiertem Diagnostic Pack RAC Shared Filesystem für Aufzeichnung verwenden

35. Praxisbeispiel 4

36. Ausgangssituation Evaluierung von Database Replay Praxistauglichkeit in großer Landschaft Implementierung eines Workflows für eventuellen produktiven Einsatz Erstellung und Durchführung von Testszenarien Migration 10.2.0.4 auf 11.2.0.1 (AIX) Migration 10.2.0.4 auf 11.2.0.1 (Linux) Bewertung über Einsetzbarkeit und Nutzen

37. Ziele Prozess Database Replay beschreiben Prozess für Database Replay beschreiben Testaufbau, Testablauf, Testergebnisse Kosten/Nutzenanalyse Technische Rahmenbedingungen (Lizenzen u.a.) Mehrwert (Anwendungsfälle) Risikominimierung Stolperfallen erkennen

38. Testablauf für AIX und Linux Aufzeichnung OLTP und Batchläufe 1. Aufzeichnen 10.2.0.4 4. Database Replay 11.2.0.1 3. Database Replay 11.2.0.1 2. Upgrade 10.2.0.4 Sicherung 10.2.0.4 Upgrade von 10.2.0.4 auf 11.2.0.1 Sicherung 11.2.0.1 Flashback für erneutes Abspielen

39. Ergebnisse Erfolgreicher Test von Database Replay Migration 10.2.0.4 nach DB 11.2.0.1 (AIX) Erfolgreicher Test von Database Replay Migration 10.2.0.4 nach DB 11.2.0.1 (Linux) Performanceveränderungen, die durch die Migration bedingt sind, können gut abgeschätzt werden Einzelne Ausreißer können nur schlecht ausfindig gemacht werden Es können nur generelle Aussagen über Performance gemacht werden

40. Probleme Generierung des Berichts zum Capture Workload bricht bei den Statistiken mit einem ORA-01722 ab ORA-01722: Ungültige Zahl Continuing to Next Section ... (Grund Capture Report während Capturing) Mehrfach Einträge in DBA_WORKLOAD_CAPTURE Invalide Objekte nach PROCESS_CAPTURE Datendivergenz nach Replay auf AIX

41. Fazit / Bewertung 4

42. Aufwand Aufbau einer Q-Umgebung für Regressionstest des einzuspielenden Patches Aufbau Migrationsdatenbank Aufzeichnen der Produktionsdatenbank Abspielen in Migrationsdatenbank Vergleich Performancestatistiken der Produktionsdatenbank mit der Migrationsdatenbank

43. Nutzen Geringerer Personalbedarf für einen Applikationstest der Migrationsdatenbank Einfachere Performance-Optimierung der Migrationsdatenbank durch wiederholtes Abspielen der Aufzeichnung möglich Risikominimierung durch Tests mit produktiven Workload in der Migrationsdatenbank

44. Fazit Realistische Performancetests möglich (keine synthetische Last) Mehrfachwiederholungen bieten gute Möglichkeiten der Optimierung Einspielung des Patches in Produktivumgebung kontraproduktiv Funktionen nicht vollständig im Grid Control abgebildet Für größere Umgebung erhöhte Vorlaufzeiten bei der Einrichtung Host-Zugangsdaten stellen ein Sicherheitsproblem dar

45. Risiko kann minimiert, aber nicht ausgeschaltet werden

46. Fragen und Antworten

47. Kontakt Simon Dickmeiß, Consultant OPITZ CONSULTING Gummersbach GmbHsimon.dickmeiss@opitz-consulting.comTelefon: +49 2261 6001 - 0