Performance-Maximierung eines Praxis-Systems auf Oracle-DB 17. Oktober 2012 Peter Ramm,, otto group
Agenda 1. Kurzvorstellung otto group / Group Technology Partner 2. Technik des zentralen CRM / ERP-Systems 3. Maßnahmen zur Optimierung der Performance 4. Fragen und Antworten
11,6 Milliarden Euro Umsatz über 53.000 Mitarbeiter, 123 wesentliche Gesellschaften in mehr als 20 Ländern eine mehr als 60-jährige Unternehmensgeschichte. Die drei Säulen der otto group Multichannel-Einzelhandel Finanzdienstleitungen Service / Logistik Group Technology Partner (GTP) ist der zentrale IT-Dienstleister der otto group 650 Mitarbeiter Rechenzentrum am Standort Hamburg Software-Projekte in allen Segmenten und Vertriebskanälen in diversen Ländern ist Bestandteil der GTP 95 Mitarbeiter am Standort Dresden 2 GTP-Abteilungen mit Verantwortung für: Lokale Logistik IT für Logistik (Lager- und Retourenprozesse) in den Lager-Standorten Mittelstand und Fulfilment Versand- und Logistiksysteme außerhalb der zentralen IT z.b. Komplettabwicklung Otto Russland am Standort Twer
GTP Das zentrale Nervensystem der Otto Group 45.000.000 Angebotsartikel 35.000 Lieferanten weltweit über 2.000 Server 8.000 PC 13.000.000 Lieferauskünfte E-Commerce 2.000.000 Artikel täglich ausgeliefert 15.000 Netzwerkanschlüsse Über 100 laufende IT-Projekte bis zu 950.000 Pakete täglich 650 Mitarbeiter http://www.ottogroup.com/karriere
Agenda 1. Kurzvorstellung otto group / Group Technology Partner 2. Technik des zentralen CRM / ERP-Systems 3. Maßnahmen zur Optimierung der Performance 4. Fragen und Antworten
Eigenschaften des betrachteten Systems Ablösung der IT-Landschaft der 70er Jahre (Host-System, Assembler, Cobol) Mandantenfähiges CRM + ERP-System, begonnen 2002 Implementiert in Java JEE2 mit eigenen Infrastruktur-Frameworks sowie PL/SQL Funktionen: Verwaltung der Kundenstammdaten 60 Mio. Kunden, 2,5 Mrd. Attribute Bereitstellung von Artikelstammdaten 25 Mio. Artikelgrößen in Katalogen Bestandsverwaltung der Lagersysteme 70 Mio. Bestandskonten Bestandsaussagen für Bestellsysteme 13 Mio. täglich Auftragserfassung 1 Mio. Auftragspositionen je Tag Fakturierung Rechnungen 300.000 Rechnungen je Tag Debitoren-Mgmt., Zahlungsverkehr 2 Mio. Buchungen je Tag Mahnwesen 2,8 Mrd. Buchungen im System Datenbank: Oracle 10.2, seit 8/2012 umgestellt auf Oracle 11.2 2,5 Terabyte Daten, 15 Schemata, 2600 Tabellen, 4300 Indizes ca. 11 Mio. Lines of Java-Code
Technik des Systems Rechenzentrum 1 (Hintergrund-Verarbeitung) Rechenzentrum 2 (Online-Verarbeitung) Glassfish App- Server-Domäne Notfall-Oracle-Server auf HP Superdome 10 Itanium cores Local Storage Glassfish App- Server-Domäne Oracle-RAC-Instanz 1 auf HP Superdome 24 Itanium CPU-cores 100 GB Memory RAC-Interconnect Oracle-RAC-Instanz 2 auf HP Superdome 18 Itanium CPU-cores 100 GB Memory Fibrechannel-Switch Fibrechannel-Switch Storage-System EMC DMX4 Storage-System EMC DMX4
Agenda 1. Kurzvorstellung otto group / Group Technology Partner 2. Technik des zentralen CRM / ERP-Systems 3. Maßnahmen zur Optimierung der Performance 4. Fragen und Antworten
Aufgabenstellung Auslöser für gezielte Optimierung der Prozesse waren Mitte 2010 die Anforderungen eines Projektes zur Optimierung logistischer Prozesse: Fähigkeit zur Mehrscheibenfakturierung statt starrer Mittags- und Nacht-Verarbeitung Verkürzung der Prozess-Zeiten zwischen CutOff (Abruf der Aufträge) und Bereitstellung in Logistik Ausgangs-Situation im Projekt war: Keine freien Zeitscheiben für neue Jobs mehr im Jobnetz bei Beachtung der Abhängigkeiten Weitgehende Auslastung der vorhandenen Hardware bzgl. CPU und I/O-Bandbreite Zeitbedarf im kritischen Pfad der nächtlichen Verarbeitung: Stundenfenster: 3.. 4 Stunden Durchsatz 200.. 250 Auftragspos./Sec. Sammler: 3.. 4 Stunden NALI-Export 1.. 1,5 Stunden
Ergebnis der Laufzeitoptimierung Reduktion der Laufzeit von Prozessen auf dem kritischen Pfad der Verarbeitung: Spielraum in der Gestaltung des Jobnetz wiedererlangt Neue Funktionen/Prozesse aus den laufenden Projekten konnten platziert werden Sichere Einhaltung der SLA gegenüber Hermes für Belieferung Logistik trotz Rückgabe freiwerdender Zeitfenster (Anpassung SLA verkürzte Prozesslaufzeiten) Nur moderate HW-Erweiterungen notwendig trotz Zuwachs im Umsatz (Ersatz DMX3 durch DMX4) Verbesserte Antwortzeiten im OLTP trotz Erhöhung Anzahl OLTP-Requests in einem Jahr um Faktor 3 Prozess Laufzeit alt Laufzeit aktuell Änderung Faktor Durchsatz alt AP / Sec. Durchsatz aktuell AP / Sec. Stundenfenster 3.. 4 Stunden 0,75.. 1 Stunden 4 200.. 250 500.. 630 Sammler 3.. 4 Stunden 1,5.. 2 Stunden 2 NALI-Exporte 1.. 1,5 Stunden 0,2.. 0.25 Stunden 5
Wege zum Ziel Umfassende Bewertung und Optimierung aller performance-relevanten Aspekte: Architektur / Lösungsdesign der Applikation passend zur Aufgabenstellung? Technische Implementierung der Lösung Parametrisierung der DB Optimal auf Aufgabe angepasste SQL-Statements Optimale Storage-Strukturen Ressourcenverteilung im DB-Cache angemessen der fachlichen Relevanz der Objekte Klärung von Concurrency-Problemen Konsequentes Housekeeping von Altdaten Iteratives Vorgehen mit großer Anzahl von Optimierungs-Zyklen: Identifizieren der aktuell problematischsten Bottlenecks Erarbeiten Lösungsvarianten und Bewerten bzgl. Wirtschaftlichkeit Umsetzen und Testen der Lösung Ausrollen der Lösung in Produktion Erfolgsbewertung der Lösung im Produktivbetrieb, Vorher-/Nachher-Vergleich Und jetzt wieder das Ganze von vorn
Herausforderungen an Releasebildung Traditionelle Releasepolitik ist oft ungeeignet zur Umsetzung: Drastische Verbesserungen der Performance eines Systems sind selten mit einigen wenigen Maßnahmen zu erreichen Eher sind einige 100 bis 1000 Einzelmaßnahmen erforderlich, um in Summe drastische Verbesserungen zu erreichen D.h., brachiale Verbesserungen der Systemperformance sind erreichbar durch die Summe von Einzelmaßnahmen die allein betrachtet mit Effekt < 1% eher als Peanuts bewertet werden Da die rein technische Umsetzung dieser Maßnahmen aber oft nur im Minutenbereich liegt, ist die Umsetzung trotzdem wirtschaftlich sinnvoll Dies erfordert jedoch, den Overhead für Organisation, Test, Rollout etc. In einem adäquatem Verhältnis zu halten Notwendig ist eine pragmatische Betrachtung, welche der Maßnahmen in den klassischen Releaseprozess mit vollständiger Testphase, Fachabnahme etc. eingeplant werden müssen Für kleine Änderungen mit kalkulierbarem Risiko braucht es einen agileren Weg für Test und Produktivsetzung mit Zyklen <= 1 Woche
Herausforderungen an Planung und Budgetierung Keine detaillierte Langfristplanung einzelner Maßnahmen möglich: Es sind jeweils nur die unmittelbar zu erkennenden Bottlenecks verfügbar als Grundlage für die Aufgabenplanung der nächsten Iteration und Aufwandskalkulation Verbleibende Bottlenecks sind oft erst erkennbar nach Produktivsetzung der Lösungen der vorhergehenden Iteration komplexere Lösungen brauchen oft mehrere Iterationen mit aufeinander aufbauenden Einzelschritten Damit ist die Wasserfall-Methode nicht anwendbar a'la: Erst ermitteln des kompletten Leistungsumfangs Erstellen von Arbeitspaketen und Schätzen der Aufwände Klären der Finanzierung auf Basis der Angebote Aufteilen der Arbeitspaketen in Lieferungen/Iterationen Vielmehr ist notwendig, Abbruchkriterien für die Systemoptimierung zu definieren: Break Even, ab dem das Problem als gelöst gilt und weitere Optimierungen unwirtschaftlich werden Oberes Limit von Budget und Zeitrahmen für die Optimierung Es braucht einen Vertrauensvorschuss zur Durchführung einer solchen Optimierung Das Fehlen dieser Vertrauensbeziehung ist oft Ursache, dass das Optimierungspotential von IT-Systemen nicht gehoben wird
Optimale Parametrisierung der DB Anpassung der DB-Initialisierungsparameter an Applikationserfordernisse unter Berücksichtigung der HW-Ressourcen, z.b.: Memory-Konfiguration mit Ziel optimaler Nutzung des vorhandenen Memory des DB- Servers sga_target (Vorbelegung db_cache_size, shared_pool_size) pga_target Rückgriff auf Empfehlungen aus v$xx_advice Konfiguration parallel query parallel_adaptive_multi_user parallel_execution_message_size parallel_threads_per_cpu PQ-Migration im RAC: parallel_instance_group (bis 10g), Service-Name (ab 11g) Steuerung Affinität zu FullTableScan bzw. Index-Scan per optimizer_index_cost_adj Nutzung function based indexes: query_rewrite_enabled, query_rewrite_integrity Unterstützung Cursor-Sharing: session_cached_cursors undo_retention: Steuern Kompromiss zw. ora-1555 (snapshot to old) und ora-1650 (unable to extend rollback segment) fast_start_mttr_target: unerreichbare Vorgabe bremst Schreibzugriffe massiv
Optimal auf Aufgabe angepasste SQL-Statements Beurteilung ausgeführter SQL aus aktueller SGA und AWR-Historie (DBA_Hist_SQLStat): Laufzeit passend zur Aufgabenstellung und Datenmenge Indizierung der Objekte passend zum SQL Bewertung über buffer gets je Execution bzw. je Row optimaler Ausführungsplan (ab bestimmter Komplexität manuelle Nachhilfe per Hint notwendig) Optimale Anwendung von Filtern z.b. bei Update (verhindern Update identischer Werte) Nutzung parallel query Anweisung per Hint am SQL statt über globale Definition Optional Limitierung degree per Hint am SQL (bei hoher Anzahl CPU-cores) Wenn Nutzung PQ, dann konsequent für alle großen Objekte des SQL Bewertung komplexer SQL durch Ausführung mit GATHER_PLAN_STATISTICS-Hint
Optimale Storage-Strukturen Minimierung Verschnitt durch minimal möglichen PctFree ohne chained rows Komprimierung von Indizes und Tabellen Partitionierung von Datenstrukturen Trennung aktive von historischen Daten Reduktion Blevel von Indizes durch Partitionierung Nutzung von Intervall-Partitionierung (ab 11g) Identifikation und Eliminierung von ungenutzten Spalten und Indizes Reduktion der Größe von Indizes auf tatsächlich relevante Records bei geringem Anteil dieser Records (ungenutzte Werte per Ausdruck auf NULL drehen und damit nicht indizieren) Verwendung von IOT für passende Objekte: Reduktion des Footprints der Objekte, somit Reduktion I/O, DB-Cache Drastische Verbesserung Zugriffsverhalten durch Reduktion der Anzahl Buffer je Execution
Ermitteln der Last-Treiber in kritischen Zeiträumen per Active Session History Auswertung v$active_session_history bzw. DBA_Hist_Active_Sess_History: Eingrenzen der Last über Wait-Time nach diversen Kriterien wie u.a. : Ausgeführte Prozesse (Module/Action per dbms_application_info) Beurteilen Verhältnis zwischen Ressourcenbelastung und fachlicher Relevanz. Ist im Zeitraum dieser Prozess im Verhältnis zur Aufgabe und den weiteren Prozessen angemessen unterwegs Passen die Verarbeitungsmengen (DBA_Hist_SQLStat.Rows_Processed) zu der fachlichen Aufgabenstellung? Ausgeführte SQL-Statements Passt die Wahl der Tabellenzugriffe (Index/Full) und Join-Operationen (NL/Hash) des Ausführungsplanes zu: der Größe der Tabellen der zu verarbeitenden Datenmenge der realisierbaren Cache-Hit-Rate zu diesem Zeitpunkt Bewertung der aufgetretenen Wait-Events Zugegriffene DB-Objekte
Bewerten des Systems nach Segment-spez. Statistiken aus DBA_Hist_Seg_Stat Scannen des Systems nach Segment-spez. Statistiken aus DBA_Hist_Seg_Stat, Zuordnung der Lasten aus Active Session History: Prüfen und Bewerten von unplausiblen Werten je Segment bezüglich: Buffer gets Phys. Reads Phys. Writes Free Buffer Waits ITL-Waits Row-Lock-Waits Check auf das Segment nutzende SQL über Reverse-Analyse der Execution-Pläne Check auf Wait-Events der Segmente über Active Session History Check auf zugehörige SQL über Active Session History
Ressourcenverteilung im DB-Cache gemessen an der fachlichen Relevanz der Objekte Beurteilung der Ressourcenverteilung im DB-Cache: Passt die Gewichtung der Objekte im Cache zur Relevanz der Objekte für die fachliche Aufgabenstellung? werden die für OLTP-Prozesse relevanten Objekte ausreichend im Cache berücksichtigt? wird evtl. Verdrängung im Cache provoziert durch Objekte, die sinnvoller per direct path read gelesen werden sollten werden durch ineffektive SQLs Objekte bevorzugt im Cache platziert, die fachlich nicht relevant sind und wesentliche Objekte verdrängen Ist Bemessung DB-Cache-Size angemessen? In Verbindung mit Auswertung V$DB_CACHE_ADVICE
Klärung von Concurrency-Problemen Auflösen von Concurrency-Problemen: Scannen der System-Historie nach blocking locks Nutzung active session history mit Einschränkungen (bis 11g keine Aufzeichnung RAC-übergreifender Locks mit Identifikation Blocker / GLOBAL) eigener Protokoll-Daemon für detaillierte Aufzeichnung und Auswertung Bewerten und Auflösen applikatorischer Probleme sinnvolle Parallelität von Prozessen Klärung Serialisierung an kritischen Ressourcen Optimierung Transaktionsgröße und Datenstrukturen für parallele Verarbeitung Ziel: nahezu vollständige Vermeidung von Blocking Lock Situationen Optimieren RAC-Spezifika für die konkrete Applikation Erkennen von Bottlenecks auf Interconnect Berücksichtigen RAC-Spezifika im Applikationsdesign (funktionale Trennung der Knoten) Partitionieren spezieller Tabellen nach RAC-Instanzen, so dass jeder Knoten eigenen physischen Bereich der Tabelle exklusiv bearbeitet
Housekeeping Konsequentes Housekeeping von Altdaten: Bestandsaufnahme Bestehende Housekeeping-Prozesse Nicht im Housekeeping enthaltene Tabellen Tabellen mit zeitlich langer bzw. unbegrenzter Aufbewahrungsdauer Analyse der fachlichen/technischen Notwendigkeit zur Aufbewahrungsdauer Bereitstellung eines Housekeeping-PL/SQL-Package Löschung in Reihenfolge der physischen Ablage der Daten Reduktion der Schreiblast auf notwendiges Minimum Ergebnis Reduktion Footprint der Tabellen Entlastung DB-Cache Quasi nebenbei Review Datenmodell Nicht mehr benötigte Alt-Tabellen gefunden und entfernt
Genutzte Werkzeuge Panorama (eigenes Werkzeug für Performance-Monitoring und Analyse) GUI für Analyse der im Vortrag genannten Performance-Aspekte Rasterfahndung nach knapp 70 unterschiedlichen Anti-Pattern bzgl. DB- Performance (auch zu finden unter http://rammpeter.wordpress.com ) Quest Toad Oracle Enterprise Manager
Ich danke für Ihre Aufmerksamkeit. Ihre Fragen?