Oracle e i backup - parte I - UPDATE

Come si può notare dal titolo, questo post non è la seconda parte della serie "Oracle e i backup", bensì un update del primo post che ho pubblicato sull'argomento.

Sostanzialmente, questa mattina mi si è presentata la necessità di clonare uno schema Oracle, chiamiamolo SORGENTE in un nuovo schema che, con notevole sforzo di fantasia chiamerei DESTINAZIONE. Da notare che entrambi gli schemi si trovano sullo stesso database.
Questi sono i passaggi che ho seguito:

* Creazione dell'utente DESTINAZIONE. Per comodità, ho utilizzato Enterprise Manager e, in particolare, l'opzione "Crea con copia" messa a disposizione nella pagina di gestione degli utenti, specificando l'utente SORGENTE come punto di partenza per l'operazione di clonazione, appunto. In questo modo, ho ottenuto un utente con gli stessi privilegi (tablespace a cui accedere, tipologia di operazioni DDL e DML, ecc)

* Esportazione mediante l'utility exp dello schema SORGENTE

exp SORGENTE/pwd@SID file=/path/expdata.dmp log=/path/explog.log

* Importazione del dump nello schema DESTINAZIONE precedentemente creato

imp DESTINAZIONE/pwd@SID fromuser=SORGENTE touser=DESTINAZIONE
file=/path/expdata.dmp log=/path/explog.log

Stop. Non c'è altro da fare e in questo modo DESTINAZIONE diventa un clone dello schema SORGENTE sul quale lavorare in tutta sicurezza!

Tanti link per Oracle su delicious

Da un'iniziativa di Rodolfo Baselli e Cristian Cudizio è nato poche settimane fa un gruppo su Facebook chiamato Oracle DBA Italia (se siete iscritti a Facebook e vi interessate di Oracle, lo potete trovare facilmente utilizzando la stringa "oracledbaitalia" nell'apposito motore di ricerca; l'iscrizione è aperta a tutti quindi fatevi pure avanti!)

Tra i vari thread aperti ne è stato iniziato uno relativo ai link su Oracle ed affini di cui tutti noi interessati all'argomento disponiamo e che sarebbe utile poter condividere.
Al fine di non disperdere questi collegamenti tra tanti thread, ho pensato di riunirli tutti in un'unica pagina su del.icio.us.
Di tanto in tanto, quando scopro qualche nuova risorsa, la aggiungo su delicious, ma se ne avete di nuove rispondete pure a questo post che le accodo!

Questo il link alla pagina del gruppo Oracle DBA Italia su delicious: Oracle DBA Italia

Corso Oracle @ UniFE, giorno primo

Ok, lo so che è una vita che non pubblico più un post, ma cercavo l'ispirazione giusta e questa è arrivata giovedì scorso durante la prima giornata del corso Oracle promosso dall'Università di Ferrara per cui lavoro.
Sono stati toccati i temi più svariati che voglio elencare qui per non dovermeli tenere su un txt sparpagliato in mille versioni su altrettanti pc come al solito :-)

Innanzitutto, il nostro relatore (un ragazzo simpatico che non sopporta quando un sistema operativo, oppure Oracle, viene installato in lingua italiana, hehehe) ha proposto un link molto interessante:
Oracle Free and Open Source Software un utile aggreatore di materiale FOSS creato da e per Oracle e che ho prontamente aggiunto ai miei preferiti.
Secondo punto all'ordine della giornata: una breve introduzione al concetto di backup con RMAN (e che sarà anche l'argomento di uno dei miei prossimi post).
Abbiamo dato un'occhiata agli script di backup con RMAN che utilizziamo attualmente al lavoro; tra tutti i parametri presenti negli script, PARALLELISM ha destato la mia attenzione: si tratta di un parametro che consente ad RMAN di parallelizzare, appunto, la creazione dei backup pieces su N processori/core, dove N è il valore con cui si imposta tale parametro. Per database di piccole dimensioni non si notano grandi incrementi di prestazioni impostando PARALLELISM ad un valore > 1, ma le cose cambiano per database con notevoli quantità di dati (nell'ordine delle decine o centinaia di GB).
Anche se al momento backuppo un db con solo qualche GB di dati ho impostato PARALLELISM a 2 mediante la direttiva

CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET

Altro punto relativo ai backup con RMAN riguarda le operazioni di pulizia dei backup piece e degli archivelog obsoleti: io di solito utilizzo un unico comando:

DELETE FORCE NOPROMPT OBSOLETE RECOVERY WINDOW OF 4 DAYS

Il relatore ha consigliato anche quest'altro per la rimozione esplicita degli archivelog più vecchi di due giorni e di quelli già backuppati su disco almeno una volta:

DELETE NOPROMPT ARCHIVELOG UNTIL TIME 'sysdate -2' BACKED UP
1 TIMES TO DISK;

Terzo punto all'ordine del giorno: i database di standby. Si tratta di un ulteriore meccanismo di backup disponibile già dalla versione 8i di Oracle che consiste nel disporre di un database replica costantemente aggiornato del proprio db di produzione.


Come si può notare dall'immagine qui sopra, il database di standby rimane allineato con l'ambiente di produzione applicando gli archivelog ricevuti da quest'ultimo.
I processi LGWRn, oltre ad occuparsi della scrittura del contenuto della redo log cache (una parte della SGA) nei redo log files, inviano anche i log archiviati al database di standby. Questa procedura, a livello di carico di CPU e di bandwidth impatta veramente molto poco.
Grazie all'applicazione degli archivelog, il database di standby può mantenere il proprio SCN (System Change Number) quasi constantemente allineato con quello del database di produzione.
Va detto che un database di standby, quando si trova in tale modalità, non è fruibile in lettura/scrittura dagli utenti, tuttavia, all'occorrenza può essere posto in modalità read-only per consentire operazioni di consultazione. In questo caso, il database di standby non può ricevere nè applicare gli archivelog inviati dalla produzione finchè non viene nuovamente posto in standby mode.
Se nella propria strategia di restore/recovery si utilizzano strumenti come exp/imp, RMAN e standby database in combinata (oltre ad una ormai indispensabile ridondanza hw garantita da sistemi RAID, sistemi di mass storage come SAN, NAS, ecc) si ottiene un livello di fault tolerance molto vicini al 100%.
Aggiungo nioltre, che la tecnologia dei database di standby è stata recentemente rinominata (a partire da Oracle 10g) in Oracle Data Guard

Quarto punto all'ordine del giorno: realizzazione di un "muletto", come lo ha simpaticamente definito il relatore. In buona sostanza, il muletto è un server, possibilmente ben carrozzato a livello hardware su cui centralizzare i seguenti servizi:

* Grid Control
* Catalog per RMAN
* Ambiente di restore/recovery

Ma andiamo con ordine, Grid Control è una tecnologia Oracle nata allo scopo di monitorare altri server/servizi attraverso un unico "pannello di controllo".


La macchina che ospita il Grdi Control deve disporre di almeno 2 GB di RAM e di 40 GB di spazio disco ed è composta dai seguenti elementi:

* interfaccia web in ascolto sulla porta 7778
* il web server Apache che comunca con l'interfaccia web mediante la porta 8887 e si pone in ascolto sulla porta 4889 per ricevere informazioni dagli agent installati sui server da monitorare
* una serie di Java apps
* un database in cui vengono memorizzati i dati inviati dagli agent

Come già detto, Grid Control riceve dati ed informazioni dagli agent che consentono di monitorare non solo db server Oracle, ma anche molte altre tipologie di servizi.

Il secondo ruolo del "muletto" sarà quello di catalog per RMAN; attualmente, tutte le informazioni necessarie ad RMAN per gestire le operazioni di backup/restore/recovery per il mio db sono contenute nel controlfile, ma questa non è una situazione sicura per almeno due motivi:

* se si corrompono tutte le copie del controlfile, RMAN perde le informazioni relative ai backup disponibili e diventa di fatto inutilizzabile
* se i record di backup memorizzati nel controlfile vengono sovrascritte troppo in fretta, RMAN perde importanti informazioni relative ai backup disponibili

L'idea di base, dunque, è quella di disporre di un recovery catalog di RMAN per tutti i database sul muletto. A questo punto, si può lanciare da una qualsiasi postazione con un client Oracle installato ed opportunamente configurato, il backup di un qualsasi database Oracle collegandosi al catalog di RMAN residente sul muletto, appunto (per un howto su questo argomento mi appunto di scrivere un post apposito). Lo stesso, ovviamente, vale per le operazioni di restore/recovery.
Terzo ed ultimo ruolo del muletto sarà quello di fungere da sandbox, cioè da ambiente protetto per fare simulazioni di disastri (perdita di datafile, controlfile, ecc) e per i conseguenti test di restore/recovery.
Nei prossimi post cercherò di illustrare al meglio le operazioni di installazione e configurazione delle varie componenti del muletto.