Performance-Maximierung eines Praxis-Systems auf Oracle-DB

Performance-Maximierung eines Praxis-Systems
auf Oracle-DB
17. Oktober 2012
Peter Ramm, Group Technology Partner Dresden, otto group
Group Technology Partner Dresden
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
Group Technology Partner Dresden
  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
Group Technology Partner Dresden 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
Group Technology Partner Dresden
Group Technology Partner Dresden
GTP – Das zentrale Nervensystem der Otto Group
45.000.000 Angebotsartikel
über 2.000 Server
35.000 Lieferanten weltweit
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
Technik des Systems
Rechenzentrum 1 (Hintergrund-Verarbeitung)
Glassfish AppServer-Domäne
Rechenzentrum 2 (Online-Verarbeitung)
Notfall-Oracle-Server
auf HP Superdome
10 Itanium cores
Glassfish AppServer-Domäne
Local Storage
Oracle-RAC-Instanz 1
auf HP Superdome
24 Itanium CPU-cores
100 GB Memory
Fibrechannel-Switch
Storage-System
EMC DMX4
Group Technology Partner Dresden
RAC-Interconnect
Oracle-RAC-Instanz 2
auf HP Superdome
18 Itanium CPU-cores
100 GB Memory
Fibrechannel-Switch
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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 DBServers
 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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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
Group Technology Partner Dresden
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. DBPerformance (auch zu finden unter http://rammpeter.wordpress.com )
 Quest Toad
 Oracle Enterprise Manager
Group Technology Partner Dresden
Ich danke für Ihre Aufmerksamkeit.
Ihre Fragen?
Group Technology Partner Dresden