Lasttests für Oracle Datenbanken. Torsten Schlautmann OPITZ CONSULTING Essen GmbH

Transkript

1 Torsten Schlautmann OPITZ CONSULTING Essen GmbH Nürnberg, OPITZ CONSULTING GmbH 2009 Seite 1

2 Agenda 1. Warum Lasttests? 2. Vorgehensmodell für Lasttests 3. Auswahl geeigneter Lasttest-Tools 4. Beispielszenarien OPITZ CONSULTING GmbH 2009 Seite 2

3 1 Warum Lasttests? OPITZ CONSULTING GmbH 2009 Seite 3

4 Warum Lasttests? Absicherung vor der Einführung neuer IT-Systeme Absicherung vor größeren Änderungen in der IT- Infrastruktur oder in der Applikation Migration auf ein neues Release (DB, Middleware, Applikation) Storage-Austausch Migration auf ein neues Betriebssystem Änderungen in der Gesamtarchitektur (Netz, Cluster-Technologien, etc.) usw. Absicherung eines Sizings Aufdecken von Problemen, bevor diese in der Produktion auftreten! OPITZ CONSULTING GmbH 2009 Seite 4

5 Warum Lasttests? Client Netzwerk Application-Server Netzwerk Datenbank Storage OPITZ CONSULTING GmbH 2009 Seite 5

6 2 Vorgehensmodell für Lasttests OPITZ CONSULTING GmbH 2009 Seite 6

7 Vorgehensmodell bei Lasttests Anforderungsprofil erstellen Tool-Auswahl Operationalisierung Ausführung und Messung Auswertung und Berechnung 6 Optimierung In Anlehnung an DIN / ISO OPITZ CONSULTING GmbH 2009 Seite 7

8 Anforderungsprofil erstellen Wie viele Benutzer arbeiten später mit dem System und müssen simuliert werden? Welche Bandbreiten müssen simuliert werden? Gibt es Spitzenlasten (z.b. Jahresabschlussarbeiten) die simuliert werden müssen? Welche Programmabläufe werden wie häufig und mit welchen Parametern aufgerufen? Welche Denkzeiten sind zu berücksichtigen? Welcher Anteil der Benutzer ist als aktiv, welcher als passiv zu bewerten? Wie soll das Antwortzeitverhalten sein? (!!!!) OPITZ CONSULTING GmbH 2009 Seite 8

9 3 Auswahl geeigneter Lasttest-Tools OPITZ CONSULTING GmbH 2009 Seite 9

10 Auswahl eines geeigneten Lastgenerators Kriterien für die Auswahl: Welche Schichten der Architektur müssen einbezogen werden? Welche Netzwerkprotokolle müssen unterstützt werden? Wie soll die Messung der Performance vorgenommen werden? (Korrelation beachten) Werden die Kriterien des Anforderungsprofiles abgedeckt? Synthetischer vs. natürlicher Lasttest Kosten (Lizenzen + Projekt) OPITZ CONSULTING GmbH 2009 Seite 10

11 Auswahl eines geeigneten Lastgenerators Lasttest-Tool / Lasterzeugung Testinfrastruktur Lasttreiber (Nutzer-Simulation) Steuerung/ Messung Application- Server Database- Server OPITZ CONSULTING GmbH 2009 Seite 11

12 Übersicht gängiger Lasttest-Tools IBM Rational Performance Tester HP (Mercury) Loadrunner Borland (Segue) SilkPerformer Compuware QALoad Quest Benchmark Factory Hammerora Swingbench OPITZ CONSULTING GmbH 2009 Seite 12

13 4 Beispielszenarien OPITZ CONSULTING GmbH 2009 Seite 13

14 Bsp.: Quest Benchmark Factory Szenario: Direkte Migration von (HP-UX, Single Instance) auf (Linux, RAC) Ziele: Probleme vor der Produktivstellung erkennen und beheben Lastverhalten unter realistischen Bedingungen prüfen Parametrisierung vor Produktivstellung optimieren Leistungsfähigkeit des System prüfen Zusammenspiel aller Komponenten testen OPITZ CONSULTING GmbH 2009 Seite 14

15 Ausgangssituation Heterogene IT-Umgebung: Diverse datenbankbetriebene Applikationen, teils hochkritisch Verschiedene Lieferanten für die Applikationen Große Anzahl an Oracle Datenbanken im Einsatz Dynamisches Umfeld mit häufigen Änderungen am Quellcode Zu berücksichtigende Änderungen: Datenbank Upgrade Anwendungsänderung Architekturwechsel und Plattformwechsel OPITZ CONSULTING GmbH 2009 Seite 15

16 Motivation: Datenbank Upgrade Ausgangslage: Datenbank zentrale Komponente Applikation für DB optimiert Datenbank Parameter optimiert Herausforderung: Support für DB-Version läuft aus Änderung: Datenbank Upgrade Upgrade? Welche Probleme treten auf? OPITZ CONSULTING GmbH 2009 Seite 16

17 Motivation: Anwendungsänderung Ausgangslage: Applikation durchläuft QS Datenbank Parameter optimiert Herausforderung: Redesign der Anwendung Massive Änderungen Änderung: Codeänderung Release 1.0 Codeänderung? Release 1.1 Welche Probleme treten auf? OPITZ CONSULTING GmbH 2009 Seite 17

18 Motivation: Architekturwechsel Ausgangslage: System Sizing für SLAs ausreichend Herausforderung: Neue Verfügbarkeitsanforderung Zukunftssichere Architektur Wachstum d. Benutzeranzahl Änderung: Architekturwechsel Betriebssystemwechsel Single Instance Architekturwechsel Betriebssystemwechsel? Knoten 2 Knoten 1 Welche Probleme treten auf? OPITZ CONSULTING GmbH 2009 Seite 18

19 Werkzeuge Quest Benchmark Factory Testet Performance und Skalierbarkeit Simuliert Benutzer und Transaktionen Abspielen eines Produktions-Workload Entwickler / DBAs / QA Teams können überprüfen, ob die Datenbank für Produktionsbetrieb skaliert Bei steigender Benutzerlast Vor Einspielen eines neuen Anwendungs-Release Vor Änderungen an Hardware / OS / Oracle-Version OPITZ CONSULTING GmbH 2009 Seite 19

20 Werkzeuge Quest Oracle Performance Analysis Abweichungen vom normalen Lastprofil erkennen Die Art des Problems eingrenzen CPU, I/O, Locking etc. Die Verursacher eingrenzen Anwendung, User, Client, SQL-Kommando Change Tracking Analyse (Ausführungspläne) Flashback-Einsatz: Als Verfahren zur Datenrückgewinnung wird Flashback für den Lasttest implementiert. OPITZ CONSULTING GmbH 2009 Seite 20

21 Mögliche Vorgehensweise im Projekt 1. Implementierung von Monitoring im Altsystem Aufzeichnung TOP-Statements Definition / Durchführung von kritischen Geschäftsprozessen Messung von Metriken Aufzeichnung Geschäftsprozesse (SQL Trace Level 12) 2. Implementierung eines Systems zur Lastgenierung und Messung Installation Clients für BF Einrichtung Repository Parametrisierung der TOP-Statements Database Replay Import SQL-Trace 3. Durchführung Performance Tests Erstellung von Testplänen Erstellung von Testszenarien auf Basis von SQL-Trace und TOP-Statements Messung von Metriken Auswertung / Vergleich / Abweichungen 4. Reaktion auf Abweichungen Änderung an der Applikation Änderung an der DB-Konfiguration Änderung Sizing Lastverteilung OPITZ CONSULTING GmbH 2009 Seite 21

22 1. Monitoring und Aufzeichnen des SQL (Trace) OPITZ CONSULTING GmbH 2009 Seite 22

23 2. Import Trace-Files und BM-Skripte OPITZ CONSULTING GmbH 2009 Seite 23

24 3. Durchführung d. Tests und Monitoring OPITZ CONSULTING GmbH 2009 Seite 24

25 4. Auswertung der Ergebnisse OPITZ CONSULTING GmbH 2009 Seite 25

26 Anmerkungen zum Vorgehen Definition des Ablaufes vor der Durchführung Gewährleistung von Vergleichbarkeit Einhalten des genauen Ablaufs! Ausschluss von weiteren Einflüssen Wiederholung sämtlicher Tests Sicherstellung der Messergebnisse Optimierung der Parameter / Konfiguration Dokumentation der Messparameter was muss z.b. bei den Wiederholungen berücksichtigt werden? OPITZ CONSULTING GmbH 2009 Seite 26

27 Bsp.: Real Application Testing (RAT) Szenario: Direkte Migration von (Windows, Single Instance, Failsafe) auf (Linux, RAC) Ziele: Probleme vor der Produktivstellung erkennen und beheben Lastverhalten unter realistischen Bedingungen prüfen Parametrisierung vor Produktivstellung optimieren Leistungsfähigkeit des System prüfen Zusammenspiel aller Komponenten testen OPITZ CONSULTING GmbH 2009 Seite 27

28 Ausgangssituation Zentrale Datenbankinfrastruktur: Mehrere Applikationen auf einer DB Dynamisches Umfeld mit häufigen Änderungen am Quellcode Zu berücksichtigende Änderungen: Datenbank Upgrade Architekturwechsel und Plattformwechsel Weitere Rahmenbedingungen: Lasttests sollen so realitätsnah wie möglich sein Kurzfristige Umsetzung aufgrund nicht beeinflussbarer Parameter zwingend notwendig (kurze Projektlaufzeit erforderlich) OPITZ CONSULTING GmbH 2009 Seite 28

29 Werkzeug: Real Application Testing: Capture Windows OPITZ CONSULTING GmbH 2009 Seite 29

30 Werkzeug: Real Application Testing: Replay Linux RAC OPITZ CONSULTING GmbH 2009 Seite 30

31 Hinweise zur Benutzung Was wird alles unterstützt? Jede Art von SQL (DML, DDL, PL/SQL) Volle LOB-Unterstützung Login / Logoff Wo sind die Grenzen? Direct path load (imp/exp) Streams, nicht PL/SQL-basiertes AQ Verteilte Transaktionen Flashback Shared Server OPITZ CONSULTING GmbH 2009 Seite 31

32 Hinweise zur Benutzung Was sollte bei der Planung berücksichtigt werden? Ausreichend Platz für die Aufzeichnung (und das Abspielen!) der Transaktionen muss vorhanden sein. Die Datenbank sollte auf jeden Fall bei Beginn der Aufzeichnung der Transaktionen durchgestartet werden (!!!) Das Zieldatenbank-System muss inhaltlich auf den Status zum Beginn der Aufzeichnung hergestellt werden. Über Filter können nach verschiedenen Kriterien nur bestimmte Transaktionen aufgezeichnet werden (User, Programm, Module, Action, Service, Session ID). Es werden SYSDBA-Rechte benötigt. Performance-Overhead ist abhängig von der Applikation Bedienung ist über Enterprise Manager & PL/SQL-Packages (DBMS_WORKLOAD_%) möglich. OPITZ CONSULTING GmbH 2009 Seite 32

33 Fazit Beide Tools haben ihre Stärken, die je nach Projektsituation gezielt eingesetzt werden sollten. Real Application Testing kann enorm Zeit sparen, sollte jedoch intensiv unter realistischen Rahmenbedingungen getestet werden (Einfluss auf Produktionssystem). Im direkten Vergleich ist die Nutzung von Benchmark Factory deutlich flexibler, setzt aber eine intensive Beschäftigung mit den wichtigsten Geschäftsprozessen voraus und verursacht Aufwände für das Skripting. OPITZ CONSULTING GmbH 2009 Seite 33

34 Fragen und Antworten OPITZ CONSULTING GmbH 2009 Seite 34

35 Kontakt Torsten Schlautmann OPITZ CONSULTING Essen GmbH Telefon Mobil OPITZ CONSULTING GmbH 2009 Seite 35