PL/SQL Performance extrem - doag.org · PDF filePL/SQL Performance extrem Seite 8...

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


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


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

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


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


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

…


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

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


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


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


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


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;

/


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


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


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


Testfall

100.000.000 Typ-reine Additionen von 1 zu einem laufenden Wert

Ausführung in interpretierter sowie nativer Kompilierung

Numerische Datentypen - Performancevergleich


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

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


Hauptprozess


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


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


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

[email protected]

Leiter Oracle Competence Center

PL/SQL Performance extrem - doag.org · PDF filePL/SQL Performance extrem Seite 8...

Documents

Transcript of PL/SQL Performance extrem - doag.org · PDF filePL/SQL Performance extrem Seite 8...