oracle pl/sql: performance extrem - doag.org · oracle pl/sql: performance extrem seite 8...

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


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?


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


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


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


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


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


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


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


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…


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 !!!


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


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


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, …


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


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


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


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


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


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


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


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


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.


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


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


Hauptprozess


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


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


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

[email protected]

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

oracle pl/sql: performance extrem - doag.org · oracle pl/sql: performance extrem seite 8...

Documents