© Paragon Data GmbH Seite 1
DOAG Regionaltreffen Bremen, 02.02.16
Partitioning für OLTP – Applikationstuning mal anders
Bremen, 02.02.2016, M. Griesel
© Paragon Data GmbH
fair – effizient – auf Augenhöhe
Seite 2
Profil und Anspruch
n 60 Mitarbeiter an den Hauptstandorten Friedrichsdorf und München
n 11 Mio. Umsatz
n Branchen: Einzelhandel, Logistik, Öffentliche Hand, Pharma, Banken
n Flache Hierarchien, offene Kommunikation, Flexibilität
n Umfassende Beratung mit Praxis-Perspektive Individuell optimierte Lösungen
n Starkes Partnernetzwerk
© Paragon Data GmbH Seite 3
Unternehmen und Referenzen
Umsatz: 11 Mio €
Mitarbeiter: 60
Starkes Partner-Netzwerk
© Paragon Data GmbH
Die Ausgangssituation
Seite 4
• Warenwirtschaftssystem
• buchhandelsspezifisch
• schlechte Performance
• blocking/ waiting Locks
• wenig/ keine Unterstützung des Herstellers
• Eigenentwicklungen
• Datenbankkonsolidierung, 8 Datenbanken auf einem System
• Partitioning Option durch Datawarehouse vorhanden
RAC/ Exadata mit Storage
Terminalserver
Clients
© Paragon Data GmbH Seite 5
Zusammenfassung der Probleme
• keine bzw. keine gute Zusammenarbeit mit dem Hersteller
• Applikation nicht optimal
• sehr kritische Performance, Gefährdung für das Unternehmen
• riesige Lockbäume mit mehr als 200 Sessions beteiligt
• „Sehr große“ Tabellen werden von allen in Teilen/ mandantenabhängig gelesen
• Sehr stark gelesene mandantenunabhängige Tabellen
Session 1: select * from ... for update;
Session 2: select * from ... for update;
Session 3: select * from ... for update; ...
Session n: select * from ... for update;
sehr große Tabelle
select * from tab where mand=‚A‘;
select * from tab where mand=‚B‘;
select * from tab where mand=‚C‘;
select * from tab where mand=‚D‘;
© Paragon Data GmbH Seite 6
Lösungsansatz
Fasten your transaction! • Applicationtuning durch den Hersteller
• Hardwareupgrade • Memoryupgrade • CPU • Storage
• Applicationtuning durch applikationstransparente Änderung des Datenmodells
• Partitioning • möglich, da DB Konsolidierung auf System mit Partitioning Option • Mit Partitioning besteht die Möglichkeit von effektiver Nutzung von
Parallel Query
© Paragon Data GmbH
Partitioning, aber wie?
Seite 7
Verschiedene Möglichkeiten des Partitioning: 1) Range 2) Hash 3) Composite
Indexpartitioning à nur local oder global Partioningkey? Key muss in den SQL-Statements benutzt werden, sonst kein Nutzen! Mandantengestütztes System, Mandantenquadruppel (FirmaNr, MandantNr, GeschaeftsNr, FilialNr) zieht sich durch das komplette DB-Modell! Zugriffe per SQL-Trace und SGA (V$SQL) ermitteln
Keep it simple!
langwierige und aufwendige Analysen
© Paragon Data GmbH
Vorgehensweise
Seite 8
Große und häufig zugegriffene Tabellen und Indizes werden partitioniert! à 15 Tabellen identifiziert! à Partitionkey wird das Mandatenquadruppel à 1 Partition pro Filiale
à Tabellen ohne Partitionkey (Sortiment ist für alle Filialen gleich, da zentral bewirtschaftet) à Hashpartitioning auf Primary Key mit PQ
à keine Reduzierung der Treffermenge, aber schnellerer Zugriff per PQ!
Tabelle AA
Mandant a Mandant b Mandant c Mandant z . . .
Tabelle SA
Hash 1 Hash 2 Hash 3 Hash 6 . . .
© Paragon Data GmbH
Tabelle
Extent 2 Extent 1 Extent 2
. . .
DOAG
Paragon
Oracle
Zugriff auf Tabellen ohne Partitioning
Seite 9
Client 1
select * from Tabelle where name = ‚PARAGON‘ and mandant = ‚01‘;
Zu lesende Blöcke: n (alle) Alle Blöcke bis zur HWM komplette Menge
© Paragon Data GmbH
Tabelle
Partition 2: Mandant 01 Partition 1: Mandant 00 Partition n: Mandant n
. . .
Extent 1 Extent 1 Extent 1
Zugriff auf eine range partitionierte Tabelle (mandantengeführt, eindeutiger Partitionkey)
DOAG
Paragon
Oracle
Client 1
select * from Tabelle where name = ‚PARAGON‘ and mandant = ‚01‘;
Zu lesende Blöcke: n (alle der Partition, 1/n Blöcke) Alle Blöcke bis zur HWM der Partion (1/n) alle Blöcke der Partition/ Teilmenge
© Paragon Data GmbH
Zugriff auf eine hash partitionierte Tabelle (kein Mandant, kein eindeutiger Partitionkey)
Seite 11
Tabelle
Hash Partition 2 Hash Partition 1 Hash Partition n
. . .
Extent 1 Extent 1 Extent 1
DOAG
Paragon
Oracle
Client 1
select * from Tabelle where name = ‚PARAGON‘;
Zu lesende Blöcke: n (alle der Tabelle) Alle Blöcke bis zur HWM jeder Partition (1/n), Striping paralleler Zugriff (schneller)
PQ1 PQ2 PQn
© Paragon Data GmbH
Zugriff auf eine composite partitionierte Tabelle (mandantengeführt, eindeutiger Partitionkey, sehr groß)
Seite 12
Partition 2: Mandant 01 Partition 1: Mandant 00 Partition n: Mandant n
. . .
HP1 HP2 HP3 HPn HP1 HP2 HP3 HPn HP1 HP2 HP3 HPn
. . . . . . . . .
EX 1 EX 1 EX 1 EX 1 EX 1 EX 1 EX 1 EX 1 EX 1 EX 1 EX 1 EX 1
DOAG
Paragon
Oracle
Client 1
select * from Tabelle where name = ‚PARAGON‘ and mandant = ‚01‘;
PQ1
PQ2
PQ3
PQn
Zu lesende Blöcke: n (alle der Rangepartition, m Hashpartitionen, 1/n Blöcke) Alle Blöcke bis zur HWM der Hashpartionen (1/m) PQ zur Beschleunigung
© Paragon Data GmbH
Darstellung der Probleme im Grid Control bzw. Cloud Control
Seite 13
Vorher:
Danach:
© Paragon Data GmbH
Ergebnisse des Partitionings
Seite 14
• deutlich schnellere Zugriffe auf die Tabellen und Daten • zwischen 4 und 20 mal schneller
• schnellere applikative Prozesse • Beispiel Dispoliste (wichtiger interner Prozess)
• Laufzeit ohne Partitioning: ca. 10 Minuten • Laufzeit mit Partitioning: 50 Sekunden
• Locking/ Blocking Locks mit Partitioning so gut wie nicht mehr vorhanden
• Exporte/ Importe via Datapump sehr viel schneller, da parallel gearbeitet werden kann
• Vorsicht bei Parallel Query (PQ), Overhead mit einberechnen, skaliert nicht unbedingt linear
© Paragon Data GmbH
Zukünftige Änderung der Partitionierung zur Heiß-/ Kaltdatenauslagerung
Seite 15
Exadata
ZS3-2
Infiniband 40 Gbit/s
T
Tabelle T (mandantengestützt)
Range 1: Mandant 00
Range 2: Mandant 01
. . .
T
Tabelle T (mandantengestützt)
Range n: Mandant n
Filiale wird geschlossen
Range 2: Mandant 01
HCC komprimiert! keine bzw. wenig Änderungen
sehr performanter Zugriff kein Smartscan
© Paragon Data GmbH Seite 16
Fragen?
Q & A