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 [luglio 2014] e' stata resa disponibile
l'opzione In-Memory.
[NdE La versione 12.2,
disponibile in cloud da novembre 2016 ed on premise da marzo 2017
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.
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!
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:
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).
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.
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!
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.
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 bycontainer=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; ALTER SESSION SET CONTAINER=PlugDbName; ALTER SESSION SET CONTAINER=cdb$root;
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!
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.
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.
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:
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.
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!
|
|
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);
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.
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 tablespace.
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!
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:
Ovviamente essendo un PITR richiede il log archiving...
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).
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
Data: 1 Luglio 2013
Versione: 1.0.5 -
14 Febbraio 2017
Autore:
mail [AT] meo.bogliolo.name