Erfahrungsbericht aus einem Evaluierungsprojekt einer …dbst/material/20130612_182_Geldner.pdf ·...
Transcript of 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
[email protected]@robotron.de