Vi sono molte realta' in cui la sicurezza (disponibilita') dei dati riveste un'importanza fondamentale. Per ottenere la massima sicurezza sui dati l'RDBMS Oracle deve essere attivato in modalita' di log archiving.
Se il log archiving e' attivo e correttamente configurato sono presenti diverse funzionalita':
In questo documento vengono descritti i principali elementi relativi all'utilizzo del log archiving.
Un database viene installato senza il log archiving attivo. I passi per l'abilitazione sono i seguenti:
A questo punto l'RDBMS opera in modalita' di log archiving.
Quando Oracle opera in modalita' di log archiving ed e' attivo l'archiving automatico viene utilizzato il processo ARCH. Il processo ARCH si occupa di copiare, nella directory di destinazione, i file di online redo log non appena sono stati riempiti.
Puo' essere utile forzare il passaggio da un redo log al sucessivo, se il log archiving e' attivo il processo ARCH si occupera' di copiare il redo log lasciato libero nella directory dei log archiviati. Il comando da utilizzare e' alter system switch logfile
La configurazione dei parametri del log archiving viene effettuata nel file initX.ora.
E' importante dimensionare correttamente i file di log. Un'ampia dimensione (eg. 5MB) diminuisce il numero di chekpoint e di attivita' di archiving. E' pertanto consigliata (e' consigliata comunque su DB con elevata attivita' transazionale).
Il numero dei gruppi di file di log deve essere almeno pari a tre. Un numero maggiore di gruppi non offre particolari vantaggi.
La directory su cui vengono archiviati i file di log deve essere correttamente dimensionata.
Se lo spazio su tale directory si esaurisce Oracle blocca ogni attivita' transazionale sull'RDBMS fino a quando non si libera spazio. In tal modo l'RDBMS Oracle assicura che ogni transazione sia recoverabile (anche a costo di non effettuare altre transazioni).
Il disco su cui vengono archiviati i redo log deve essere differente da quello in cui sono posti gli altri componenti dell'RDBMS. Solo in tal modo si ha la garanzia di poter comunque recuperare i dati anche in caso di perdita completa di un disco.
Deve essere pertanto effettuato un dimensionamento basandosi sul numero di redo log archiviati, la loro dimensione e l'intervallo di tempo tra backup fisici.
La valutazione non e' complessa:
Con tali elementi si ottiene la stima del dimensionamento.
Deve essere posta attenzione ad attivita' estemporanee sul database (creazione indici, creazione di tabelle con ampi parametri di storage, import, riorganizzazioni dati, update pesanti, ...). Duranti tali attivita' il numero di redo log archiviati puo' essere molto elevato ed il rallentamento delle attivita' puo' essere sensibile.
Durante tali attivita' viene tipicamente disattivato il log archiving.
ATTENZIONE: se il log archiving viene disattivato per recuperare i dati e' possibile utilizzare solamante i backup fisici.
E' possibile effettuare alcune operazioni in modalita' UNRECOVERABLE (eg. creazione di indici o tabelle applicative temporanee, vedi Novita' presenti in Oracle 7.3) in pratica disattivando l'ARCHIVING degli oggetti creati in tale modalita'.
Per sfruttare adeguatamente le possibilita' del log archiving e' necessario effettuare salvataggi fisici. Per i salvataggi fisici si utilizzano le normali utilita' di sistema per effettuare copie (eg. su Unix dd, cpio, tar).
Il backup fisico deve essere effettuato a database non attivo. Il database deve essere in modalita' di log archiving: non e' possibile effettuare il backup e quindi attivare il log archiving.
Debbono essere salvati tutti i componenti dell'RDBMS:
E' opportuno inoltre salvare anche i file di configurazione (init e config).
Periodicamente debbono essere salvati anche gli archived redo log. E' anche opportuno ripulire periodicamente le directory che li contengono. Ad esempio su Unix e' possibile utilizzare il seguente crontab che mantiene su file system due giorni di log archivati:
55 23 * * * find /data02/orabck/arc -name 'arch.*' -mtime +2 -exec rm {} \;>> /dev/null 2>&1
E' opportuno disporre sempre di piu' copie di backup in modo da avere piu' modalita' di ripristino dei dati in caso di problemi. Debbono quindi essere predisposte opportune politiche di ritenzione dei supporti fisici su cui si effettuano i salvataggi.
L'utilizzo del log archiving e dei backup fisici non esclude l'utilizzo dei salvataggi logici dei dati con il comando di exp. L'utilizzo dell'export e' complementare ai salvataggi fisici, in una corretta strategia di backup sono presenti entrambe le modalita'.
Salvataggio dati a database attivo
E' possibile effettuare salvataggi fisici a database attivo. In questo caso il tablespace da salvare deve essere posto in stato di BACKUP (alter tablespace begin backup) e quindi posto nuovamente in linea al termine del backup (alter tablespace end backup). L'operazione deve essere effettuata per tutti i tablespace presenti anche se eventualmente in momenti e con frequenze differenti. Durante l'operazione e' possibile operare liberamente sui dati presenti nel tablespace.
L'operazione e' pesante e presenta alcune complessita'. E' pertanto da utilizzare solo nel caso in cui sia l'unica possibilita' (utilizzo 7x7, 24x24).
Le attivita' di recovery consentono il recupero del funzionamento e dei dati di un RDBMS.
Le possibili azioni dipendono dal problema presentatosi. Puo' essere utile comunque riportare i passi necessari in caso di rottura di un disco su cui era presente un datafile in raw device (che e' un caso putroppo comune):
Sono possibili diverse altre modalita' di recupero. Ad esempio e' possibile effettuare un recupero dati fino ad un momento preciso (alter database recover until time '1995-12-31:12:50') oppure fino ad un determinato log (con la modalita' until cancel o until change). Nel caso di ripristino parziale e' necessario resettare i file di log con il comando alter database open resetlogs...
Possono essere recuperati errori relativi non solo ai datafile, come negli esempi, ma anche ai redo log ad ai control file...
La documentazione Oracle sull'argomento del recupero dei dati e' molto ampia e precisa. Alcune informazioni specifiche sono riportate nel documento Attivita' di recovery sull'RDBMS Oracle.
Se correttamente configurato il log archiving non presenta svantaggi prestazionali su un tipico sistema OLTP. L'unica attivita' svolta dal processo di ARCH e' infatti quella della copia degli online redo log. Inoltre ponendo su device differenti i redo log archiviati non si presentano conflitti su risorse e l'utilizzo del log archiving risulta quindi trasparente.
Come gia' riportato, l'unica avvertenza e' quella di non utilizzare la modalita' di log archiving quando si effettuano pesanti riorganizzazioni dei dati.
Testo: Utilizzo della
modalita' di log archiving in Oracle
Data: 17 Maggio 1997
Versione: 1.0
Autore: mail@meo.bogliolo.name