L'RDBMS Oracle offre diverse modalita'
di backup e diversi strumenti per mantenere la sicurezza dei dati a fronte di
errori Hardware o Software.
Questo documento riporta una panoramica
sui principali strumenti ed architetture Oracle utilizzabili. Il documento non
entra in dettaglio sulle modalita' di configurazione, sono tuttavia riportati
i riferimenti di altri documenti tecnici che riportano tali inforamzioni.
Dopo una breve introduzione sull'architettura di Oracle, necessaria per meglio comprendere gli elementi sucessivi, vengono presentati i seguenti argomenti:
In questo paragrafo vengono riportati, in modo succinto e semplificato, i principali elementi architetturali di Oracle di interesse per la sicurezza dei dati.
Dal punto di vista di strutture appoggiate sui supporti di memorizzazione Oracle utilizza i seguenti oggetti:
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).
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 innanzi a tutti il contenuto del blocco che lo contiene
su un segmento di rollback, 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.
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.
Ogni attivita' di scrittura sui dischi e' riportata sui file di log in modo
sincrono al commit delle transazioni. 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 salvataggio logico della base dati Oracle (export) e' effettuato con il comando exp che salva su file (con formato proprietario Oracle) il contenuto dell'intero database, di un utente completo o di una serie di tabelle.
La fase di recupero dati avviene invece con il comando imp che puo' ripristinare l'intero contenuto dell'export o parte di esso.
I programmi di exp/imp utilizzano "normali" statement SQL (quindi SELECT ed INSERT) e naturalmente richiedono che l'RDBMS sia attivo.
La possibilita' di restorare singole tabelle o di spostare dati tra diversi utenti rendono l'export molto flessibile e quindi consigliabile in tutte le installazioni di Oracle. In particolare nei sistemi dedicati allo sviluppo, su sistemi con frequenti variazioni e nel periodo sucessivo all'installazione di nuove applicazioni l'utilizzo dei salvataggi logici e' una necessita'.
Il salvataggio fisico dei dati richiede la copia dei diversi oggetti Oracle (datafile, control file, ...) con un opportuno comando del sistema operativo.
Nel caso in cui l'RDBMS non abbia il log archiving attivo e' possibile effettuare salvataggi fisici dell'RDBMS solo a database non attivo e salvando tutti i file su disco.
Nel caso in cui l'RDBMS abbia il log
archiving attivo e' possibile effettuare salvataggi dell'RDBMS anche a database
attivo e salvando eventualmente solo parti di esso. Per effettuare i salvataggi
a database attivo e' necessario l'utilizzo di alcuni statement SQL di controllo
particolari per indicare i momenti di inizio e fine del salvataggio di un particolare
tablespace.
Con il log archiving abilitato e' inoltre possibile effettuare il recovery fino
all'ultima transazione committata partendo da un backup fisico completo e riapplicando
tutti i file di redolog generati dal momento dell'ultimo salvataggio. E' inoltre
possibile effettuare un recovery fino ad un preciso momento caricando solo una
parte dei log archiviati.
Da parecchie versioni di Oracle (9.0 se non ricordo male) e' inoltre disponibile l'RMAN (Recovery Manager) per la gestione dei backup e dei restore. Con RMAN e' possibile automatizzare la maggioranza delle operative sia dei backup che dei restore preparando semplici script.
Oracle non implementa il mirroring dei data file. L'implementazione a livello di RDBMS sarebbe infatti inefficiente in termini prestazionali. L'implementazione del RAID sul sistema operativo o, meglio, direttamente sullo storage e' molto piu' efficiente e disponibile da decenni. Tuttavia Oracle mantiene in mirroring le strutture di limitate dimensioni piu' importanti per il suo funzionamento.
E' infatti assolutamente necessario
definire piu' Control File, possibilmente appoggiati su dischi differenti.
E' inoltre
opportuno utilizzare gruppi di redo log file composti da piu' membri (quindi
in mirroring).
Oracle fornisce uno strumento integrato per l'effettuazione dei backup: Enterprise Backup Utility (EBU). EBU si occupa di tutte le problematiche relative ai backup inviando i comandi corretti all'RDBMS per effettuare i diversi tipi di backup fisici.
EBU si integra con diversi strumenti per la gestioni dei device di backup (Legato Networker, IBM ADSM, ...) permettendo cosi' politiche di backup integrate e, in molti casi, anche complesse.
I sistemi operativi attuali offrono molteplici funzionalita' per migliorare la sicurezza dei dati e le prestazioni dei dischi. E' fortemente consigliabile utilizzare tali strumenti per migliorare le prestazioni di Oracle e la sicurezza dati.
Il mirroring dei dischi, nel caso della caduta di un singolo disco, oltre ad evitare la perdita dei dati, consente la continuita' operativa.
Altre modalita' di RAID, oltre alle carattirische di fault tolerance, presentano vantaggi prestazionali grazie allo striping (utilizzo in parallelo) di piu' dischi.
Non riguarda la sicurezza dati ma l'importante aspetto della continuita' del servizio l'utilizzo di un cluster Active-Passive.
L'opzione Oracle Parallel Server 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 piu' recenti il prodotto e' diventato
Oracle RAC (Real Application Cluster).
A partire dalla versione 7.3 di Oracle e'
disponibile la modalita' di stand-by di un'istanza. In tale modalita' un'istanza
puo' essere mantenuta non attiva ma aggiornata continuamente (passando i file
di redo log) rispetto all'istanza di produzione.
Nelle versioni piu' recenti il prodotto e' diventato
Oracle Data Guard.
Con Oracle RAC si ottengono gli RTO ed RPO minimali, con Data Guard si ha una protezione con un'istanza a distanza geografica: la soluzione che prevede entrambe le opzioni e' quella che fornisce le maggiori garanzie di continuita' del servizio.
La tecnologia dei database distribuiti permette di effettuare transazioni che operano in modo sincronizzato su istanze differenti.
Oracle fornisce diverse modalita' di utilizzo dei database distribuiti. Di interesse per la sicurezza dei dati e' certamente la possibilita' di mantenere repliche di tabelle su uno o piu' siti distribuiti geograficamente con aggiornamenti sincroni, asincroni o periodici.
La possibilita' di accedere a database
esterni, di creare link tra database e rendere trasparenti, in selezione, gli
accessi remoti sono funzionalita' di base presenti nella versione Enteprise.
La Distribuited Database Option permette l'utilizzo di transazioni distribuite
tra istanze. Viene utilizzato il protocollo di two-phase commit.
La Advanced Replication Option permette la sincronizzazione asincrona
tra istanze differenti. Tale modalita' consente di mantenere in allineamento
istanze differenti senza blocchi quando si verificano interruzioni di sistema
o dei canali di comunicazione. Eventuali modifiche occorse durante un'interuzione
vengono infatti accodate e sono riproposte alla riattivazione.
Le possibilita' applicative per garantire un'elevata sicurezza sui dati sono molteplici.
Innanzi tutto debbono essere evitati "errori" nelle applicazioni! La frase sembra lapalissiana ma ha alcune sottili implicazioni. Infatti una corretta gestione delle transazioni (ed in particolare del momento del commit) e' fondamentale per assicurare la consistenza dei dati non solo quando tutto viene eseguito correttamente ma anche quando un qualsiasi errore (HW, di sistema, dell'RDBMS, dell'applicazione, ...) interrompe l'esecuzione.
La tecnica piu' semplice e comune per garantire un semplice recupero di dati e fornire un dettagliato controllo e' quello di utilizzare tabelle di "loggging applicativo".
E' inoltre opportuno evitare statement
di DELETE ma utilizzare la cancellazione logica (con il semplice uso di un flag).
Anche gli statement di UPDATE diretti andrebbero evitati. E' utilizzabile in
questo caso un INSERT e la cancellazione logica del record precedente.
Le possibilita' di configurazione dei backup di Oracle sono parecchie. I manuali e gli help in linea presentano tutte le indicazioni necessarie. Ulteriori notizie si hanno anche sul sito web Oracle.
Deve essere comunque ricordata la possibilita' di utilizzare il log archiving di Oracle che consente diverse possibilita' di recupero dati (cfr. Utilizzo della modalita' di log archiving in Oracle). Il log archiving e' un prerequisito sia del PITR (point in time recovery) che di Data Guard.
E' inoltre spesso utile l'utilizzo della funzione di export per effettuare salvataggi logici. La funzione di export richiede che l'RDBMS sia attivo.
Titolo: Sicurezza dati in Oracle
Livello: Avanzato
Data:
20 Gennaio 1999
Versione: 1.0.2 - 15 Agosto 2012
Autori: mail [AT] meo.bogliolo.name