Post on 28-Jan-2019
transcript
06.06.2018, Berlin
Jan Gorkow
Oracle PL/SQL: Performance extrem
Laufzeit-optimierte Umsetzung rechenintensiver Anwendungen
Leiter Oracle Competence Center
AGENDA
1
2
3
4
5
Kundenprojekt
Code-Optimierung und Code-Typen
Caching
Datentypen
Parallelisierung
6 Zusammenfassung
Kundenprojekt „LCR-Planungstool“
LCR: Liquidity Coverage Ratio / Mindestliquiditätsquote
Perspektivischer Ausweis der LCR-Kennziffer & Liquiditätsplanungbei einem Bankhaus für Immobilien-Finanzierung
▪ Tag-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 4Oracle PL/SQL: Performance extrem
Kundenprojekt: LCR-Planungstool - Screenshots
Seite 5Oracle PL/SQL: Performance extrem
Kundenprojekt: LCR-Planungstool – Herausforderungen
Kern-Herausforderung: Erwartung Web-üblicher Antwortzeiten Performance im Hinblick auf die Laufzeit der komplexen Berechnungen
▪ Sofortige Berücksichtigung von Simulationen
▪ Berücksichtigung von Fremdwährungen, Abschlägen usw.
▪ Komplexe Abhängigkeiten von Werten untereinander
▪ Kaum Vorberechnungen möglich bzw. praktikabel
▪ Lösung durch Best Practice Ansätze dieses Vortrages
Weitere technische Herausforderungen
▪ 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
PL/SQL Optimizer &Code Typen
Was kann bzw. macht der PL/SQL Optimizer?
Wodurch unterscheiden sich die verfügbaren Code Typen bzw. Kompilierungsarten?
Seite 7Oracle PL/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 LOOPv3 := v1 + v2;…
END LOOP;
v3 := v1 + v2;FOR i IN 1 .. 10 LOOP
…END LOOP;
IF TO_NUMBER(v1) = 5OR v2THEN …
IF v2OR TO_NUMBER(v1) = 5THEN …
PL/SQL Optimizer
Seite 8Oracle PL/SQL: Performance extrem
PL/SQL-Optimizer
Session- bzw. System-Parameter 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
▪ 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 9Oracle PL/SQL: Performance extrem
PL/SQL-Kompilierung: Interpreted vs. Native
Steuerung via Session- bzw. System-Parameter 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
NativerMaschinencode
EXECUTE …
PL/SQL Interpreter Engine
Anweisungsausführung Anweisungsausführung
Seite 10Oracle PL/SQL: Performance extrem
Native Kompilierung von Built in Packages
Im Standard sind sämtliche Built in Packages interpretiert kompiliert
Änderung in native Kompilierung:
▪ Oracle-Skript dbmsupgnv.sql im Upgrade-Mode ausführen
▪ Rückänderung per dbmsupgin.sql
▪ Empfehlung: Anpassung von PLSQL_CODE_TYPE auf System-Ebene
Performancetest:
BEGINFOR i IN 1 .. 500000LOOP
DBMS_OUTPUT.put_line (DBMS_RANDOM.VALUE ());END LOOP;
END;/
1,375
1,625
NATIVE
INTERPRETED
Laufzeit in s
Seite 11Oracle PL/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 BODYREUSE SETTINGS;
Caching
Performance-Steigerung durch Caching
Caching-Mechanismen
Seite 13Oracle PL/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 14Oracle PL/SQL: Performance extrem
Function Result Cache
Eingeführt mit (Enterprise Edition)
Speicher-Darstellung einer Oracle-Instanz
Oracle - Instanz
SGA
Shared Pool
Library Cache
Shared SQLArea
Private SQLArea (opt.)
Data Dictionary
Cache
Server ResultCache
ReservedPool
…
LargePool
DatabaseBufferCache
In-MemoryColumnStore (opt.)
Fixed SGA
Java Pool
Streams Pool
PGA
SQL Work Areas
Session Memory
Private SQL Area
Redo Log Buffer
Server Result Cache
SQL QueryResult Cache
PL/SQL FunctionResult Cache
Seite 15Oracle PL/SQL: Performance extrem
Function Result Cache – Parametrisierung und Verwendung
Speicherreservierung (Server Result Cache insgesamt)
▪ via Parameter RESULT_CACHE_MAX_SIZE
Weitere Parameter
▪ RESULT_CACHE_MAX_RESULT
▪ RESULT_CACHE_REMOTE_EXPIRATION
RESULT_CACHE - Klausel
FUNCTION get_stock_price_rc (isin IN stock_price.isin%TYPE)RETURN stock_price.price%TYPERESULT_CACHE
IS…
Seite 16Oracle PL/SQL: Performance extrem
Function Result Cache – Funktionsweise und Vorteile
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 17Oracle PL/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 18Oracle PL/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
▪ In allen Oracle Editionen verfügbar
▪ 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 19Oracle PL/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 FunctionResult Cache
PGA
PL/SQL-Variablen,Assoziative Arrays
PROCEDURE process_data(…)v_data [array];
BEGINv_data := get_data(…);… v_data[key] * v_data[key]……
Applikation,Request, …
Seite 20Oracle PL/SQL: Performance extrem
Caching mittels Application Context
Application Context: Key Value ListeKeys und Values sind Strings
Kann sowohl Session-abhängig als auch Session-übergreifend genutzt werden
Context anlegen
CREATE OR REPLACE CONTEXT global_cacheUSING pac_context_cachingACCESSED GLOBALLY;
Context-Werte über angegebenes Package unter Verwendung der Routine dbms_session.set_context setzen.
Wert-Abruf erfolgt mittels sys_context
Seite 21Oracle PL/SQL: Performance extrem
Caching mittels Application Context
Vorteile
▪ Session-übergreifend nutzbar
▪ SQL-Zugriff auf alle Werte in globalen Contexten über View global_contextmöglich
SELECT *FROM global_context;
Nachteile
▪ Eigenes Management-Package erforderlich
▪ Ausschließlich Ablage von Strings möglich
Datentypen
Wahl der optimalen numerischen Datentypen
Performance vs. Genauigkeit
Seite 23Oracle PL/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
Seite 24Oracle PL/SQL: Performance extrem
Nutzung von Fließkommatypen
BINARY_FLOAT & BINARY_DOUBLE
▪ Keine Overflow- / Underflow-Exceptions
▪ Validierungsprüfung via Konstantenz.B. BINARY_DOUBLE_NAN, BINARY_DOUBLE_MAX_NORMAL
Genauigkeitsverlust bei Verwendung von Fließkommatypen
▪ Ergebnis-Rundungen bei Rechenoperationen, z.B.1015 + 0,01 = 1015
▪ Ungenaue Darstellung dezimaler Werte, z.B.0,1 + 0,2 != 0,3
Seite 25Oracle PL/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
▪ z.B. SIMPLE_INTEGER wechselt Vorzeichen
Seite 26Oracle PL/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
Laufzeit je Code Type in s
0,641
1,094
1,094
0,704
2,094
3,984
SIMPLE_INTEGER
SIMPLE_DOUBLE
BINARY_DOUBLE
PLS_INTEGER
NUMBER
INTEGER
INTERPRETED
0,156
0,266
0,281
0,344
1,578
3,391
SIMPLE_INTEGER
SIMPLE_DOUBLE
BINARY_DOUBLE
PLS_INTEGER
NUMBER
INTEGER
NATIVE
Seite 27Oracle PL/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 29Oracle PL/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 30Oracle PL/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 31Oracle PL/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 32Oracle PL/SQL: Performance extrem
Parallelisierung – Variante II: Direkte Nutzung des Schedulers
Erzeugung der Parallelprozesse via Scheduler
▪ Optimierte Job-Styles
▪ Ab 11.1: Lightweight-Jobs Reduzierte Metadatenpersistierung
▪ Ab 12.2: In Memory Full-Jobs Kompletter Verzicht auf Persistierungen
▪ Erfordern 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 33Oracle PL/SQL: Performance extrem
Hauptprozess
Parallelisierung – Variante II: Direkte Nutzung des Schedulers
Vorbereitung desJob-Definition-Array
Anlage der Jobs
Parallelprozesse
Routine 1 Routine 2 Routine …
Scheduler
Warten auf Rückmeldungen
aus Pipe
Rückmeldung viaDBMS_PIPE
Anlage einerprivaten Pipe
Entfernung derprivaten Pipe
Seite 34Oracle PL/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
Zusammen-fassung
Caching
▪ Function Result Cache
▪ PGA Caching
▪ Kombination beider sinnvoll
Automatische Code Optimierung
▪ Level 3 Automatisches Inlining
Native Kompilierung
▪ 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
Franklinstr. 28/2910587 Berlin
Tel: +49 (0)30 443232 0
Jan Gorkow
jan.gorkow@sd-c.de
Leiter Oracle Competence Center
Testsystem
Sämtliche dargestellten Messwerte sind auf folgendem System ermittelt worden
▪ Intel Core i7 vPro, 2,8 GHz, Quad-Core mit Hyper Threading, 6MB L3 Cache
▪ 32 GB RAM
▪ Oracle 12.1.0.2 EE auf Windows 8.1