Erfahrungsbericht aus einem Evaluierungsprojekt einer …dbst/material/20130612_182_Geldner.pdf ·...

Erfahrungsbericht aus einem Evaluierungsprojekt einer hochtransaktionalen Datenbankanwendung auf Oracle EXADATA

Lars Geldner, Thomas Lehmann

HTW Datenbankstammtisch

Dresden, 12.06.2013

Agenda

� robotron*ecount-System bei der RWE Metering GmbH

� Smart Meter-Skalierungsprojekt

� Vorstellung EXADATA

� Tuningkonzepte / Tuningwerkzeuge

� konkrete Tuningmaßnahmen

� EXADATA-Spezifika

� Zusammenfassung

Agenda

� robotron*ecount-System bei der RWE Metering GmbH

� Smart Meter-Skalierungsprojekt

� Vorstellung EXADATA

� Tuningkonzepte / Tuningwerkzeuge

� konkrete Tuningmaßnahmen

� EXADATA-Spezifika

� Zusammenfassung

robotron*ecount bei der RWE Metering GmbH

robotron*ecount bei der RWE Metering GmbH

robotron*ecount bei der RWE Metering GmbH

Agenda

� robotron*ecount-System bei der RWE Metering GmbH

� Smart Meter-Skalierungsprojekt

� Vorstellung EXADATA

� Tuningkonzepte / Tuningwerkzeuge

� konkrete Tuningmaßnahmen

� EXADATA-Spezifika

� Zusammenfassung

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)

Smart Meter-Skalierungsprojekt

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 Überlastungstestsmit einer sehr großen Anzahl von Zählern durchzuführen

– Smart Meter-Tests auf Basis der aktuellen Systemgrundlast

Smart Meter-Skalierungsprojekt

� Teiltests Grundlast

– ZFA-Import: Import, Plausibilisierung und Export von RLM-Zeitreihen (ca. 120.000 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

Smart Meter-Skalierungsprojekt

� 2 Mio. Zähler-Test– 1.520.000 Zähler * 1 Wert = 1.520.000 Werte

– 275.000 Zähler * 96 Werte = 26.400.000 Werte

– 105.000 Zähler * 2 Kanäle * 96 Werte = 20.160.000 W erte

– � 96.160.000 Werte/d (Rohzeitreihe + Arbeitszeitreihe)

� 12 Mio. Zähler-Test– 12.000.000 Zähler * 1 Kanal * 96 Werte = 1.152.000. 000 Werte/d

– � 2.304.000.000 Werte/d (Rohzeitreihe + Arbeitszeitreihe)

Agenda

� robotron*ecount-System bei der RWE Metering GmbH

� Smart Meter-Skalierungsprojekt

� Vorstellung EXADATA

� Tuningkonzepte / Tuningwerkzeuge

� konkrete Tuningmaßnahmen

� EXADATA-Spezifika

� Zusammenfassung

EXADATA Spezifika

� abgestimmte Hardwarekonfiguration

� Scale-Out-Architektur

� optimierte Storagezugriffe

� performante Cache-Nutzung

� Oracle Real Application Cluster

Intelligent Storage Grid

• 14 High-performance low-cost storage servers

• 100 TB High Performance disk, or504 TB High Capacity disk

• 22.4 TB PCI Flash

• Intelligent Storage Server Software

Exadata Hardware Architecture

InfiniBand Network• 3 x 36-port 40Gb/s switches

• Unified server & storage network

Database Grid • 8 x Dual-processor x64 database servers OR • 2 x Eight-processor x64 database servers

� 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

Agenda

� robotron*ecount-System bei der RWE Metering GmbH

� Smart Meter-Skalierungsprojekt

� Vorstellung EXADATA

� Tuningkonzepte / Tuningwerkzeuge

� konkrete Tuningmaßnahmen

� EXADATA-Spezifika

� Zusammenfassung

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

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 PackTuning Pack

control_management_pack_access

Agenda

� robotron*ecount-System bei der RWE Metering GmbH

� Smart Meter-Skalierungsprojekt

� Vorstellung EXADATA

� Tuningkonzepte / Tuningwerkzeuge

� konkrete Tuningmaßnahmen

� EXADATA-Spezifika

� Zusammenfassung

Beispiel 1: INSERT-Optimierung

� Problemstellung: Erhöhung der Einfügeperformance

� Testfall: parallel schreibende Sessions auf 1 Tabelle

ID WERTE

1 Wert1, Wert2, Wert3; Wert4, Wert5,…

2 Wert10, Wert11, Wert12; Wert13,…

… …

PKSequence

Ad-hoc Monitoring

� Database / Cloudcontrol

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

Engpässe identifizieren

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 TOOLSpctfree 10initrans 20maxtrans 255

reverse;

Reverse Key Index

Root

ROWID IDAAAOM5AApAAAACDAAA 10

AAAOM5AApAAAACDAAB 11

AAAOM5AApAAAACDAAC 12

AAAOM5AApAAAACDAAD 13

AAAOM5AApAAAACDAAE 14

ROWID IDAAAOM5AApAAAACDAAA 01

AAAOM5AApAAAACDAAB 11

AAAOM5AApAAAACDAAC 21

AAAOM5AApAAAACDAAD 31

AAAOM5AApAAAACDAAE 41

>=5<5

10,11,12,13,14

7,831,2

Root

>=20<20

31,4121111,2

Hot blocks

� Buffer bussy waits

� Enq: TX Index contention

Root

>=5<5

10,11,12,13,147,831,2

Umsetzungsergebnis überprüfen

Engpässe beheben

� Problem: enq: SQ contention

� Lösung: Cache-Parameter der Sequence erhöhen

drop sequence SEQ_WERTE;

create sequence SEQ_WERTEminvalue 1maxvalue 9999999999999999999999999999start with 1increment by 1cache 1000;

Umsetzungsergebnis überprüfen

vorher:

Tuningergebnis

� Indexkonvertierung durchgeführt

� Indexparameter geändert

� Cacheparameter der Sequence angepasst

� geringer Anpassungsaufwand

� Reduzierung von Warteereignissen

� Beschleunigung des INSERT-Statements um 30%

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;

Engpässe identifizieren

DBMS_LOCK

� MOS ID 67680.1 – Package DBMS_LOCK Specification

� MOS ID 840840.1 – DBMS_LOCK_ALLOCATED Table cleanup

INSERT intoDBMS_LOCK_ALLOCTED

DELETE fromDBMS_LOCK_ALLOCTED

DBMS_LOCK.allocate_uniquejeder Aufruf jeder 100. Aufruf

Engpässe beheben

� Problem: enq: SQ contention

� Lösung: Anpassung der AnwendungVermeidung von DBMS_LOCK.allocate_uniqueanwendungsseitige Generierung von eindeutigen IDs

dbms_lock.allocate_unique;

dbms_lock.request;

…

…

dbms_lock.release;

Umsetzungsergebnis

voher:

Sequencen im RAC -Umfeld

create sequence SEQ_WERTEminvalue 1maxvalue 9999999start with 1increment by 1cache 1000;

SEQ_WERTE (1-1000) SEQ_WERTE (1001-2000)

INSERTINSERT INTO … VALUES (1);INSERT INTO … VALUES (2);

INSERT INTO … VALUES (1001);INSERT INTO … VALUES (3);

INSERT INTO … VALUES (1002);INSERT INTO … VALUES (1003);

Sequencen im RAC -Umfeld

� Ergebnis: IDs nicht aufsteigend nummeriert !1001 kommt vor 3

� Keine Sortierung nach ID-Spalten aus Sequenzen

ID Zeitstempel

1 04.12.2012 15:44:01

2 04.12.2012 15:44:02

1001 04.12.2012 15:44:03

3 04.12.2012 15:44:04

1002 04.12.2012 15:44:05

1003 04.12.2012 15:44:06

Sequencen Anlegen

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 val ue 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 20sequence 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 .

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 !

Agenda

� robotron*ecount-System bei der RWE Metering GmbH

� Smart Meter-Skalierungsprojekt

� Vorstellung EXADATA

� Tuningkonzepte / Tuningwerkzeuge

� konkrete Tuningmaßnahmen

� EXADATA-Spezifika

� Zusammenfassung

EXADATA -Spezifika

� verteilte Anwendungsprozesse

� Parallelisierung

� Skalierungsfähigkeit

� Oracle RAC Instanzen

– Global Cache

– Synchronisation zwischen RAC-Knoten

� Signifikantere Auswirkung von Ressourcenengpässen

Hot blocks unter RAC

SCAN-Listener

Client

ID WERTE

1 Wert1, Wert2, Wert3; Wert4, Wert5,…

2 Wert10, Wert11, Wert12; Wert13,…

… …

PK

Client Client Client. . . . .

Hot blocks unter RAC

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)

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 / 11 500) *100 = 65 %

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 !

Agenda

� robotron*ecount-System bei der RWE Metering GmbH

� Smart Meter-Skalierungsprojekt

� Vorstellung EXADATA

� Tuningkonzepte / Tuningwerkzeuge

� konkrete Tuningmaßnahmen

� EXADATA-Spezifika

� Zusammenfassung

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

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 geeigneterHardware

Fragen ?

Vielen Dank für Ihre Aufmerksamkeit!

Referenten

Lars GeldnerLeiter Projekte Industrie

Thomas LehmannSystemberater Support

Tel.: +49 351/25859 2751Tel.: +49 351/25859 2782

lars.geldner@robotron.dethomas.lehmann@robotron.de