DOAG Datenbank Partitioning für OLTP Applikationstuning mal anders. Düsseldorf, , M. Griesel. Paragon Data GmbH Seite 1

Transkript

1 DOAG Datenbank 2015 Partitioning für OLTP Applikationstuning mal anders Düsseldorf, , M. Griesel Seite 1

2 Profil und Anspruch fair effizient auf Augenhöhe 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 Seite 2

3 Unternehmen und Referenzen Umsatz: 11 Mio Mitarbeiter: 60 Starkes Partner-Netzwerk Seite 3

4 Die Ausgangssituation Warenwirtschaftssystem buchhandelsspezifisch schlechte Performance Clients blocking/ waiting Locks wenig/ keine Unterstützung des Herstellers Eigenentwicklungen RAC/ Exadata mit Storage Terminalserver Datenbankkonsolidierung, 8 Datenbanken auf einem System Partitioning Option durch Datawarehouse vorhanden Seite 4

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 Session 1: select * from... for update; Session 2: select * from... for update; Session 3: select * from... for update;... Session n: select * from... for update; select * from tab where mand= D ; sehr große Tabelle Sehr stark gelesene mandantenunabhängige Tabellen select * from tab where mand= C ; select * from tab where mand= A ; select * from tab where mand= B ; Seite 5

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 Seite 6

7 Partitioning, aber wie? Verschiedene Möglichkeiten des Partitioning: 1) Range 2) Hash 3) Composite Keep it simple! 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 langwierige und aufwendige Analysen Seite 7

8 Vorgehensweise Große und häufig zugegriffene Tabellen und Indizes werden partitioniert! à 15 Tabellen identifiziert! à Partitionkey wird das Mandatenquadruppel à 1 Partition pro Filiale Tabelle AA Mandant a Mandant b Mandant c Mandant z... à Tabellen ohne Partitionkey (Sortiment ist für alle Filialen gleich, da zentral bewirtschaftet) à Hashpartitioning auf Primary Key mit PQ Tabelle SA Hash 1 Hash 2 Hash 3 Hash 6... à keine Reduzierung der Treffermenge, aber schnellerer Zugriff per PQ! Seite 8

9 Zugriff auf Tabellen ohne Partitioning Client 1 Zu lesende Blöcke: n (alle) Alle Blöcke bis zur HWM komplette Menge select * from Tabelle Tabelle where name = PARAGON and mandant = 01 ; Extent 1 Extent 2 DOAG Extent 2 Paragon Oracle... Seite 9

10 Zugriff auf eine range partitionierte Tabelle (mandantengeführt, eindeutiger Partitionkey) Client 1 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 select * from Tabelle Tabelle where name = PARAGON and mandant = 01 ; DOAG Partition 1: Mandant 00 Partition 2: Mandant 01 Partition n: Mandant n Paragon Extent 1 Extent 1 Extent 1 Oracle...

11 Zugriff auf eine hash partitionierte Tabelle (kein Mandant, kein eindeutiger Partitionkey) Client 1 Zu lesende Blöcke: n (alle der Tabelle) Alle Blöcke bis zur HWM jeder Partion (1/n), Striping paralleler Zugriff (schneller) Tabelle select * from Tabelle where name = PARAGON ; DOAG Hash Partition 1 Hash Partition 2 Hash Partition n Paragon Extent 1 Extent 1 Extent 1 Oracle PQ1 PQ2 PQn... Seite 11

12 Zugriff auf eine composite partitionierte Tabelle (mandantengeführt, eindeutiger Partitionkey, sehr groß) Client 1 select * from Tabelle where name = PARAGON and mandant = 01 ; 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 Bescheunigung DOAG Paragon Partition 1: Mandant 00 Partition 2: Mandant Oracle 01 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... P P P P Q Q2 Q3 Qn 1 Seite 12

13 Darstellung der Probleme im Grid Control bzw. Cloud Control Vorher: Danach: Seite 13

14 Ergebnisse des Partitionings 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 Seite 14

15 Zukünftige Änderung der Partitionierung zur Heiß-/ Kaltdatenauslagerung Tabelle T (mandantengestützt) Tabelle T (mandantengestützt) Range 1: Range 2: Mandant 00 Exadata Mandant 01 Range n: Mandant n Range 2: Mandant Filiale wird geschlossen HCC komprimiert! keine bzw. wenig Änderungen sehr performanter Zugriff ZS3-2 kein Smartscan T T Infiniband 40 Gbit/s Seite 15

16 Fragen? Q & A Seite 16

17 Vielen Dank! Malthe Griesel, Seite 17