Il primo post verteva sull'uso dei comandi exp ed imp per l'esportazione ed importazione, a caldo, ossia eseguibile anche a database attivo, di uno schema Oracle sfruttando un file binario intermedio (il cosiddetto dump).
Questo secondo post, invece, è relativo ad RMAN (Recovery MANager), un utile strumento messo a disposizione da Oracle per il restore ed il recovery di un database (compresi anche i file fisici presenti su disco fisso, come control files, datafiles, spfile, redo logs, archivelogs, necessari al suo funzionamento).
Come al solito, vorrei focalizzare l'attenzione sull'uso che faccio di RMAN al lavoro, sia per gli ambienti di test, sia per quelli in produzione, senza per questo replicare la già abbondante documentazione esistente sull'uso di questo comando. Se siete interessati ad approfondire l'argomento, come di consueto in coda a questo post ho aggiunto alcuni link (e non dimenticate il buon Google).
Il modo più semplice per invocare RMAN è tramite l'utilizzo della command line, dopo aver specificato il SID dell'istanza Oracle di cui gestire il backup/restore/recovery (per sistemi Microsoft Windows utilizzare il comando set al posto di export):
$ export ORACLE_SID=
$ rman TARGET /
Una volta ottenuto il prompt di RMAN, se ne possono impostare i parametri di funzionamento, eseguire backup, restore (il ripristino di componenti di un db Oracle come datafile, control files, redo logs, ecc. corrotte, ad esempio in seguito alla rottura del disco fisso su cui erano memorizzate), oppure il recovery (effettuato dopo il restore, permette di riportare i dati contenuti in un database nello stato in cui si trovavano prima che si verificasse il guasto, come la rottura di un disco fisso del db server, oppure la corruzione di un file importante per il db, o ancora l'interruzione della corrente elettrica).
In alternativa, è possibile creare un file dei parametri da passare ad RMAN ogniqualvolta esso viene eseguito. Questa soluzione si rivela molto utile quando si vuole schedulare periodicamente l'esecuzione di RMAN mediante strumenti come cron per GNU/Linux, oppure Operazioni Pianificate di Microsoft Windows.
RMAN permette di creare diverse tipologie di backup (full, incrementale), di varie componenti di un db Oracle (datafiles, control file, spfile, redo logs, archivelogs, altri backup di RMAN), in diversi formati (backup pieces, image copies) e su differenti tipologie di supporto (disco fisso, nastro).
RMAN può essere configurato secondo le proprie necessità semplicemente impostando alcuni tra i numerosi parametri messi a disposizione da questo potente strumento. Prima di passare al codice degli script che utilizzo quotidianamente al lavoro vorrei delineare la politica di backup da me adottata:
* 1 backup incrementale di livello 0 una volta al giorno alle ore 20:00
* 1 backup incrementale di livello 1 alle ore 8:00, 13:00 e 18:00
Il backup incrementale delle ore 20:00 effettua il backup di tutti i blocchi dati contenuti in un datafile perciò le dimensioni del backup piece, o dell'image copy risultante, a seconda del sistema utilizzato, potranno essere anche notevoli. I backup incrementali di livello 1, invece, vengono definiti differenziali (ed è il caso di quelli che creo io con RMAN) quando vengono memorizzati i blocchi di dati a partire dal più recente backup di livello 0 o di livello 1, oppure cumulativi se vengono memorizzati i blocchi modificati a partire dal più recente backup incrementale di livello 0, come evidenziato nell'immagine sottostante.
Perchè utilizzo questa strategia? Fondamentalmente perchè le dimensioni dei backup set creati quotidianamente da RMAN per il mio database di produzione sono nell'ordine del GB, una quantità di spazio relativamente irrisoria da memorizzare su una NAS, una SAN, oppure da spostare su un file server remoto via rete (tra l'altro, i backup pieces prodotti da RMAN sono normali files che è possibile comprimere prima di un'eventuale copia in rete via ftp, rsync, scp, o altro. In questo modo diminuisce il tempo di trasferimento dei files e la loro dimensione, ma aumenta il tempo di un eventuale restore/recovery da quei files che andranno prima riportati sul db server e scompattati per poterli effettivamente utilizzare).
Quello che segue è il file dei parametri che utilizzo per RMAN:
# -------------------------------------------------
# Script per eseguire un backup incrementale a caldo
# di livello 0
#
# --------------------
# Default e Politiche
# --------------------
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
CONFIGURE MAXSETSIZE TO UNLIMITED;
# --------------------------------
# Backup di control file + sp file
# --------------------------------
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
TO '/backup//CF_%F';
# -----------------------------------------------------
# Creazione del redundancy set costituito da:
# - backup dei datafiles
# - backup degli archive redo logs
# - backup del control file
BACKUP
DEVICE TYPE DISK
AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 0
DATABASE
FORMAT '/backup//DATAFILE_%d_%T_%t_%s_%p'
TAG 'INCREMENTAL LEV 0'
PLUS ARCHIVELOG
FORMAT '/backup//ARCH_%d_%T_%t_%s_%p'
SKIP INACCESSIBLE;
BACKUP CURRENT CONTROLFILE FORMAT
'/backup//SOLO_CF_%d_%T_%t_%s_%p'
tag='CF a parte';
# -----------------------------------------------------
# -----------------------------------------------------
# elimino i files obsoleti (compresi gli archivelogs)
DELETE force noprompt obsolete;
# -----------------------------------------------------
Ho lasciato i commenti al codice per tenermi in mente cosa combina! Come si può notare, per prima cosa vengono impostati alcuni parametri per RMAN, come la recovery window, ossia per quanto tempo mantenere un backup piece nello stato 'AVAILABLE' prima di considerarlo obsoleto (che non significa necessariamente inutile per un eventuale restore/recovery), ma anche il tipo di device su cui eseguire i backup (in questo caso su disco) e così via.
Importante è la parte relativa all'impostazione dell'autobackup che permette di creare in automatico un backup di control file + spfile da inserire in un backup piece separato rispetto a quelli dei datafiles e degli archivelogs.
Con l'istruzione BACKUP ... DATABASE PLUS ARCHIVELOG ... si avvia il backup, appunto, incrementale di livello 0 (o di livello 1 a seconda del valore impostato) dei datafiles e degli archivelogs (grazie all'istruzione 'CONFIGURE BACKUP OPTIMIZATION ON' vengono tralasciati gli archivelogs già backuppati una volta su disco riducendo, di fatto, la dimensione dei backup pieces risultanti).
Inoltre, viene creato un ulteriore backup a sè stante per il control file. Backuppo quotidianamente il control file non solo perchè si tratta di un elemento fondamentale per un database Oracle (altrimenti non se ne può nemmeno effettuare lo startup), ma soprattutto perchè RMAN memorizza al suo interno record relativi ai backup files necessari per un eventuale restore/recovery (a meno di non utilizzare un recovery catalog esterno).
L'ultima istruzione, 'DELETE force noprompt obsolete' permette di fare un pò di pulizia rimuovendo i backup considerati obsoleti, ossia che non rientrano nella recovery window impostata precedentemente (pari a 4 giorni).
Per chi volesse approfondire l'argomento backup con RMAN lascio qualche utile link:
Oracle® Database Backup and Recovery Quick Start Guide
Oracle® Database Backup and Recovery Basics
Oracle® Database Backup and Recovery Reference
Oracle® Database Backup and Recovery Advanced User's Guide
Nessun commento:
Posta un commento