Erfahrungsbericht aus einem Evaluierungsprojekt einer hochtransaktionalen Datenbankanwendung auf Oracle EXADATA

Transkript

1 Erfahrungsbericht aus einem Evaluierungsprojekt einer hochtransaktionalen Datenbankanwendung auf Oracle EXADATA Lars Geldner, Thomas Lehmann HTW Datenbankstammtisch Dresden,

2 Agenda robotron*ecount-system bei der RWE Metering GmbH Smart Meter-Skalierungsprojekt Vorstellung EXADATA Tuningkonzepte / Tuningwerkzeuge konkrete Tuningmaßnahmen EXADATA-Spezifika Zusammenfassung

4 robotron*ecount bei der RWE Metering GmbH

8 Smart Meter-Skalierungsprojekt Smart Metering tatsächlicher aktueller Energieverbrauch des Endkunden (auch SLP!) tatsächliche Nutzungszeit umfassendes Bild der gegenwärtigen Energiekosten bessere Steuerbarkeit sowie Vergleichbarkeit Einsatz von intelligenten Zählern rechtliche Grundlage: z.b.: EnWG 21b Abs. 3a (Einbau von intelligenten Zählern bei Neuanschlüssen)

9 Smart Meter-Skalierungsprojekt

10 Smart Meter-Skalierungsprojekt Projektauftrag aktuelles System hinsichtlich Skalierbarkeit auf zukünftige Anforderungen durch Smart Metering untersuchen Ertüchtigungsmaßnahmen für System ableiten und bewerten bewerten, ob die Architektur der Anwendung geeignet ist, die für die Zukunft geschätzte Anzahl von Smart Meter zu verwalten und zu verarbeiten zur Feststellung der Zukunftssicherheit sind Überlastungstests mit einer sehr großen Anzahl von Zählern durchzuführen Smart Meter-Tests auf Basis der aktuellen Systemgrundlast

11 Smart Meter-Skalierungsprojekt Teiltests Grundlast ZFA-Import: Import, Plausibilisierung und Export von RLM- Zeitreihen (ca Zeitreihen mit je 96 Werten/d) Lastflussrechnung: beschreibt Energiefluss vom vorgelagerten Netzbetreiber bis hin zum Letztverbraucher. Dabei werden auf Basis gemessener Viertelstunden-Arbeitswerte je Netz- und Umspannebene abgeleitete Viertelstundenwerte und Kenngrößen (z.b. Jahreshöchstleistung) ermittelt Teiltests Smart Metering Import der Daten von 2 Mio. Smart Metern Nutzerauthentifizierung und Lastgangabruf im Tarifkundenportal

12 Smart Meter-Skalierungsprojekt 2 Mio. Zähler-Test Zähler * 1 Wert = Werte Zähler * 96 Werte = Werte Zähler * 2 Kanäle * 96 Werte = Werte Werte/d (Rohzeitreihe + Arbeitszeitreihe) 12 Mio. Zähler-Test Zähler * 1 Kanal * 96 Werte = Werte/d Werte/d (Rohzeitreihe + Arbeitszeitreihe)

14 EXADATA Spezifika abgestimmte Hardwarekonfiguration Scale-Out-Architektur optimierte Storagezugriffe performante Cache-Nutzung Oracle Real Application Cluster

15 Exadata Hardware Architecture Database Grid 8 x Dual-processor x64 database servers OR 2 x Eight-processor x64 database servers Intelligent Storage Grid 14 High-performance low-cost storage servers 100 TB High Performance disk, or 504 TB High Capacity disk 22.4 TB PCI Flash InfiniBand Network 3 x 36-port 40Gb/s switches Unified server & storage network Intelligent Storage Server Software

16 Kostengünstige Einstiegskonfiguration 16 Database Cores, 54 TB Disk, 2.4 TB PCI Flash Hochverfügbarkeitskonfiguration mit allen Exadata Eigenschaften Exadata Achtel Rack hat exakt die gleiche Hardware wie das Quarter Rack Die Hälfte der Hardware in jedem Server ist durch Software deaktiviert Hälfte der CPU cores in jedem DB server socket Hälfte der CPU cores in jedem Storage server socket Hälfte der Disks und Hälfte der Flash Cards in jedem Storage server Memory ist nicht deaktiviert Eine sehr leistungsstarke Konfiguration Upgrade von Achtel auf Quarter Rack durch Scriptausführung Capacity on Demand

17

18

20 Tuningkonzepte Proaktives Monitoring Vergleichswerte Keine signifikanten Änderungen der Anwendung Kleine Eingriffe (Statistiken, SQL Profile, SQL Plan Baseline, ) Konkrete Problemlösung (bottleneck) Überbeanspruchung einer Ressource Großer Eingriff

21 Tuningwerkzeuge Database / Cloud Control* Baselines, Events, Real Time Monitoring AWR-Reports* zeitbezogene Top-Down-Analyse Advisors* konkrete Problemanalyse 3rd party Tools eigene Skripte *Lizenzen: Diagnostic Pack Tuning Pack control_management_pack_access

23 Beispiel 1: INSERT-Optimierung Problemstellung: Erhöhung der Einfügeperformance Testfall: parallel schreibende Sessions auf 1 Tabelle Sequence PK ID WERTE 1 Wert1, Wert2, Wert3; Wert4, Wert5, 2 Wert10, Wert11, Wert12; Wert13,

24 Ad-hoc Monitoring Database / Cloudcontrol

25 Monitoring per AWR-Report 1. Snapshot Database / Cloudcontrol DBMS_WORKLOAD_REPOSITORY Lasttest 2. Snapshot Generierung AWR-Report Database / Cloudcontrol DBMS_WORKLOAD_REPOSITORY $ORACLE_HOME\rdbms\admin\awrrpt.sql

26 Engpässe identifizieren

27 Engpässe beheben Problem: buffer busy waits & enq: TX index contention Lösung: REVERSE KEY INDEX Problem: ITL contention Lösung: INITTRANS Parameter create unique index WERTE_PK on WERTEABLAGE (ID) tablespace TOOLS pctfree 10 initrans 20 maxtrans 255 reverse;

28 Reverse Key Index ROWID ID AAAOM5AApAAAACDAAA 10 AAAOM5AApAAAACDAAB 11 AAAOM5AApAAAACDAAC 12 AAAOM5AApAAAACDAAD 13 AAAOM5AApAAAACDAAE 14 ROWID ID AAAOM5AApAAAACDAAA 01 AAAOM5AApAAAACDAAB 11 AAAOM5AApAAAACDAAC 21 AAAOM5AApAAAACDAAD 31 AAAOM5AApAAAACDAAE 41 Root Root <5 >=5 <20 >=20 1,2 3 7,8 10,11,12, 13,14 1, ,41

29 Hot blocks Root <5 >=5 1,2 3 7,8 10,11,12, 13,14 Buffer bussy waits Enq: TX Index contention

30 Umsetzungsergebnis überprüfen

31 Engpässe beheben Problem: enq: SQ contention Lösung: Cache-Parameter der Sequence erhöhen drop sequence SEQ_WERTE; create sequence SEQ_WERTE minvalue 1 maxvalue start with 1 increment by 1 cache 1000;

32 Umsetzungsergebnis überprüfen vorher:

33 Tuningergebnis Indexkonvertierung durchgeführt Indexparameter geändert Cacheparameter der Sequence angepasst geringer Anpassungsaufwand Reduzierung von Warteereignissen Beschleunigung des INSERT-Statements um 30%

34 Beispiel 2: DBMS_LOCK Problemstellung: Optimierung Sperrmechanismus bei pessimistischem Lockansatz Testfall: massive Benutzung von DBMS_LOCK dbms_lock.allocate_unique; dbms_lock.request; dbms_lock.release;

35 Engpässe identifizieren

36 DBMS_LOCK jeder Aufruf DBMS_LOCK.allocate_unique jeder 100. Aufruf INSERT into DBMS_LOCK_ALLOCTED DELETE from DBMS_LOCK_ALLOCTED MOS ID Package DBMS_LOCK Specification MOS ID DBMS_LOCK_ALLOCATED Table cleanup

37 Engpässe beheben Problem: enq: SQ contention Lösung: Anpassung der Anwendung Vermeidung von DBMS_LOCK.allocate_unique anwendungsseitige Generierung von eindeutigen IDs dbms_lock.allocate_unique; dbms_lock.request; dbms_lock.release;

38 Umsetzungsergebnis voher:

39 Sequencen im RAC-Umfeld create sequence SEQ_WERTE minvalue 1 maxvalue start with 1 increment by 1 cache 1000; INSERT SEQ_WERTE (1-1000) SEQ_WERTE ( ) INSERT INTO VALUES (1); INSERT INTO VALUES (2); INSERT INTO VALUES (3); INSERT INTO VALUES (1001); INSERT INTO VALUES (1002); INSERT INTO VALUES (1003);

40 Sequencen im RAC-Umfeld ID Zeitstempel :44: :44: :44: :44: :44: :44:06 Ergebnis: IDs nicht aufsteigend nummeriert! 1001 kommt vor 3 Keine Sortierung nach ID-Spalten aus Sequenzen

41 Sequencen Anlegen

42 Sequenceoptionen CACHE: Specify how many values of the sequence the database preallocates and keeps in memory for faster access. This integer value can have 28 or fewer digits. The minimum value for this parameter is 2. For sequences that cycle, this value must be less than the number of values in the cycle. You cannot cache more values than will fit in a given cycle of sequence numbers. If a system failure occurs, all cached sequence values that have not been used in committed DML statements are lost. The potential number of lost values is equal to the value of the CACHE parameter. NOCACHE Specify NOCACHE to indicate that values of the sequence are not preallocated. If you omit both CACHE and NOCACHE, the database caches 20 sequence numbers by default. ORDER Specify ORDER to guarantee that sequence numbers are generated in order of request. This clause is useful if you are using the sequence numbers as timestamps. Guaranteeing order is usually not important for sequences used to generate primary keys. ORDER is necessary only to guarantee ordered generation if you are using Oracle Database with Real Application Clusters. If you are using exclusive mode, sequence numbers are always generated in order. NOORDER Specify NOORDER if you do not want to guarantee sequence numbers are generated in order of request. This is the default.

43 Ressourcen Nutzen - Parallelisieren Auf Parallelisierbarkeit der Anwendung achten DBMS_PARALLEL_EXECUTION KEEP-POOL DBMS_SHARED_POOL.MARKHOT* *ab Oracle 11.2 verfügbar unbedingt Testen!

45 EXADATA-Spezifika verteilte Anwendungsprozesse Parallelisierung Skalierungsfähigkeit Oracle RAC Instanzen Global Cache Synchronisation zwischen RAC-Knoten Signifikantere Auswirkung von Ressourcenengpässen

46 Hot blocks unter RAC Client Client Client Client..... PK SCAN-Listener ID WERTE 1 Wert1, Wert2, Wert3; Wert4, Wert5, 2 Wert10, Wert11, Wert12; Wert13,

47 Hot blocks unter RAC

48 Smart Scan Filterung der Daten auf Storage-Ebene Unterstütze Operatoren: =,!=, <,>, NULL, LIKE, AND, OR Zeilen- und Spaltenbasiert Reduzierung von Netzwerktraffic Administrative Operationen (RMAN backup, datafiles, Optimizerstatistiken)

49 Flash Cache Zusätzlicher Datenbank-Cache Besonders effizient bei OLTP-Systemen LRU-Mechnismus oder feste Adressierung (cell_flash_cache) Effizienz = reads hits / request * 100 (7 500 / ) *100 = 65 %

50 Hybrid Columnar Compression (HCC) Spaltenbasierter Komprimierungsmechanismus Verschiede Komprimierungstypen (FOR QUERY, FOR ARCHIVE) Deutliche Reduzierung von I/O-Operationen bei nur marginal mehr CPU-Bedarf Besonders gute Ergebnisse bei Komprimierung für Langzeitarchivierung (FOR ARCHIVE HIGH) Reduzierung der Tabellengröße von 10,5 GB auf 1,1 GB 90 % Hinweis: Vorsicht bei DML und Sperren auf komprimierten Tabellen!

52 Zusammenfassung geeignete Werkzeugwahl (ad-hoc, reproduzierbare Tests) Top-Down-Analyse und Tuning Anwendungscode Datenbankdesign Hardware zum Teil enge Abstimmung mit Entwicklung ggf. Durchführung mehrere Optimierungsläufe Ressourcenengpässe in verteilten Umgebungen EXADATA-Features können zur deutlichen Performanceverbesserung beitragen

53 Zusammenfassung für das Smart- Meter-Umfeld Verarbeitung von 2 Millionen Zählern mit Grundlast Verarbeitung von 12 Millionen Zählern entspricht 2,3 Mrd. Zählerständen Verarbeitungszeit von 22 Stunden Ladeperformance und Verarbeitungsprozesse EDM / MDM als ein System unter Verwendung geeigneter Hardware

54 Fragen?

55 Vielen Dank für Ihre Aufmerksamkeit! Referenten Lars Geldner Leiter Projekte Industrie Thomas Lehmann Systemberater Support Tel.: / Tel.: /