In-Memory Techniken der Oracle Datenbank Christoph Blessing Server Technologies Customer Center ORACLE Deutschland B.V. & Co. KG

Agenda • In-Memory – Ein Markttrend • Übersicht der Oracle Memory-Strukturen • Keep Cache • Result Cache

• Verwendung von SSD: Oracle Flash Cache • Speicheroptimierende Techniken der Datenbank

• Oracle TimesTen In-Memory Database • Architektur und Funktionen • In-Memory Database Cache

In-Memory – Ein Markttrend

In-Memory und Real-Time – ein Gespann Autorisierung, Online Abrechnung, Lokations-basierte Dienste

Markt Daten, Marktereignisse, Auftragszusammenführung, Trading

Real-Time Analytics Interaktive Dashboards Data Mart, Scorecard

eCommerce, Personalisierung, Real-Time Ad Serving

Real-Time Applikationen Instantly Responsive / Highly Scalable / Always-On

Mainstream 64-bit Prozessoren

Schnelle Netzwerke

Schlüsseltechnologien

Genügend RAM

Applikations-Antwortzeiten Warum sind diese entscheidend? • Service Level Agreements (SLA) nicht eingehalten • Aufgrund hoher Antwortzeiten

• Bestimmt Mitarbeiterproduktivität und Kundenzufriedenheit • Kundenabwägungen • Mitbewerb liefert bessere Antwortzeiten

• Unternehmensziele nicht erreicht und abnehmende Profitabilität • Auswirkungen auf das Geschäftsergebnis

Übersicht der Oracle Memory-Strukturen

Architektur des Arbeitsspeichers

Keep Cache

Der Keep Cache DB Buffer Cache

Least Recently Used

2k Blöcke

Most Recently Used Default Cache

4k Blöcke

16k Blöcke Keep Cache

Recycle Cache

Free / Pinned / Dirty Buffer

• Der Keep Cache ist Bestandteil des Buffer Caches • Die Buffer im Keep Cache werden so lange gefüllt, bis für das Aufnehmen neuer Blöcke der älteste geleert wird • Die Konfiguration des Keep Cache erfolgt über den Parameter DB_KEEP_CACHE_SIZE • Der Recycle Cache enthält Blöcke, die nach Nutzung sofort wieder aus dem Arbeitsspeicher entfernt werden (DB_RECYCLE_CACHE_SIZE)

Steuerung des Keep Cache • Die Storage-Klausel bestimmt den jeweiligen Cache: CREATE TABLE test(a NUMBER, b VARCHAR2(20)) STORAGE (BUFFER_POOL KEEP | RECYCLE | DEFAULT);

• Mit KEEP wird jede NOCACHE-Klausel überschrieben • Bei einer partitionierten Tabelle erben die einzelnen Partitionen die Speicherorteinstellung

• Der Speicherort für Blöcke einer Tabelle oder eines Index kann im laufenden Betrieb verändert werden ALTER TABLE test STORAGE (BUFFER_POOL KEEP);

ALTER TABLE test STORAGE (BUFFER_POOL DEFAULT); SELECT buffer_pool FROM dba_tables WHERE table_name = 'TEST';

Beispiel Oracle OLAP Nutzung der Architekturvorteile • Zusätzlicher Performance-Boost durch Persistierung des Analytic Workspace im Flash Cache alter table olaptrain.aw$salestrack storage(buffer_pool keep);

• Parallelisiertes Lesen und Schreiben durch partitionierte Cubes

Query Result Cache

Konzept und Einsatz des Result Cache • Eigener Cache im Shared Pool, per Default vorhanden • Automatische Invalidierung • Refresh durch erneute Ausführung des SQL Statements • Zwei Konfigurationsmöglichkeiten: • Server-side SQL Query und PL/SQL Function Result Cache • Client-side OCI Result Cache

 Unterschied zum Buffer Pool: es wird das finale Datenset vorgehalten (weniger logical I/O)

Anwendungsbeispiele • Lang andauernde teure Abfragen • Sich wiederholende Abfragen • Rechenintensive PL/SQL-Funktionen • Randbedingungen • Abfragen mit kleinen Ergebnismengen • Ausreichend Memory steht zur Verfügung • Tabellen sind relativ statisch

• Ziel: SQL Performance mit möglichst einfachen Mitteln erhöhen

Result Cache: Ein Teil des Shared Pool SGA

PGA

2

Shared Pool Private SQL Area

3 Data Dictionary Cache

DB Buffer Cache Library Cache

Result Cache

Cursors

1

Redo Log Buffer DB Files

SQL Area

Java Pool

Large Pool

Streams Pool

Misc.

Quelle: http://www.oracle.com/technetwork/articles/datawarehouse/vallath-resultcache-rac-284280.html

Parameter zum Result Cache RESULT_CACHE_MAX_RESULT RESULT_CACHE_MAX_SIZE RESULT_CACHE_MODE RESULT_CACHE_REMOTE_EXPIRATION

5 (%) abhängig vom OS MANUAL/FORCE 0 (min)

• RESULT_CACHE_MAX_SIZE: Gesamtgröße des reservierten Bereichs für den Result Cache im Shared Pool • RESULT_CACHE_MAX_RESULT: Prozentualer Anteil am gesamten Result Cache für die einzelnen Ergebnisse • RESULT_CACHE_REMOTE_EXPIRATION: Zeitdauer bei Remote Objekt-Nutzung, wie lange das Resultat in Minuten im Cache verbleibt

Parameter RESULT_CACHE_MODE • Falls RESULT_CACHE_MODE=MANUAL gesetzt ist, dann einen Hint im Statement einfügen wie z.B. SELECT /*+ result_cache */ count(*) FROM sales

• Falls RESULT_CACHE_MODE=FORCE gesetzt ist, dann erfolgt ein automatisches Einfügen des Hints im Root-SELECT • Ausnahmen mit Hint /*+ NO_RESULT_CACHE */ SELECT /*+ no_result_cache */ count(*) FROM sales

...

• Der Result Cache hat eine eigene LRU-Liste, nach der alte Results für neue Einträge entfernt werden

Query mit Result Cache Hint SQL> SELECT /*+ result_cache */ COUNT(*), SUM(salary) FROM hr.bigemp group by department_id ORDER BY department_id; ------------------------------------------------------------------------------------------------| Id

| Operation

| Name

| Rows

| Bytes | Cost (%CPU)| Time

------------------------------------------------------------------------------------------------|

0 | SELECT STATEMENT

|

|

11 |

55 |

|

1 |

| 91myw5c1bud0mcn64g3d0ykdhm |

|

|

|

2 |

|

3 |

RESULT CACHE SORT GROUP BY

|

TABLE ACCESS FULL| BIGEMP

2229

(2)| 00:00:34 |

|

11 |

55 |

2229

(2)| 00:00:34

|

876K|

4280K|

2201

(1)| 00:00:34

Statistics ----------------------------------------------------------------------------0

recursive calls

0

db block gets

0

consistent gets

0

physical reads

0

redo size

696

bytes sent via SQL*Net to client

419

bytes received via SQL*Net from client

2

SQL*Net roundtrips to/from client

0

sorts (memory)

0

sorts (disk)

12

rows processed

Tipps zum Einsatz von Result Cache • Der Einsatz des Result Cache ist sinnvoll bei • Verwendung von eher statischen SQL Statements • Häufiger „Read Only“-Nutzung (nur wenige Invalidierungen) • Rechenintensiven (teuren) Operationen

• Anders als beim Buffer Cache liegen finale Result Sets vor, keine Datenbankblöcke

• Unterschied Result Cache zu Materialized Views • Alle außer der ersten Anfrage aus dem Memory beantwortet • Automatisches Refresh mit originalem SQL nach Invalidierung • Keine Persistenz und kein Rewrite

http://www.oracle.com/global/de/community/dbadmin/tipps/result_cache/index.html

Verwendung von SSD: Oracle Flash Cache

Oracle Database Smart Flash Cache

Hot Data 16 GB SGA Memory

120 GB Flash Cache

Extended Buffer Cache

Cold Data 360 GB Hard Disks

Warm Data

• Angebundene oder eingebaute SSD Devices / Flash Cards wirken als Level 2 Cache für die SGA • Derzeit für Oracle Solaris und Oracle Enterprise Linux verfügbar • Lässt sich auch in Kombination mit Flash Disks verwenden (ganze Tablespaces auf SSD Storage)

Den Buffer Cache transparent erweitern • Zum Aktivieren des Flash Cache zwei Parameter setzen: DB_FLASH_CACHE_FILE DB_FLASH_CACHE_SIZE

0 (Default) – auch zum Leeren

• Storage-Klausel steuert das Caching: CREATE TABLE test(a NUMBER, b VARCHAR2(20)) STORAGE (FLASH_CACHE KEEP | NONE | DEFAULT);

• KEEP: Ein Objekt wird dauerhaft im Flash Cache gehalten • NONE: Ein Objekt wird niemals im Flash Cache gehalten • DEFAULT: „Herausalternde“ Objekte des Buffer Cache werden im Flash Cache abgelegt

Flash Cache vor allem für DWHs von Interesse • Im Data Warehouse wird auf die gleichen Datenobjekte über längere Zeit lesend zugegriffen  Der Einsatz von Flash wird bei Read-Only / Read-Mostly Daten empfohlen, wenn • db file sequential read ein Top Wait Event ist • Genügend CPU-Ressourcen verfügbar sind • Es Hinweise gibt, dass ein größerer Buffer Cache Abhilfe schafft

Speicheroptimierende Techniken der DB

Advanced Compression • Advanced Compression in Oracle 11g für: • • • •

Strukturierte und unstrukturierte Daten Backups Data Pump exports Data Guard – Redo Transport

• Reduziert Ressourcenanforderungen und Kosten! • Storage, weniger I/Os, effiziente Buffer Cache Nutzung …

• Storage-Einsparungen zwischen Faktor 2-4 typisch DML uncompressed

PCTFREE reached: Compression!

Further DML uncompressed

PCTFREE reached: Compression! Overhead Free Space uncompressed compressed

PoC Kompression SAP/ERP (FI/CO) Ergebnisse (SAP Subsystem FFS) • Erreichte Einsparung durch Kompression = 46% DB – Größe vor Reorganisatio n in GByte Oracle 10.2

DB – Größe nach Reorganisatio n in GByte Oracle 10.2

Einsparung durch Reorganisati on in % Oracle 10.2

DB – Größe nach Kompressio n in GByte Oracle 11.2

Einsparung durch Kompressio n in % Oracle 11.2

Einsparung durch Kompression in GByte Oracle 11.2

GesamtEinsparung in %

837 GB

554 GB

34%

296 GB

46%

258 GB

65%

• Größter Einsparungseffekt durch • Tabellen - Kompression (75% Anteil) • Index - Kompression (24% Anteil)

• Durchschnittliche Performanceverbesserung Leseoperationen ca. 10-15% Updateoperationen ca. 17%

Oracle 11.2

Best Practices OLTP Table Compression • Komprimieren der zehn größten Tabellen • 20% der Tabellen verbrauchen 80% des Speicherplatzes

• Bessere Kompressionsraten mit größeren Blöcken • Höhere Wahrscheinlichkeit mehrfacher gleicher Werte

• Sortiertes Laden nach nicht selektiven Spalten • B-Tree Index Kompression • Index validieren und INDEX_STATS analysieren index_stats.opt_compr_count liefert Prefix Länge N index_stats.opt_compr_pctsave liefert Einsparung in % CREATE INDEX idx_comp ON ... COMPRESS N;

• Bitmap Indexes sind an sich hoch komprimiert • Geeignet für niedrige bis mittlere Kardinalität

Partitionierung • Splittet große Objekte in kleinere • Vollkommen transparent für Applikation • Einfaches und effizientes Space Management • Minimierung von Contention auf Objekten • Partition Pruning

Table T1

Partitioned Table T1

Entkoppelt die Relation zwischen Datenwachstum und Performance SAP Note 1333328 – SAP Partitioning Engine

Index I1

Partitioned Index I1

Weitere optimierende Techniken • Parallelisierung • Materialized Views • Cube-organized Materialized Views • Query Rewrite zielt auf einen OLAP-Cube • Ersetzt unzählige Materialized Views • Leitet sich von einem relationalen Star Schema bzw. Data Mart ab • Transparent für Applikationen Zeit

• OLAP

Wann? Reg

Zeit

Region Wo? Org. Linie

Prod Produkt Was?

Oracle TimesTen In-Memory Database

Entwicklung der TimesTen In-Memory DB

2010

2009 2007

2005

LOBs 2011 Cache Advisor In-Memory Analytics Columnar Compression Parallel Replication

ODP.NET Support Cache Grid for Scale Out Oracle Clusterware Integration

PL/SQL Support Oracle Call Interface Support

OEM & SQLDeveloper Integration Oracle Database Data Types Support 2000 National Language Support Integration with Oracle RAC 1998 Mid-tier Cache for Oracle DB Online Upgrades High Availability 1st Commercial In-Memory RDBMS

Eine Memory-optimierte Datenbank Telco Services Financial Services

Application

CRM, Portal, SaaS, Customer-facing Applications

Application

Real-Time BAM & BI

Application

• Real-Time Applikationen erfordern kürzeste Antwortzeiten • TimesTen hält die Daten dicht an der Applikation • Kürzere Netzwerklatenzzeiten • Weniger physischer I/O zur Beschaffung der Daten

• Vollständiges relationales DBMS • Anbindung über ODBC, JDBC oder OCI • Bedienung mit Standard-SQL • Reduzierung der Antwortzeiten

Microsecond Response Time

7.0

1.78

Oracle TimesTen In-Memory Database 11.2.2.0 - Intel Xeon 5670 2.93Ghz, 2 CPUs, 6 cores/CPU - Oracle Linux 5.6

Anwendungsszenarien • Sehr Hohe Transaktionslast • United States Postal Service: 33000 Filialen 275M Txs/15h • Ericsson: Abrechnungssystem für Mobiltelefone • Monitoringsystem für Energieunternehmen mit bis zu 2167 Messages/sec, die es zu verarbeiten gilt

• Service Level Agreement – Konsistentes Antwortzeitverhalten • Bank of America: Wertpapierhandelssystem • Deutsche Börse: Xetra Vorsystem – 80ms SLA (Order-Routing)

• Real-Time Szenarien mit Antwortzeiten in Mikrosekunden • Reisereservierungssystem und Ticket-Suche

TimesTen In-Memory Database ist schnell • TT läuft idealerweise auf dem Rechner des Application Server

Client-Server Application TimesTen Client Lib

Client/ Server

• In-Memory optimiert – Datenbank komplett im Shared Memory – Zugriffsmethoden dafür optimiert

Direct-Linked Application TimesTen Libraries

JDBC / ODBC / ADO.NET / OCI / PLSQL

Fast data access

Checkpoint Files

Transaction Log Files

Memory-Resident Database

• Direct-Link für ideale Performance – Shared Memory hängt am Applikationsprozess – Kein Netzwerk Overhead – Client-Server-Anbindung zur Admin möglich (z.B. SQL Developer)

Unterschiede TimesTen zur Oracle DB • TimesTen In-Memory Datenbank • • • •

Gesamte Datenbank ist komplett im Hauptspeicher Datenbank-Design speziell auf Memory Layout abgestimmt Weniger Strukturen, weniger Prozesse – weniger Overhead Direkterer Zugriff auf die Daten

• Eine Anwendung kann direkt mit TimesTen gelinkt werden • Datenbank-Operationen werden aus dem Adressraum des Anwendungsprozesses heraus ausgeführt • Kein Overhead für Netzwerk und IPC (Inter Process Communication)

Replikation von TimesTen Datenbanken Applikation

Applikation Netzwerk

CKPT LOG

Netzwerk

• Replikation von TimesTen Datenbanken wird primär als Hochverfügbarkeits-Lösung eingesetzt • Mögliche Konfigurationen als • Active-Active / Active-Standby • Master-Subscriber • Uni- und bidirektional

CKPT LOG

In-Memory Database Cache

Zentrale Daten aus der Oracle Datenbank Applikation

Applikation

Applikation

Applikation Netzwerk

Netzwerk

• Daten aus der Oracle Datenbank nutzen DB-Instanz

• Daten werden initial in TimesTen geladen • Änderungen lassen sich in die Oracle Datenbank zurückschreiben (synchron/asynchron oder über Cache Write-Through Mechanismus)

 Daten aus einer zentralen Enterprise Datenbank für schnellen Zugriff bereitstellen

TimesTen Cache Connect • Tabellen aus der Oracle Datenbank oder Teile davon werden in TimesTen als sog. “Cache Groups” geladen

Applikation

CKPT LOG

Netzwerk

DB-Instanz

• Cache Groups lassen sich für lesenden als auch schreibenden Zugriff konfigurieren • Daten werden in regelmäßigen Abständen automatisch synchronisiert • Cache Group Daten sind auch dann verfügbar, wenn die Verbindung zur Oracle Datenbank zeitweise nicht besteht

Oracle Maximum Availability Architecture • TimesTen unterstützt RAC und die synchrone DataGuard Physical Standby-Konfiguration • Failover/Switchover • Transient Rolling Upgrade

• Automatische Wiederauf- LOG nahme der Datenaktualisierung von Oracle nach TimesTen • Automatische Wiederaufnahme der Transaktionsweitergabe von TimesTen an Oracle

ApplikationsTransaktionen

Hot Standby (Read-Only)

In-Memory Cache Tables

In-Memory Cache Tables

Active

Standby LOG

Cache Refresh

Cache Write-Through

Data Guard

Real Application Clusters

Active Data Guard

TimesTen Support im SQL Developer • Bearbeiten von TimesTen-Datenbankobjekten • Konfiguration des Cachings von Oracle Tabellen in sog. Cache Groups • Definition von Cache Groups • Laden/Refresh von Cache Data

• • • •

Entwicklung von PL/SQL Prozeduren/Packages Anzeige von SQL Execution Plans Aktualisieren von Statistiken Verwendung des SQL Worksheet für die Ausführung von ad-hoc Queries oder internen TimesTen Prozeduren

TimesTen Enterprise Manager PlugIn • Monitoring der Key Performance Metrics • Bestimmen von Schwellwerten für Alerts und Benachrichtigungen • Standard Reports über TimesTen-Metriken • Angepasste Reports lassen sich per Report Wizard erzeugen • Geringer Overhead

Zusammenfassung Data Buffer Keep Cache LRU-Algorithmus

Result Cache

Coherence Object Cache / Data Grid für Anwendungen

Shared Pool oder Client Transparent für Anwendungen

Flash Cache Data Buffer Erweiterung 2nd level Cache Auch für Datafiles

“In-Memory” Techniken der Datenbank In-Memory Database Cache Memory optimierende Techniken Compression Partitioning Parallelisierung OLAP

Kürzeste Antwortzeiten Real-Time Oracle DB konform