Novita' nell'architettura di Oracle 12c

La recente versione Oracle 12c [NdE luglio 2013] introduce alcune variazioni all'architettura ed alle funzionalita' di base dell'Oracle RDBMS, il relazionale commerciale piu' diffuso al mondo. In questo breve documento ne descriviamo le principali, ovviamente a mio insidacabile giudizio! In particolare: Multitenant Option, Flex Cluster, Multithreaded model, Enterprise Manager Database Express, Raw device desupport, Heat Map, RMAN (single table restore), LIMIT, ... Con la versione 12.1.0.2 [NdE luglio 2014] e' stata resa disponibile l'opzione In-Memory mentre la versione 12.2 [NdE disponibile novembre 2016 in cloud e da marzo 2017 on premise] ha ulteriormente arricchito le funzionalita' multitenant anche in ottica cloud.

Ma prima dovrete sorbirvi un noioso ripasso sull'architettura Oracle valida per le versioni precedenti! [NdE potete saltare l'introduzione seguendo questo link]

Il taglio del documento e' semplice e pratico, con esempi per ogni funzionalita' descritta... nonostante questo per leggerlo e' necessaria almeno una discreta conoscenza dell'RDBMS Oracle e delle problematiche DBA. Un'introduzione ad Oracle si trova in questo documento.

Introduzione

Le novita' introdotte nella versione 12c sono molte e significative.
Chi conosce bene Oracle sa che la 12c R1 non verra' immediatamente utilizzata negli ambienti di produzione... ma il suo rilascio e' utile per impadronirsi delle nuove funzionalita' e saperle quindi sfruttare adeguatamente in futuro. Quello che vediamo oggi con la 12c e' quindi una finestra sul futuro dei prossimi anni sul mondo dei database Enterprise. Almeno secondo Oracle... [NdE che, dal nome, sa prevedere il futuro].

La novita' principale e' la nuova opzione Multitenant che consente di montare piu' PDB (Plugable Database) sulla stessa istanza container. Si tratta di una variazione significativa dell'architettura che consente una gestione piu' flessibile delle istanze/database Oracle in ottica di servizio o, come e' certamente piu' di moda in questo periodo, per un'utilizzo in Cloud. In tale architettura l'istanza del CDB (Container Database) mantiene al suo interno diversi PDB utilizzando lo stesso set di processi e di strutture interne. Dal punto di vista delle applicazioni invece i PDB vengono visti come
Altra modifica architetturale, sempre nell'ottica della semplificazione, e' la possibilita' di utilizzare un modello a thread anziche' a processi. Questo riduce in modo significativo il numero di processi presenti sul sistema ed il footprint dell'istanza Oracle.

Molte sono anche le nuove funzionalita' che arricchiscono opzioni gia' presenti in 11g (eg. RAC, Advanced Compression, Active Data Guard, Information Lifecycle Management, ...). L'impegno della versione 12c sulla gestione automatica del ciclo di vita dei dati e', a mio avviso, quello piu' lungimirante. In molti progetti le politiche di svecchiamento dei dati sono demandate alle applicazioni che, semplicemente, non le implementano. Di conseguenza le basi dati crescono in modo continuo e spesso con andamenti esponenziali. Ma anche nelle basi dati ben disegnate e ben controllate la crescita della quantita' di dati e' sempre significativa. La versione 12c fornisce una gestione completa dell'ILM (Information Lifecycle Management), basata su Heat Map, compressione dati e migrazione automatica degli storage. Questo rende il database Oracle ancora piu' interessante per la gestione di basi dati di grandi dimensioni e con grandi tassi di crescita.

Sono tante le altre piccole novita' della 12c... ma quella che preferisco, forse banale ma certo molto utile, e' il restore di una singola tabella con RMAN!

Architettura Oracle RDBMS

Prima di vedere le novita' architetturali della versione 12c e' necessario un riassunto delle puntate precedenti... Ecco un ripasso sull'architettura di Oracle!

L'architettura dell'RDBMS Oracle presenta una certa complessita': vi sono una serie di processi di sistema che si occupano ciascuno di un compito specifico (eg. la scrittura dei dati, il controllo dei processi, l'esecuzione di job, l'archiviazione, ...). I vari processi condividono un'area di memoria, implementata come Shared Memory, denominata SGA. La SGA (System Global Area) mantiene i buffer dei dati, l'elenco dei lock, la cache delle strutture della base dati, ... Con il passare delle versioni di Oracle il numero di processi di sistema (background e shadow) e' sempre cresciuto. Nelle prime versioni un buon DBA sapeva a memoria il nome e la funzione di ogni singolo processo (SMON, PMON, DBWR, ...), con la versione 12c tale numero raggiunge i quaranta processi e chi afferma di conoscerli davvero tutti vi sta prendendo in giro.
Per l'accesso in Client-Server alla base dati viene utilizzato il processo listener che crea una processo oracle dedicato per ogni Client. Se il numero di Client e' molto elevato e' possibile sfruttare la tecnica dell'MTS (Multi Threaded Server) che sfrutta un pool di processi per le diverse sessioni.
Oracle utilizza una serie di file: Architettura Oracle RDBMS

Con l'eccezione del file di parametri, le strutture di Oracle possono essere definite sul file system oppure possono essere appoggiate direttamente sui device fisici (raw devices). Con l'ASM Oracle puo' gestire direttamente lo storage fisico senza necessita' di utilizzo di Volume Manager e/o di File Systems. La struttura interna dei datafile e' molto complessa poiche' sono molteplici le strutture di memorizzazione che Oracle utilizza. Le tecniche maggiormente utilizzate sono i B-Tree, la compressione delle chiavi e l'hashing.

La gestione delle transazioni e' molto efficiente ed affidabile con l'RDBMS Oracle. Per implementarla Oracle utilizza diverse tecniche.
Quando deve essere effettuata una modifica su un dato Oracle salva il contenuto del blocco che lo contiene su un segmento di rollback e quindi effettua la modifica sul dato. In tal modo e' sempre possibile effettuare un rollback della transazione in corso. Quando la transazione viene confermata il segmento di rollback viene segnato come libero ed il dato e' definitivamente confermato. I segmenti di rollback sono mantenuti sui datafile e la loro gestione, via via con le diverse versioni di Oracle, e' divenuta sempre piu' sofisticata ed automatizzata.
Per migliorare le prestazioni Oracle utilizza una cache in memoria ed effettua in modo periodico (o quando richiesto dal commit di una transazione) l'allineamento sui dischi.
Oracle e' giustamente considerato uno degli RDBMS piu' robusti ed affidabili. Ogni attivita' di scrittura sui dischi e' riportata sui file di log in modo sincrono al commit delle transazioni per garantire in modo completo la D dell'ACID. Ogni file utilizzato da Oracle e' marchiato con un timestamp (SCN). I file di log vengono utilizzati in modo circolare, quindi sono periodicamente ricoperti. Per mantenere la "storia" delle transazioni avvenute su un database e' possibile attivare il log archiving. Con il log archiving attivo quando un file di redo log e' stato completato viene salvato sulla directory definita dal DBA con una numerazione progressiva. Il log archiving permette il point in time recovery ed il backup a caldo. Per semplificare le attivita' di backup e restore fisico e' stato introdotto nella versione 9i l'RMAN (Recovery Manager). Un restore di una base dati resta comunque uno degli incubi del DBA.
Oracle non implementa il mirroring dei data file. L'implementazione a livello di RDBMS sarebbe infatti inefficiente in termini prestazionali. Tuttavia Oracle mantiene in mirroring le strutture di limitate dimensioni piu' importanti per il suo funzionamento come i Control File ed i Redo Log.

Le funzionalita' di Oracle possono essere estese utilizzando specifiche Option. Alcune sono di particolare importanza anche dal punto di vista architetturale.

L'opzione Oracle RAC consente la condivisione, da parte di istanze differenti ed attive su macchine distinte, di pool di dischi comuni. In tal modo sistemi differenti utilizzano le stesse risorse sui dischi. In caso di fault di un sistema, il secondo sistema puo' immediatamente sostituirsi ad esso. Si tratta quindi di una configurazione in cluster Active-Active. Nelle versioni precedenti l'opzione era denominata Oracle Parallel Server. Con la versione Oracle 11g R2 e' stata introdotto il RAC one Node: simile ad un ambiente di cluster failover introduce alcune possibilita' come l'Omotion (passaggio trasparente della base dati tra i nodi). Architettura Oracle RAC

E' possibile mantenere un'istanza Oracle in stand-by. In tale modalita' l'istanza non e' attiva ma puo' essere aggiornata continuamente (passando i file di redo log) rispetto ad un'istanza di produzione. Tale funzionalita' e' presente dalla versione 7.3 di Oracle (col nome di Stand-by Instance). Nelle versioni piu' recenti l'opzione e' chiamata Oracle Active Data Guard e consente di mantenere attiva l'istanza di Standby pur applicando continuamente i Redo Log. Architettura Oracle Data Guard

Per la loro importanza architetturale non sono infine da dimenticare anche l'Advanced Compression e le opzioni sulla sicurezza. La loro descrizione supera i limiti di questo documento... ne parleremo nel seguito quando serve.

Ora che sapete tutto di come funziona Oracle possiamo vedere le novita' dell'ultima versione Oracle 12c che avete appena installato!

Multitenant Option

Nella versione 12c e' possibile ospitare piu' istanze di database (PDB: Pluggable Database) all'interno di un unico container chiamato CDB (Container Database). Si tratta di una variazione significativa dell'architettura che consente una gestione piu' flessibile del database Oracle in ottica di servizio o, come e' certamente piu' di moda in questo periodo, per un'utilizzo in Cloud. Architetture database Oracle

Nell'architettura Multitenant disponibile dalla versione 12c di Oracle (evidenziata in rosso nella figura) l'istanza CDB mantiene al suo interno piu' PDB utilizzando lo stesso set di processi, la stessa SGA (System Global Area) e gli stessi Redo Log. In pratica tutte le componenti di sistema sono condivise. Dal punto di vista logico invece i PDB sono completamente separati ed utilizzano data dictionary distinti, utenti diversi, ... e naturalmente datafile separati.
I tablespace TEMP sono comuni ma e' possibile definirli in modo esclusivo per un solo PDB. La creazione di un'utenza e' locale al DB cui si e' connessi ma e' possibile creare nel CDB utenze comuni (dal nome c##Utente) per tutti i PDB. Le utenze comuni sono tipicamente utenze amministrative o di controllo.

La creazione di un DB viene tipicamente effettuata con il comando dbca che risulta di semplice utilizzo anche con i CDB ed i PDB. Un'istanza CDB contiene inizialmente il PDB$SEED in READ ONLY che viene utilizzato come base per la creazione dei successivi PDB. Un'istanza normale puo' essere trasformata in PDB mediante un comando che genera un file XML di descrizione della base dati e puo' essere infine montata un CDB.
L'attivazione di un CDB avviene come quella di una normale instanza con il comando di startup da SQL*Plus. I PDB vanno invece aperti esplicitamente con un comando di OPEN. All'avvio del CDB i PDB sono in stato MOUNTED (quindi non utilizzabili da parte degli utenti/applicazioni) ma si puo' automatizzare la loro partenza con un trigger di startup. Ogni PDB si registra come servizio sul listener, rendendo cosi' completamente trasparente l'accesso alle applicazioni: l'utilizzo di un PDB o di un'istanza dedicata e' indifferente per gli utenti finali. Naturalmente un DBA, che conosce i giusti comandi, sapra' sempre a cosa e' collegato...

Ecco i comandi SQL di gestione dei CDB e dei PDB per realizzare quando descritto fino ad ora:

CREATE PLUGGABLE DATABASE PlugDbName
 ADMIN USER AdminUserName IDENTIFIED BY Password;

create user c##meo identified by  container=all;

alter pluggable database PlugDbName open;
alter pluggable database all open;

create or replace trigger Sys.After_Startup after startup on database
begin
   execute immediate 'alter pluggable database all open';
end;
/  

select Sys_Context('Userenv', 'Con_Name') con_name from dual;
rem Or else, with SQL*Plus: show con_name 

select NAME, CDB, CON_ID from V$DATABASE;
select name pdb_name, open_mode, total_size from v$pdbs;

Oracle Corp. suggerisce di utilizzare la configurazione Multitenant in ogni nuova installazione/upgrade. Il Multitenant e' un'opzione [NdE ovvero a pagamento] pero' nel caso in cui venga utilizzata con un solo Pluggable Database non richiede l'acquisto della licenza.

Con la versione 12c R2 [NdE disponibile novembre 2016 in cloud e da marzo 2017 on premise] l'opzione multitenant risulta notevolmente arricchita: e' possibile utilizzare character sets differenti, un PDB puo' essere un active DG, l'utilizzo dei PDB e' integrato con il DG Broker, sono disponibili a livello di PDB le funzioni di flashback e di hot clone, ... torneremo sull'argomento!

Oracle Flex Cluster

L'architettura di Oracle RAC si basa sul'infrastruttura di Oracle Grid. Su un nodo RAC sono installati i componenti Grid, tra cui il modulo fondamentale ASM (Automatic Storage Management) ed il software dell'RDBMS. Con la versione 12c e' possibile utilizzare nodi leggeri che non richiedono la componente ASM e non accedono direttamente allo storage.
Con Oracle Flex Cluster si hanno nodi di tipo HUB, configurati come i tradizionali nodi di un cluster RAC, e nodi di tipo LEAF che non accedono allo storage ma utilizzano il canale del nodo HUB associato.

Architettura Oracle Flex

In una configurazione Flex ASM, oltre alle istanze +ASMx sui nodi Hub sono presenti le istanze +APXx (istanze ASM-Proxy).

La nuova architettura consente di accrescere in modo significativo il numero di nodi assegnati ad un cluster in modo flessibile superando il limite sul numero di nodi HUB (attualmente 64) e consentendo l'aggiunta di nodi leggeri.
Inoltre l'eventuale caduta di un'istanza ASM non interrompe l'accesso all'ACFS poiche' l'istanza APX puo' accedere ai metadati sia localmente che su un altro nodo.

Multithreaded model

Oracle utilizza da sempre su Unix un'architettura multiprocesso sia per gestione interna delle strutture del database (processi di background) che per le connessioni utente. Con il crescere delle funzionalita' in ogni versione il numero dei processi di backgruond. Un'installazione di default di Oracle utilizza i seguenti 44 processi: ora_pmon_TST01 ora_psp0_TST01 ora_vktm_TST01 ora_gen0_TST01 ora_mman_TST01 ora_diag_TST01 ora_dbrm_TST01 ora_dia0_TST01 ora_dbw0_TST01 ora_lgwr_TST01 ora_ckpt_TST01 ora_smon_TST01 ora_reco_TST01 ora_lreg_TST01 ora_mmon_TST01 ora_mmnl_TST01 ora_d000_TST01 ora_tmon_TST01 ora_tt00_TST01 ora_smco_TST01 ora_aqpc_TST01 ora_w000_TST01 ora_p000_TST01 ora_p001_TST01 ora_p002_TST01 ora_p003_TST01 ora_qm02_TST01 ora_q002_TST01 ora_q003_TST01 ora_cjq0_TST01 ora_w001_TST01 ora_w002_TST01 ora_w003_TST01 ora_w004_TST01 ora_w005_TST01 ora_w006_TST01 ora_w007_TST01 ora_w008_TST01 ora_w009_TST01 ora_p004_TST01 ora_p005_TST01 ora_p006_TST01 ora_p007_TST01 ora_s001_TST01 ...
Per non dimenticare il listener (tnslsnr) ed un processo per ogni utente connesso!

Dalla versione 12c e' possibile utilizzare il multithreading anziche il multiprocessing sfruttando le possibilita' offerte dal sistema operativo Unix. L'attivazione e' semplice poiche' richiede la modifica di un solo parametro (ovviamente non dinamico) ed un riavvio. Ecco i passi:

CONNECT sys AS SYSDBA ALTER SYSTEM SET threaded_execution=TRUE SCOPE=SPFILE; SHUTDOWN IMMEDIATE STARTUP

Gia' fatto! Il numero dei processi ora e' drasticamente ridotto, con un conseguente uso ridotto di memoria e di risorse di sistema: ora_pmon_TST01 ora_psp0_TST01 ora_vktm_TST01 ora_u004_TST01 ora_u005_TST01 ora_dbw0_TST01 .

Per utilizzare il multithreading nelle connessioni utente e' invece necessario impostare il parametro seguente nel file listener.ora:


DEDICATED_THROUGH_BROKER_=ON

Poiche' il modello a processi e' molto piu' consolidato e' opportuno utilizzare il modello multithread solo nel caso in cui, consolidando un numero elevato di istanze senza sfruttare l'opzione multitenant, si abbia un numero troppo elevato di processi sul sistema ospite.
Una nota finale: attenzione alla connessione come SYS perche' non si puo' utilizzare la OS Authentication con il multithread.

Enterprise Manager Database Express

La nuova versione di EM per la gestione della base dati non solo ha una nuova interfaccia semplice ed efficace... la sua implementazione e' completamente differente!

Enterprise Manager Express Oracle 12c - Storage - Undo Management Enterprise Manager Express Oracle 12c - Performance Hub

L'EM con la versione 12c non utilizza un framework Java esterno ma e' ospitato all'interno del DB stesso. Nella versione 12c e' il modulo Oracle XML DB (XDB), che opera in XML in modo nativo, ad ospitare l'EM.

Le utenze amministrative (DBA) sono abilitate per default con tutti i diritti sull'EM ma e' possibile consentire un'accesso in sola lettura ad altri utenti con:
  grant EM_EXPRESS_BASIC to utente;

Dopo l'installazione l'EM per default e' configurato in HTTPS sulla porta 5500.
E' possibile modificare la porta con il comando exec DBMS_XDB_CONFIG.setHTTPSPort (8443);

Raw device desupport

Questo e' molto semplice da descrivere... non si utilizzano piu' i raw devices!
Sono molte le funzionalita' deprecate o non supportate nella versione 12c, il desupporto dei raw device e' quello con maggiori impatti sull'architettura. Per raggiungere il massimo delle prestazioni e del controllo sullo storage gia' da tempo si utilizza l'ASM, quindi proseguire nel supporto dei raw devices non era piu' necessario.

La definizione di un data file su raw device consentiva ad Oracle un accesso diretto al disco, senza passare attraverso un file system e le sue cache. In questo modo si poteva ottenere il massimo delle prestazioni, naturalmente se tutta la configurazione era perfettamente ottimizzata. Ma un accesso diretto ai dischi si ha anche con l'ASM (Automatic Storage Management) introdotto con la versione 10g. Inoltre l'ASM offre un insieme molto ampio di funzionalita' per il controllo e per la gestione mentre con i raw devices tutte le attivita' di configurazione richiedono interventi sistemistici manuali. L'utilizzo del file system puo' essere coniugato con l'utilizzo di ASM utilizzando l'ACFS.
Nella versione 11g non era piu' possibile utilizzare la dbca per creare database con i raw devices, dalla versione 12c non e' piu' possibile alcun utilizzo dei raw devices con l'RDBMS Oracle.

Heat Map

La versione 12c introduce le Heat Map che consentono di stabilire la frequenza degli accessi per blocco o per oggetto. Le Heat Map possono essere interrogate per ottimizzare le prestazioni oppure possono essere utilizzate in una piu' completa politica di ILM (Information Lifecycle Management) integrata con l'ADO (Automatic Data Optimization) e l'Advanced Compression Option. In questo modo e' possibile definire in modo completo l'ILM effettuando una storicizzazione dei dati non piu' acceduti comprimendoli e/o ponendoli sullo storage piu' adatto.

Le Heat Map permettono di indentificare i blocchi Hot, Warm o Cold a livello di blocco, extent, oggetto o tablespace [NdA la documentazione ufficiale riporta la dicitura row or segment, ma l'implementazione e' per blocco fisico ed extent e non per riga]. Va impostato il parametro heat_map=on e risulta cosi' selezionabile la vista v$heat_map_segment.
Il parametro HEAT_MAP puo' essere impostato a livello di sessione o di sistema. Le Heat Map non sono disponibili per gli oggetti definiti nei tablespace SYSTEM o SYSAUX o con sui CDB.

Se il parametro HEAT_MAP e' impostato a livello di sistema e' possibile utilizzare l'ADO (Automatic Data Optimization). Oracle infatti consente di definire politiche di tiering sia sullo storage che sulla compressione utilizzando storage piu' lento e meno costoso e/o comprimendo i dati acceduti con minor frequenza.
Le politiche di ADO possono indicare la compressione oppure la migrazione dello storage, riferirsi ad un segmento, un gruppo oppure ad una riga ed essere attivate da una condizione basata sulle Heat Map (clausola AFTER) o su una funzione custom (clausola ON). La compressione utilizza le normali clausole presenti anche nella create table: NOCOMPRESS, COMPRESS, ROW STORE COMPRESS [BASIC|ADVANCED], COLUMN STORE COMPRESS FOR [QUERY|ARCHIVE] [LOW|HIGH] ... Mentre l'indicazione del tier di storage... basta indicare il tablespqce.
Troppe parole! Un esempio di politiche e' il seguente:

ALTER TABLE fatture_attive ILM ADD POLICY 
 COMPRESS FOR ARCHIVE HIGH SEGMENT 
 AFTER 12 MONTHS OF NO ACCESS;

ALTER TABLE fatture_passive ILM ADD POLICY 
 TIER TO tbs_economico SEGMENT
 AFTER 6 MONTHS OF LOW ACCESS;

Gia' da tempo sono disponibili "Storage Intelligenti" che gia' applicano i principi delle Heat Map in modo sempre piu' sofisticato con il caching ed il tiering... perche' implementarla a livello di base dati? Perche' la gestione da parte di Oracle puo' essere ancora piu' intelligente!
Infatti solo l'RDBMS e' in grado di distinguere un accesso applicativo da un accesso effettuato durante un backup oppure per aggiornare le statistiche. Il rischio con gli "Storage Intelligenti" e' quello di ottimizzare le attivita' di scrittura dei backup rallentando l'online!

RMAN (single table restore)

Semplicemente prima della versione 12c non si poteva recuperare con RMAN una singola tabella e bisognava ripristinare un'intero tablespace (RMAN), esportare (expdp) e reimportare (impdp) ...
Ora basta un comando RMAN:

RMAN> connect target; RMAN> RECOVER TABLE scott.emp until time "to_date('2013-08-01:09:00:00','YYYY-MM-DD:HH24:MI:SS')";

Ovviamente essendo un PITR richiede il log archiving...

LIMIT

Sono molte le estensioni della Oracle 12c anche all'SQL ed all'ottimizzatore. Come ultimo esempio presentiamo una funzionalita', implementata da tempo in modo semplice su molti database (LIMIT in MySQL o SQLite), ma mancante nell'SQL di Oracle: il controllo del numero di righe restituite da una query!

La gestione del numero di righe e della paginazione introdotta da Oracle con la versione 12c e' molto completa e potente, ma comunque semplice. Per introdurla, come sempre, e' meglio fare un esempio:

select *
 from scott.emp
 order by sal desc
 fetch first 5 rows only;

Come trucco per aggirare l'assenza della clausola di controllo con Oracle si e' sempre utilizzato la virtual column ROWNUM, ma con alcuni problemi sulle condizioni e sull'ordinamento. Finalmente la versione 12c ha introdotto la clausola FETCH con una sintassi simile a DB2.
E' possibile indicare il numero di righe da estrarre (FIRST o NEXT) e quante saltarne (OFFSET). E' anche possibile indicare il numero di record con una percentuale (PERCENT) oppure con l'indicazione a pari merito (WITH TIES).

Varie ed eventuali...

L'evoluzione delle funzionalita' dell'RDBMS Oracle nel tempo e' stata notevole. Maggiori dettagli tecnici sulle 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 che e' scritto come una favola].


Titolo: Novita' architettura Oracle 12c
Livello: Avanzato (3/5)
Data: 1 Luglio 2013
Versione: 1.0.4 - 14 Febbraio 2017
Autore: mail [AT] meo.bogliolo.name