Oracle Database In-Memory – Der schnelle Einstieg

„Was bringt mir Database In-Memory bei meinem Workload?“

Diese Frage stellen sich Anwender bei der Bewertung, ob Database In-Memory bei ihrer Umgebung einen Mehrwert bringen könnte.

Das Thema In-Memory ist nach wie vor topaktuell und Oracle stellt mit Oracle Database In-Memory Real-Time Analytics Out-of-the-Box zur Verfügung und beschleunigt dadurch analytische Abfragen extrem.

Auch in der kostenlosen Oracle Database Express Edition (XE) steht dem Anwender Oracle Database In-Memory zur Verfügung.

Hier stehen insgesamt 2 GB an Hauptspeicher für die SGA & PGA zu Verfügung. Einem schnellen Kennenlernen steht somit nichts im Wege.

Kleines Beispiel zum selber testen

Das folgende Beispiel soll im Zusammenspiel mit dem ebenfalls kostenlos erhältlichen Oracle SQL Developer den Nutzen von Oracle Database In-Memory veranschaulichen.

Nachdem die Installation der Oracle XE 21c unter Windows 10 Professional nach ein paar Minuten durchgelaufen ist, müssen nur noch die Initialisierungsparameter SGA_TARGET und PGA_TARGET angepaßt werden. Dazu als DBA an der CDB anmelden. Anmerkung: Bei Windows wird die Home Edition in Verbindung mit Oracle XE nicht unterstützt. Zudem ist Oracle XE auch auf Linux verfügbar.

Nach dem Setzen der INMEMORY_SIZE von 1 GB wird die Datenbank durchgestartet.

-- Als DBA an der CDB anmelden
connect / as sysdba 
-- Intialisierungsparameter bei Oracle Database XE bearbeiten
alter system set sga_target=1568M scope=spfile; 
alter system set pga_aggregate_target=412M scope=spfile; 
alter system set inmemory_size=1G scope=spfile; 
shutdown immediate; 
startup;

Danach steht mit der In-Memory Area ein neuer Pool innerhalb der SGA zur Verfügung, der den In-Memory Column Store enthält.

Zum Aufbau einer kleinen Testumgebung stehen ein Dump-File mit einem Export des SSB-Schemas zur Verfügung, die in den 1 GB großen In-Memory Column Store passen. Die eigene Testumgebung kann leicht mit dem beiliegenden Skript erzeugt werden. Die erforderlichen Schritte sind das Erzeugen eines Tablespaces, das Anlegen des Users SSB, der Import des Dumps mit den Beispieldaten und das Aktualisierung der Statistiken. Das Dump-File und das Skript mit den Schritten zum selber Aufbauen der Umgebung steht unter den Links zum Download zur Verfügung.

Das SSB-Schema beinhaltet die Faktentabelle LINEORDER mit 11.997.996 Rows. Deweiteren sind die Dimensionstabellen CUSTOMER mit 60.000 Rows, DATE_DIM mit 2556 Rows, PART mit 400.000 Rows und SUPPLIER mit 4.000 Rows enthalten. Die Tabellen sind basiskomprimiert und benötigen etwa 1,3 GB Plattenspeicher und 590 MB Platz im In-Memory Column Store. Dort wird die Standardkomprimierung MEMCOMPRESS FOR QUERY LOW verwendet.

Um die Objekte in den In-Memory Column Store zu laden, muss das INMEMORY Attribut gesetzt werden.
Standardmäßig steht die INMEMORY PRIORITY auf NONE. Dies bedeutet, dass Oracle automatisch die Objekte beim ersten Zugriff in den In-Memory Column Store lädt. Die Objekte werden demnach bei Bedarf (“On Demand”) geladen.
Alternativ kann der Priority Level auf einen Wert wie z.B. CRITICAL oder HIGH gesetzt werden und das Beladen erfolgt dann sofort anhand der Reihenfolge der gesetzten Prioritäten.

-- "On demand" Population - Standardmäßig ist die INMEMORY PRIORITY auf NONE gesetzt

alter table CUSTOMER inmemory;
alter table DATE_DIM inmemory;
alter table LINEORDER inmemory;
alter table PART inmemory;
alter table SUPPLIER inmemory;

-- INMEMORY PRIORITY ist auf CRITICAL und HIGH gesetzt

alter table CUSTOMER inmemory priority high;
alter table DATE_DIM inmemory priority high;
alter table LINEORDER inmemory priority critical;
alter table PART inmemory priority high;
alter table SUPPLIER inmemory priority high;

Die folgende analyische Abfrage wird nun im Oracle SQL Developer ausführt. Um die Performance-Verbesserung der In-Memory Abfrage mit dem Buffer Cache besser vergleichen zu können, wird die Buffer Cache Abfrage mit dem NO_INMEMORY Hint versehen.

-- Analytische Abfrage gegen den In-Memory Column Store ausführen

select /*+ INMEMORY */ sum(lo_extendedprice * lo_discount) revenue
from
  LINEORDER l,
  DATE_DIM d
where
  l.lo_orderdate = d.d_datekey
  and l.lo_discount between 2 and 3
  and l.lo_quantity < 24
  and d.d_date='December 24, 1996';

Elapsed: 0.009 seconds

-- Analytische Abfrage gegen den Buffer Cache/Row Store ausführen 

select /*+ NO_INMEMORY */ sum(lo_extendedprice * lo_discount) revenue 
from 
  LINEORDER l,
  DATE_DIM d
where
  l.lo_orderdate = d.d_datekey
  and l.lo_discount between 2 and 3
  and l.lo_quantity < 24
  and d.d_date='December 24, 1996';

Elapsed: 0.868 seconds

Im SQL Developer werden über den Autotrace-Button (oder durch Drücken der Funktionstaste F6) die tatsächlichen Ausführungspläne für In-Memory- und Buffer Cache-Abfragen erzeugt und miteinander verglichen. Praktisch ist die Pin-Funktion (Symbol mit der roten Stecknadel), die verwendet werden kann, um beide Pläne besser vergleichbar zu machen.

Auf der linken Seite ist der In-Memory Plan mit einem Bloom-Filter (:BF0000) erkennbar, der aus der D_DATE Spalte der Tabelle DATE_DIM erzeugt wird und für das Scannen der LINEORDER Tabelle verwendet wird.

Auf der rechten Seite ist der Buffer Cache Plan zu sehen, bei dem die Tabellen DATE_DIM und LINEORDER jeweils über einen Full-Table Scan und den Hash Join abgearbeitet werden.

Ebenso sind die Session-Statistiken beim Aufrufen von Autotrace in der Übersicht enthalten. Auch diese können gepint werden und über “Compare with…” miteinander verglichen werden.

Über die Filter-Funktion wird zum einen nach “IM” für die In-Memory Statistiken gefiltert:

Zum Anderen stehen über das Filtern nach “ph” die Physical Read Statistiken zur Verfügung:

Fazit

Das SQL Statement ist ideal für die In-Memory Verarbeitung geeignet. Die Ausführungspläne und die Statistiken zeigen, dass im vorliegenden Fall die komplette Verarbeitung hinsichtlich Scannen und Filtern der Daten im IM Column Store erfolgt und keinerle Physical I/O stattfindet. Selbst in diesem Beispiel mit geringen Datenmengen läßt sich durch Database In-Memory und die Verwendung des In-Memory Column Stores die Antwortzeit beachtlich reduzieren (In-Memory 0.009 seconds vs. Buffer Cache 0.868 seconds).