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.

Oracle e i backup - parte I

Una parte fondamentale del lavoro di qualsiasi DBA (o di chi volesse diventarlo, come il sottoscritto) sono i backup dei database. Come al solito, non voglio fornire una spiegazione di TUTTI gli strumenti di backup/restore/recovery messi a disposizione da Oracle, ma focalizzerò l'attenzione su quelli che utilizzo quotidianamente.
Quando ho iniziato a lavorare con Oracle, un mio collega mi ha instradato sull'utilizzo delle utilities exp ed imp; la prima permette di eseguire l'esportazione di uno specifico schema Oracle (struttura del database più i dati in esso contenuti) all'interno di un file con estensione .dmp, mentre la seconda parte da un dump file generato con exp e lo importa nello schema Oracle corrispondente.
I comandi exp ed imp sono forniti con l'installazione di Oracle Database Server quindi possono essere richiamati da un prompt di MS-DOS, oppure da una shell Unix/Linux/Solaris, a seconda del sistema operativo con cui si sta lavorando.
Tali comandi dispongono di un elevato numero di parametri opzionali con cui possono essere lanciati e per cui vi rimando a questa pagina per ulteriori delucidazioni.
In sostanza, exp crea un'istantanea, a caldo, della struttura e dei dati di uno schema Oracle e la salva all'interno di un dump file, mentre imp esegue il passaggio inverso, scompattando il contenuto di un dump file in uno schema vuoto.
I motivi per cui usare queste due utilities sono:

* voglio disporre di un backup della struttura del database (tabelle, indici, constraints, ecc) e dei dati in esso presenti per effettuare un restore rapido (molto utile per db in stadio di sviluppo o test)
* devo inviare ad un collega un'istantanea del db (struttura + dati) per ulteriori elaborazioni

Ma come si usano questi due comandi? Partiamo dall'esportazione:

exp username/password@nome_istanza FILE=nome_file.dmp
LOG=nome_log_gile.log

Quella riportata è la sintassi minima per lanciare l'esportazione di uno schema. Come si può notare è necessario indicare, dopo il nome del comando, il nome dello schema da esportare, la password (se non la si indica qui, verrà richiesta subito dopo aver premuto invio) e il nome dell'istanza in cui si sta lavorando. Quindi, va specificato il nome del file di dump che ospiterà la struttura dello schema con eventuali dati in esso presenti (la direttiva FILE) e un eventuale file di log (opzionale) in cui Oracle memorizza il risultato dell'operazione di esportazione, oltre a visualizzarlo sullo stdout.

Ora invece passiamo all'importazione:

sqlplus system@nome_istanza
SQL> drop user username cascade;
SQL> create user username identified by pwd;
SQL> grant connect, resource to username;
SQL> exit

imp username/pwd@nome_istanza FILE=nome_file.dmp
LOG=nome_log_gile.log FULL=Y

Per prima cosa, va notato che in qualità di utente SYSTEM dell'istanza di riferimento ho effettuato l'eliminazione di un eventuale utente "username" preesistente (attenzione!!!), quindi l'ho ricreato e gli ho assegnato una password e una serie limitata di privilegi.
Fatto questo, sono tornato al prompt di MS-DOS/Linux e ho lanciato l'importazione nello schema vuoto appena creato.
In aggiunta rispetto al comando exp potete notare l'opzione FULL impostata a 'Y' che consente di importare sia la struttura, sia i dati contenuti nel file di dump.
ATTENZIONE! l'operazione di importazione di uno schema può non andare a buon fine se il character set del db di partenza differisce da quello di destinazione. In questo caso si riceveranno parecchi errori relativi a problemi nell'importazione delle statistiche.
L'unica soluzione possibile è quella di mantenere uguale il character set tra tutti i database.
Per ora è tutto! Nel prossimo post introdurrò un altro strumento di backup/restore/recovery, molto più avanzato ed articolato, ossia RMAN!

Piattaforma di sviluppo web con Apache, PHP e backend Oracle

Spesso mi sono occupato di creare pagine web uilizzando il linguaggio server-side PHP, l'ottimo web server Apache ed Oracle come DBMS di backend.
Dato che nel mio posto di lavoro solo ultimamente il software open source sta facendo il suo ingresso, inizialmente non ho trovato una piattaforma di sviluppo web già pronta, ma mi è stata data carta bianca per metterne in piedi una.
La configurazione da me adottata prevede due macchine, un web e un db server, entrambe con sistema operativo Debian GNU/Linux. Sul web server ho installato Apache e PHP con supporto al DBMS Oracle ed all'autenticazione mediante LDAP, mentre sul db server ho installato Oracle 10g XE (la versione limitata di Oracle 10g R2).
Per tenere traccia di tutti i passi di installazione e configurazione da me seguiti ho creato una guida che potete trovare pubblicata sul blog di programmazione web di Valerio (Neryo) Giacomelli e anche su guide.debianizzati.org
e che vi invito a visionare se questa soluzione per lo sviluppo di applicazioni web-based vi può interessare!
Ah, dimenticavo: stufo di avere mille server fisici che poi uno manco si ricorda più a cosa servono, molto spesso, mi sono buttato anche sulla virtualizzazione, riproducendo l'ambiente di cui sopra anche mediante VMware Server, ma questo sarà probabilmente l'argomento di un post futuro.

Usare Ubiquity per le ricerche nella documentazione Oracle

Ubiquity è un plugin per Firefox che permette di effettuare ricerche nel web in modo nuovo, ossia non indicando la parola o l'insieme di parole di interesse per poi venire indirizzati su siti/blog/portali, ecc che ne contengono uno o più riferimenti, bensì indicando cosa si intende fare. Non voglio aggiungere altro su questo plugin e vi invito a vedere il video di presentazione per una panoramica completa sulle sue funzionalità.
Ma cosa c'entra questo interessante plugin con Oracle e la sua documentazione? Beh, fino ad ora, per accedere alla documentazione del nostro DBMS preferito, l'unico sistema era quello di andare direttamente sul sito della Oracle, sezione documentazione, oppure dirigere il proprio browser sull'ottimo Tahiti.
Girovagando per la rete ho trovato un post sul blog di Eddie Awad in cui l'autore spiega che ha creato un comando per Ubiquity chiamato "oradoc" con cui richiamare la documentazione di Oracle versioni 10g e 11g.
Sostanzialmente, Eddie ha creato un feed RSS della pagina di ricerca della documentazione di Oracle versione 10g servendosi di un tool in stile web 2.0 chiamato dapper, quindi ha creato il comando oradoc per Ubiquity; questo comando legge il feed RSS della documentazione e presenta all'utente i risultati della ricerca effettuata direttamente nella finestra di Ubiquity.

Per imparare ad usare ubiquity potete dare un'occhiata a questo screencast.

Ad Oracle non piace la lettera 'U'

Lo so che dal titolo del post non si capisce una mazza, ma ora mi spiego: circa un paio di mesi fa mi sono trovato ad installare Oracle Database Server 10.2.0.1 su una macchina con SO Windows Server 2003 R2 SP2. Lancio OUI, l'installazione parte, ma all'85% circa si blocca con uno strano messaggio di errore che non fmi da molte spiegazioni, ma indica che l'installazione non può proseguire e mi invita a guardare l'alert.log (il quale a sua volta mi dice ben poco). Non capisco! Non è mai capitato prima! Che manca? Forse una qualche componente Java? Qualche file richiesto da OUI per portare a termine l'installazione? Non sono soddisfatti i prerequisiti di rete richiesti da Oracle? Per farla breve, giorni di ricerche in rete e alla fine, ormai in preda alla disperazione arrivo a questa interessante pagina (purtroppo non avevo ancora accesso all'ottimo Metalink, altrimenti forse avrei risolto prima il mio problema).
In sostanza, la versione 10.2.0.1 di Oracle ha un bug per cui dbconsole non funziona correttamente se l'hostname della macchina su cui si vuole installare Oracle Server inizia con la lettera 'U'. Ma che sfiga!!! In questo caso, solo modificando il nome dell'host e ripetendo l'installazione, Oracle è andato su tranquillamente. Ad ogni modo, questo bug affligge tutte le versioni di Oracle tipo 10.2.0.x ed è stato fissato solo con la versione 11g, quindi occhio ;-)