Oracle In-Memory

Oracle Database In-Memory permette un accesso velocissimo ai dati sfruttando la tecnica dell'accesso per colonne tipica dei sistemi OLAP (On-Line Analytical Processing) e mantenendo i dati in memoria. Se utilizzata correttamente permette miglioramenti di un'ordine di grandezza nelle query di analisi e migliora anche le prestazioni nelle operazioni OLTP.

Database In-Memory e' una Option introdotta dalla versione Oracle 12.1.0.2 [NdE disponibile da oggi 22 luglio 2014 in EE per Linux e Solaris a 64-bit] che non richiede HW specifici ne, sopratutto, alcuna modifica applicativa per essere utilizzata. In questo breve documento vediamo come si usa.

1,2,3 fatto!

Architettura

L'architettura di Database In-Memory e' relativamente semplice e si integra in modo complementare con l'architettura standard di Oracle. All'interno della SGA e' disponibile una nuova cache che e' possibile popolare con le tabelle piu' significative. La cache e' chiamata IM Column Store perche' viene utilizzata una memorizzazione dei dati per colonne, modalita' tipica di molti strumenti di analisi dei dati.

Possono essere caricate nell'IM Column Store tabelle, partizioni, sottopartizioni, viste materializzate e LOB (anche se questi ultimi non ne hanno tipicamente beneficio).

Le normali transazioni ed attivita' operano senza alcuna differenza rispetto ad un database Oracle tradizionale. Tutte le funzionalita' di sicurezza e protezione dei dati (eg. log archiving, Data Guard) non presentano alcuna differenza... l'IM Column Store si affianca alla normale memorizzazione e gestione delle informazioni in formato per righe. L'adozione di In-Memory con l'opzione RAC non presenta differenze e' anzi possibile isolare su un solo nodo le query analitiche ottenendo cosi' una separazione del carico ideale.

E' possibile definire quando popolare un oggetto in memoria: all'avvio dell'istanza o al primo accesso. La scelta si effettua impostando la clausola PRIORITY dell'oggetto: none (default), low, medium, high e critical (popolato allo startup).
E' possibile definire il livello di compressione degli oggetti posti nell'IM Column Store impostando la clausola MEMCOMPRESS: for query (2x-5x default), for capacity low (3x-10x for query+OZIP), for capacity high (massima compressione ma impatto sulle performance), basic (nessuna compressione).
L'IM Column Store non utilizza alcun algoritmo di svecchiamento (eg. LRU): quando e' pieno semplicemente non carica piu' in memoria altri oggetti.

Configurazione

La configurazione dell'opzione In-Memory e' davvero semplice come descritto all'inizio del documento. In effetti, come molte altre opzioni di Oracle, e' gia' abilitata. Sono presenti sei nuovi parametri ma per iniziare ad utilizzare l'opzione e' sufficiente variarne uno solo rispetto al default.

Con il comando SQL alter system set inmemory_size=8G scope=spfile; si configura la memoria utilizzabile nella cache per la memorizzazione delle tabelle in formato colonnare. Va solo posta attenzione all'impostazione globale della memoria ed eventualmente modificarla con il comando alter system set sga_target=12G scope=spfile;
Naturalmente i valori da utilizzare variano da una configurazione all'altra. Impostati i parametri e' sufficiente un restart e l'opzione e' subito attiva.

Hands on

Nuovi comandi, nuove colonne sulle tabelle del data dictionary, nuove performance view, package per la gestione, ... meglio i fatti delle parole:

alter table MyImportantTable inmemory priority critical memcompress for query; alter table MyNotSoImportanTable inmemory priority low memcompress for capacity high; select owner, table_name, cache, inmemory_priority inmem_prio, inmemory_distribute, inmemory_compression from dba_tables where inmemory='ENABLED'; select OWNER, SEGMENT_NAME, INMEMORY_SIZE, BYTES, BYTES_NOT_POPULATED, POPULATE_STATUS, INMEMORY_PRIORITY, INMEMORY_DISTRIBUTE, INMEMORY_COMPRESSION, round(BYTES/INMEMORY_SIZE,3) comp_ratio from V$IM_SEGMENTS; EXEC DBMS_INMEMORY.REPOPULATE ('MEO','MYTAB'); alter table MyNotSoImportanTable NO inmemory;

Gli esempi parlano da soli!
Quindi vediamo una sessione reale da cui sono stati tagliati solo i dettagli non significativi:

alter system set inmemory_size=2G scope=spfile; shutdown immediate exit $ sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Tue Jul 22 22:22:22 2014 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 4294967296 bytes Fixed Size 2932632 bytes Variable Size 419430504 bytes Database Buffers 1711276032 bytes Redo Buffers 13844480 bytes In-Memory Area 2147483648 bytes Database mounted. Database opened. SQL> select count(*) from scott.big_emp; COUNT(*) ---------- 14680064 SET AUTOTRACE ON SET TIMING ON SET LINES 132 SQL> select count(*), deptno from scott.big_emp group by deptno; COUNT(*) DEPTNO ---------- ---------- 6291456 30 5242880 20 3145728 10 Elapsed: 00:00:02.26 Execution Plan ------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 3 | 9 | 4 (25)| 00:00:01 | | 1 | HASH GROUP BY | | 3 | 9 | 4 (25)| 00:00:01 | | 2 | TABLE ACCESS FULL| BIG_EMP | 14 | 42 | 3 (0)| 00:00:01 | ------------------------------------------------------------------------------ SQL> alter table scott.big_emp inmemory; Table altered. SQL> select count(*), deptno from scott.big_emp group by deptno; COUNT(*) DEPTNO ---------- ---------- 6291456 30 5242880 20 3145728 10 Elapsed: 00:00:01.74 Execution Plan --------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 3 | 9 | 2 (50)| 00:00:01 | | 1 | HASH GROUP BY | | 3 | 9 | 2 (50)| 00:00:01 | | 2 | TABLE ACCESS INMEMORY FULL| BIG_EMP | 14 | 42 | 1 (0)| 00:00:01 | ---------------------------------------------------------------------------------------

La query utilizzata e' banale ma le differenze sono evidenti: nuovi algoritmi e differenti tempi di esecuzione.

Utilizzo nelle applicazioni

Per sfruttare l'opzione InMemory non e' necessaria alcuna modifica alle applicazioni.

L'ottimizzatore utilizzera' l'accesso migliore a seconda delle query.
L'utilizzo dei dati in memoria viene facilmente rilevato negli execution plan come TABLE ACCESS INMEMORY FULL. L'ottimizzatore ha inoltre una nuova serie di algoritmi utilizzabili per i dati InMemory (eg. bloom filter) che risultano significativamente piu' efficienti per le query analitiche.
Gli accessi per chiave restano invece molto piu' efficienti quando eseguiti con indice. Quindi per questi l'ottimizzatore utilizzera' nell'execution plant gli algoritmi tradizionali.

Per sfruttare ulteriormente InMemory si possono cancellare gli indici non necessari alle transazioni OLTP. In questo modo le attivita' di DML risultano piu' veloci perche' debbono essere aggiornati meno indici.
Si tratta pero' di un passo da valutare caso per caso. Cancellare tutti gli indici lasciando solo primary key e constraint puo' avere controindicazioni... non tutte le applicazioni sono sempre piu' veloci in questo caso.

Applicazioni complesse che sono state ottimizzate nel tempo per sfruttare al meglio le funzionalita' di Oracle potrebbero ottenere vantaggi significativi ma non ecclatanti. Alcune prove effettuate da Oracle su EBS e JDE hanno portato ad elaborazioni 100 volte piu' veloci, ma per ottenere questi risultati vanno ottimizzate in parte anche le applicazioni.

Adozione Oracle 12c

Le novita' introdotte nella versione 12c sono molte e significative: Flex Cluster, Multitenant Option, ILM/Heat Map, RMAN (single table restore), ...
Ma si sa che la prima uscita di una versione Oracle viene accolta sempre con un certo ritardo e con la dovuta attenzione negli ambienti di produzione.

L'uscita della nuova versione e l'opzione In-Memory sono un'importante spinta per l'adozione della versione 12c.
Perche' rinunciare a query dieci volte piu' veloci e che sfruttano al meglio l'HW disponibile?

Effettuare un POC consente di verificare gli vantaggi sulle applicazioni reali. Con In-Memory e' particolarmente semplice realizzare un POC perche' non richiede nessuna modifica applicativa e non richiede alcun hardware specifico o dedicato.
E' cosi' possibile valutare quali sono gli effettivi vantaggi e pianificare al meglio l'upgrade alla nuova versione di Oracle.

Varie ed eventuali...

In-Memory e' una Database Option. Come tutte le Database Option di Oracle ha un costo aggiuntivo.

L'evoluzione delle funzionalita' dell'RDBMS Oracle nel tempo e' stata notevole.
Un'introduzione ad Oracle si trova in questo documento. La versione 12 e' descritta in questo documento.

Maggiori dettagli sulle funzionalita' delle diverse versioni di Oracle sono riportate in questo documento. Mentre la storia delle versioni Oracle negli ultimi 20 anni viene descritta in modo assai piu' romanzato in questo favoloso documento [NdA favoloso nel senso letterale perche' e' scritto come una favola].

Titolo: Oracle Database In-Memory
Livello: Avanzato (3/5)
Data: 22 Luglio 2014
Versione: 1.0.2 - 23 Luglio 2014
Autore: mail [AT] meo.bogliolo.name