lunedì 17 novembre 2008

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.

4 commenti:

MAlonzo ha detto...

Ciao Simone,
Chi era il tecnico che vi ha fatto il corso?

Simone Saravalli ha detto...

Si tratta di Franco Anania. Davvero molto bravo e preparato (e uno dei pochi che se gli mandi una mail con qualche domanda ti risponde)!

MAlonzo ha detto...

A parte la sua disponibilità ti posso assicurare che ad oggi è il tecnico più preparato con cui ho mai parlato.

E poi con il fatto che è un tecnico e non un docente a mio parere l'insegnamento è molto più efficace (sempre che mastichi quello di cui lui parla...).

A noi ha fatto lo stesso corso due anni fa. Da li mi sono chiarito mille dubbi che avevo dopo la lettura della documentazione.

Simone Saravalli ha detto...

Qualche tempo fa Franco era venuto ad installare un RAC, ma al tempo di Oracle ne sapevo veramente poco e mi è stato difficile capire le sue spiegazioni. Ora che ho potuto approfondire i vari argomenti sono riuscito a seguirlo come si deve e, in effetti, mi ha già chiarito vari dubbi.
Se avrai voglia di tornare sul mio blog, nelle prossime giornate di corso Franco approfondirà questi argomenti:

- backup/restore/recovery con RMAN
- Grid Control e DataGuard
- performance tuning

Cercherò di illustrarli al meglio delle mie possibilità :-)