18.11.2015, Nürnberg
Ansprechpartner
PL/SQL Performance extrem
Laufzeit-optimierte Umsetzung rechenintensiver Anforderungen
Jan Gorkow
- Das sind wir!
Eckdaten
Gründung: 2003
Standorte:
Berlin-Mitte – im eWerk
Hamburg – am Gänsemarkt
Mitarbeiter:
über 80 IT-Spezialisten
davon 65 festangestellt
AGENDA
1
2
3
4
5
Kundenprojekt
Caching
Code-Optimierung und Code-Typen
Datentypen
Parallelisierung
6 Zusammenfassung
Kundenprojekt „LCR-Planungstool“
Planung der meldepflichtigen LCR-Kennziffer bei einemBankhaus für Immobilien-Finanzierung
Tages-genaue Vorschau über einen Zeitraum von bis zu einem Jahr basierend auf
täglich aktualisierten Ist-Daten
Szenarien-basierten Simulationen verschiedenster Geschäftsvorfälle
Detaillierte Darstellung der Bestände, Cashflows und Deckungsstöcke sowie Aufschlüsselung der LCR-Teilkomponenten und der Liquiditätsplanung
Technologie:
Seite 5PL/SQL Performance extrem
Kundenprojekt: LCR-Planungstool - Screenshots
Seite 6PL/SQL Performance extrem
Kundenprojekt: LCR-Planungstool – Herausforderungen
Kern-Herausforderung: Erwartung Web-üblicher Antwortzeiten Performance im Hinblick auf die Laufzeit der Berechnungen
Technische Herausforderungen
Komplexe und umfangreiche Berechnungen in PL/SQL
Sofortige Berücksichtigung von Simulationen
Berücksichtigung von Fremdwährungen
Komplexe Abhängigkeiten von Werten untereinander
Kaum Vorberechnungen möglich
Lösung durch folgende Ansätze
Matrix-Aufbau
Langsames Parsing des serverseitig erzeugten HTML-Codes im Browser
Ajax – basiertes Lazy-Loading
Datenmenge
Tägliche Aktualisierung der Ist-Daten, u.a. mehrere 100.000 Cashflows
Aufbereitung per vorgelagertem ETL-Prozess und Speicherung nach SCD-Mimik
Caching
Performance-Steigerung durch Caching
Caching-Mechanismen
Seite 8PL/SQL Performance extrem
Performance-Steigerung durch Caching
Grundprinzip: Ergebnisse einmalig ableiten und vielfach nutzen
Caching von…
SQL-Ergebnissen zur Reduktion von…
Kontext-Switches zwischen PL/SQL und SQL
Abfrage-Ausführungen
IO und CPU
PL/SQL-Ergebnissen zur Reduktion von…
Code-Ausführungen
Code-Laufzeit und somit CPU
„Richtiges“ Caching
Caching ausschließlich im RAM
Mehrfach-Nutzung abgeleiteter Werte
Cache-Zugriff schneller als Wert-Ableitung
Seite 9PL/SQL Performance extrem
Function Result Cache
Eingeführt mit (Enterprise Edition)
Speicher-Darstellung einer Oracle-Instanz
Instanz
SGA
Shared Pool
Library Cache
Shared SQL
Area
Private SQL
Area (opt.)
Data
Dictionary
Cache
Server
Result
Cache
Reserved
Pool
…
Large
Pool
Database
Buffer
Cache
In-Memory
Column
Store (opt.)
Fixed
SGA
Java
Pool
Streams
Pool
PGA
SQL Work Areas
Session Memory
Private SQL Area
Redo Log Buffer
Server Result Cache
SQL Query
Result CachePL/SQL Function
Result Cache
Seite 10PL/SQL Performance extrem
Function Result Cache – Überblick
Funktionsweise
Für Caching vorgesehene Funktion wird ausgeführt
Ergebnis wird im Cache hinterlegt,Key besteht aus Funktionsname und Parameterwerten
Weitere Aufrufe zu identischem Parameterset werden aus Cache bedient
LRU – Algorithmus integriert
Vorteile des Function Result Cache
Session-übergreifend
Cache-Einträge werden bei Änderung zugrunde liegender Tabellen automatisch ungültig
Achtung!
Vorsicht bei dynamischem SQL !!!
Seite 11PL/SQL Performance extrem
Function Result Cache - Parametrisierung
Speicherreservierung (Server Result Cache insgesamt)
via Parameter RESULT_CACHE_MAX_SIZE
Weitere Parameter
RESULT_CACHE_MAX_RESULT
RESULT_CACHE_REMOTE_EXPIRATION
RESULT_CACHE - KlauselFUNCTION get_stock_price_rc (isin IN stock_price.isin%TYPE)
RETURN stock_price.price%TYPE
RESULT_CACHE
IS
…
Seite 12PL/SQL Performance extrem
Function Result Cache – Unterstützende Objekte
Package DBMS_RESULT_CACHE
Statusabfrage & Memory-Report
Aktivierung / Deaktivierung Bypassing
Einträge auf Basis von Abhängigkeiten entfernen
Cache-Statistiken: View V$RESULT_CACHE_STATISTICS
Seite 13PL/SQL Performance extrem
PGA - Caching
Caching über lokale / globale PL/SQL-Variablen
Nutzung assoziativer Arrays auf Basis von PL/SQL-Types
String als Key
Beliebig komplexe Values
Vorteile
Erheblich performanter als Function Result Cache
In eigener Session individuell manipulierbar
Nachteile
Caching auf Session-Ebene
Höherer Speicherverbrauch, redundante Daten im Speicher
Stateless – Applikationen: PGA-Caching nur für Zeitraum einer Request-Verarbeitung
Seite 14PL/SQL Performance extrem
process_data ruft get_data auf und bekommt beim zweiten Aufruf die Daten sehr schnell zurück, nutzt diese beliebig oft und verwirft die lokal gecachten Daten nach Abschluss der Verarbeitung
get_data übernimmt einmalige Selektion undAufbereitung der Daten Ergebnis: im Result Cache hinterlegtes assoziatives Array
Sinnvolle Kombination beider Caching-Techniken
FUNCTION get_data(…)
RETURN [array type]
RESULT_CACHE IS
v_data [array type];
BEGIN
… SELECT …
v_data[key] := value;
RETURN v_data;
SGA
PL/SQL Function
Result Cache
PGA
PL/SQL-Variablen,
Assoziative Arrays
PROCEDURE process_data(…)
v_data [array];
BEGIN
v_data := get_data(…);
… v_data[key] * v_data[key]…
…
Applikation,
Request, …
PL/SQL Optimizer &Code Typen
Was kann bzw. macht der PL/SQL Optimizer?
Wodurch unterscheiden sich die verfügbaren Code Typen bzw. Kompilierungsarten?
Seite 16PL/SQL Performance extrem
PL/SQL-Optimizer
Eingeführt mit
Konfigurierbare Optimierung von PL/SQL-Code im Rahmen der Kompilierung
Inhalt der *_SOURCE – Views undlogisches Verhalten des Codes unverändert
Optimierung wirkt sich ausschließlich auf das Kompilat aus
Beispiele
… v1 + v2 …
IF v1 + v2 = …
gv1 := v1 + v2;
IF gv1 = …
FOR i IN 1 .. 10 LOOP
v3 := v1 + v2;
…
END LOOP;
v3 := v1 + v2;
FOR i IN 1 .. 10 LOOP
…
END LOOP;
IF func(v1) = 5
OR v2
THEN …
IF v2
OR func(v1) = 5
THEN …
PL/SQL
Optimizer
Seite 17PL/SQL Performance extrem
PL/SQL-Optimizer
Session- bzw. System-Variable PLSQL_OPTIMIZE_LEVEL
0 – Keine Optimierung, Kompilierungsverhalten wie in Oracle 9i, z.B.keine semantische Identität von BINARY_INTEGER & PLS_INTEGER
1 – Eliminierung unnötiger Berechnungen und Exceptions,keine Änderung der Anweisungs-Reihenfolge
2 – Default seit 10g: Code-Transformationen und manuelles Inlininglokaler Routinen via PRAGMA INLINE (subprogram, ‘YES‘)
3 – Automatische Ermittlung von Inlining-Möglichkeiten, dies kann viaPRAGMA INLINE (subprogram, ‘NO‘) ausgeschlossen werden
Inlining
INLINE PRAGMA ist ein Hint, wird also nicht zwingend von Oracle befolgt
Pragma kann auf einzelne Aufrufe oder jeglichen Aufruf eines Unterprogramms angewendet werden
Nach Oracle-eigenen Tests Performance-Steigerungen bis zu 20%
Führt zu größerem Kompilat benötigt mehr Speicher bei der Ausführung
Seite 18PL/SQL Performance extrem
PL/SQL-Kompilierung: Interpreted vs. Native
Steuerung via Session- bzw. System-Variable PLSQL_CODE_TYPE
INTERPRETED (Default)
Schnellere Kompilierung
Langsamere Ausführungaufgrund Interpreter-Overhead
Für Debugging zwingend
NATIVE
Aufwendigere Kompilierung
Schnellere Ausführung bei höherem Speicherverbrauch
Kein Debugging möglich
CREATE PACKAGE BODY …
IS
…
System-unabhängiger
Bytecode
Nativer
Maschinencode
EXECUTE …
PL/SQL Interpreter Engine
Anweisungsausführung Anweisungsausführung
Seite 19PL/SQL Performance extrem
Native Kompilierung von Build In Packages
Im Standard sind sämtliche Build In Packages interpretiert kompiliert
Änderung in native Kompilierung:
Empfehlung: Anpassung von PLSQL_CODE_TYPE auf System-Ebene
Oracle-Skript dbmsupgnv.sql im Upgrade-Mode ausführen
Rückänderung per dbmsupgin.sql
Performancetest:
BEGIN
FOR i IN 1 .. 1000000
LOOP
DBMS_OUTPUT.put_line ('A');
END LOOP;
END;
/
Seite 20PL/SQL Performance extrem
Persistierung der Kompilierungseigenschaften
Code-Type und Optimierungslevel werden auf Artefakt-Ebeneim Data Dictionary persistiert
View *_PLSQL_OBJECT_SETTINGS
Wiederverwendung der Einstellungen
ALTER PACKAGE pac_tracing COMPILE BODY
REUSE SETTINGS;
Datentypen
Wahl der optimalen numerischen Datentypen
Performance vs. Genauigkeit
Seite 22PL/SQL Performance extrem
Numerische Datentypen in Oracle
Oracle bringt eine Reihe numerischer Datentypen für PL/SQL mit, z.B.:
NUMBER: extrem flexibel und genaubei größtem Datenbereich
INTEGER: Ganzzahlige NUMBER-Werte
PLS_INTEGER: 32 Bit-INTEGER
BINARY_FLOAT: 32 Bit-Fließkommazahl
BINARY_DOUBLE: 64 Bit-Fließkommazahl
Hardware-basierte Arithmetik
Grundsätzlich performanter,insbesondere bei nativer Kompilierung
BINARY_FLOAT & BINARY_DOUBLE
Keine Overflow- / Underflow-Exceptions
Validierungsprüfung via Konstantenz.B. BINARY_DOUBLE_NAN, BINARY_DOUBLE_MAX_NORMAL
Seite 23PL/SQL Performance extrem
Numerische Datentypen - Neu seit
SIMPLE_ - Typen
SIMPLE_INTEGER
SIMPLE_FLOAT
SIMPLE_DOUBLE
Basierend auf entsprechenden PLS_- bzw. BINARY_-Typen
Ergänzt um NOT NULL-Constraint
Geringfügig schneller, da zur Laufzeit entsprechende Prüfungen entfallen
Keine Overflow- / Underflow-Exceptions
SIMPLE_INTEGER wechselt Vorzeichen
Genauigkeitsverlust bei Verwendung von Fließkommatypen
Ergebnis-Rundungen bei Rechenoperationen
Ungenaue Darstellung dezimaler Werte, z.B. 0.1 + 0.2 != 0.3
Seite 24PL/SQL Performance extrem
Testfall
100.000.000 Typ-reine Additionen von 1 zu einem laufenden Wert
Ausführung in interpretierter sowie nativer Kompilierung
Numerische Datentypen - Performancevergleich
Seite 25PL/SQL Performance extrem
Hohe Genauigkeit oder maximaler Wertebereich erforderlich
NUMBER
Integer-Berechnungen bis 2^31
PLS_INTEGER
NULL-Werte ausgeschlossen: SIMPLE_INTEGER
Fließkomma-Unschärfen vertretbar, Performance vorrangig
BINARY_DOUBLE
NULL-Werte ausgeschlossen: SIMPLE_DOUBLE
Grundsätzlich
Native Kompilierung nutzen
Numerische Datentypen - Empfehlungen
Parallelisierung
Möglichkeiten der parallelisierten Ausführung von PL/SQL-Code
DBMS_PARALLEL_EXECUTE
Scheduler-Jobs
Inter-Prozess-Kommunikation
Seite 27PL/SQL Performance extrem
Moderne Hardware unterstützt Parallelisierung
zunehmende Anzahl Cores je CPU
zunehmende Anzahl CPUs je Server
Oracle DBMS selbst skaliert hochgradig
Parallele Ausführung von Sessions
Parallelisierte Abarbeitung von SQL
RAC: Parallelisierung über mehrere Server
Aber:
PL/SQL wird zunächst nur in einem Thread ausgeführt!!!
Parallelisierung
Seite 28PL/SQL Performance extrem
Eingeführt mit
Hintergrund: Parallelisierung von Updates auf Massendatenim Warehouse Umfeld
Vorgehen
Parallelisierung – Variante I: DBMS_PARALLEL_EXECUTE
Task erzeugen
Chunks bilden
Task ausführen
Task entfernen
Vergabe einer Bezeichnung für den Task
Erzeugung der Arbeitspakete auf Basis einer zugenerierenden Liste von Start- und End-IDs
Festlegung des auszuführenden Codes und desParallelisierungsgrades. Diese Routine kehrt erst nachAbarbeitung aller Chunks zurück.
House Keeping.
Seite 29PL/SQL Performance extrem
Vorteile
Prozesserzeugung integriert:Interne Nutzung des Schedulers
Prozesssynchronisation integriert:RUN_TASK-Aufruf kommt erst zurück, wenn alle Chunks abgearbeitet wurden
Parallelisierungsgrad konfigurierbar
Logging- und Monitoring integriert
Nachteile
Vielzahl impliziter Transaktionen
Hoher Overhead aufgrund vieler Metadaten
Zeitaufwendige Synchronisation nach Abschluss der Verarbeitungsprozesse
Parallelisierung – Variante I: DBMS_PARALLEL_EXECUTE
Seite 30PL/SQL Performance extrem
Parallelisierung – Variante II: Direkte Nutzung des Schedulers
Erzeugung der Parallelprozesse via Scheduler
Reduzierte Metadaten durch Lightweight-Jobs
Erfordert Definition von Scheduler-Programs
Job-Definition-Array
Vorbereitung sämtlicher Job-Definitionen inkl. Parametrisierung
Anlage aller Jobs über einen Aufruf nur eine Transaktion
Inter-Prozess-Kommunikation zur Prozesssynchronisation erforderlich
DBMS_PIPE
Nutzung einer privaten Pipe
Status-Rückmeldung der Parallelprozesse an den Hauptprozess
Hauptprozess wartet, bis alle Rückmeldungen vorliegen
Sehr schnell und transaktionslos
Seite 31PL/SQL Performance extrem
Hauptprozess
Parallelisierung – Variante II: Direkte Nutzung des Schedulers
Vorbereitung des
Job-Definition-Array
Anlage der Jobs
Parallelprozesse
Routine 1 Routine 2 Routine …
Scheduler
Warten auf
Rückmeldungen
aus Pipe
Rückmeldung via
DBMS_PIPE
Anlage einer
privaten Pipe
Entfernung der
privaten Pipe
Seite 32PL/SQL Performance extrem
Vorteile
Minimale Metadaten, geringe Anzahl impliziter Transaktionen
Sehr schneller Start der parallelen Prozesse
Schnelle Synchronisation nach Abschluss des letzten Prozesses
Insgesamt weniger Overhead & bessere Performance
Nachteile
Aufwendigere Umsetzung, da alles „Marke Eigenbau“
Kein integriertes Logging oder Monitoring
Parallelisierung – Variante II: Direkte Nutzung des Schedulers
Zusammenfassung
Caching
Function Result Cache
PGA Caching
Kombination beider sinnvoll
Automatische Code Optimierung
Level 3 Automatisches Inlining
Native Compilierung
Anwendung auf sämtlichen Code
Einsatz optimaler Datentypen
Nach Möglichkeit Typen mit CPU-basierter Arithmetik
SIMPLE_-Typen:Maximale Performance vs. Dezimal-Genauigkeit und Überlaufprüfungen
Parallelisierung
Maximale Performance via „Marke Eigenbau“ per Scheduler
Inter-Prozess-Kommunikationper DBMS_PIPE
www.sd-c.de
Vielen Dank!
SD&C Solutions Development &Consulting GmbH
Mauerstraße 7910117 Berlin
Tel: +49 (0)30 443232 0
Jan Gorkow
Leiter Oracle Competence Center