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 ;-)

Nuovo gruppo di discussione per DBA Oracle su Facebook

dato che mi sembra un'iniziativa interessante, la segnalo anche qui. Da pochi giorni è nato un nuovo (il primo) gruppo di discussione per DBA Oracle italiani su Facebook. L'unico prerequisito per iscriversi è, ovviamente, disporre di un account su Facebook. Per ora siamo in 22 iscritti e ci sono un paio di post, ma speriamo di crescere velocemente, dai!
Ah, il creatore del blog è sempre lui, Rodolfo (Rudy) Baselli.

Se il buon giorno si vede dal mattino

Inauguro questo blog su Oracle con un episodio che mi è capitato proprio questa mattina appena arrivato al lavoro.
Breve preambolo: alle ore 10:30 doveva iniziare lo stress test di una nuova procedura che abbiamo acquistato qui dove lavoro. Si tratta di un applicativo web-based le cui pagine web vengono servite da due application server Tomcat con SO Windows Server 2003 R2, mentre il db si trova su un RAC Oracle (due nodi Red Hat 5) connesso ad una SAN tramite fibbra ottica (che figata!).
Lo scopo è quello di migliorare le prestazioni dell'applicativo in modo tale da consentire agli utenti (abituati ad un applicativo client-server praticamente con un'interfaccia pseudo-testuale quindi molto veloce rispetto ad una procedura web-based) di lavorare in modo veloce. Questo tuning si riflette a livello di Tomcat, delle pagine web da esso servite e del sottostante db Oracle. Io, almeno in parte, mi occupo di quest'ultimo punto.
Proprio stamattina dunque, la ditta che ci fornisce l'applicativo mi ha caldamente consigliato di portare il parametro processes su ciascuna delle due istanze del nostro RAC, relativamente al db in questione, dal valore 1000 a 4000. Ora, questo parametro che si trova nel spfile del proprio db, indica il numero massimo di processi del sistema operativo che possono connettersi al database Oracle concorrentemente. Impostarlo a 4000, per ciascun nodo, significa in un RAC a due nodi, avere fino a 8000 possibili processi che possono accedere al database.
Dato che l'spfile di un db Oracle è un file binario, non ci si deve manco sognare di aprirlo e modificarlo con un editor di testi, mentre è possibile usare il comando SQL ALTER SYSTEM SET ...:

$ sqlplus /nolog
SQL> connect sys@ as sysdba
SQL> ALTER SYSTEM SET PROCESSES=4000 SCOPE=SPFILE SID='*'

Il parametro SCOPE indica di effettuare l'aggiornamento del valore di processes nel spfile del db, mentre il parametro SID='*' serve per indicare a Oracle di eseguire la modifica per entrambe le istanze del db, dato che ci si trova ad operare su un RAC.
Fatto questo, si stoppano le due istanze tramite il comando srvctl fornito da Oracle, oppure con uno shutdown immediate eseguito sempre come utente SYS o SYSTEM dal prormpt di SQL e poi si riavviano le istanze del RAC per rendere effettiva la modifica apportata al file spfile.
Mi aspettavo che tutto filasse liscio, invece, lanciando il comando per l'avvio delle due istanze del RAC, mi compare questo errore:

ORA-00371: not enough shared pool memory, should be atleast N bytes

Per sistemare questo errore, googlando un pò trovo:

Cause: Init.ora parameter shared_pool_size is too small
Action: Increase the parameter value

Bene, basta incrementare il valore della memoria condivisa assegnata ad Oracle, per ciascuna istanza, nel file spfile, quindi sempre mediante un ALTER SYSTEM, da lanciare come utente SYS e... come faccio ad accedere come utente SYS se il db è giù?
La prima idea che mi è venuta è stata quella di copiare il contenuto del file spfile in un pfile, editarmelo con calma, riportando a 1000 il valore di processes, per poi ricreare l'spfile, ma facendo questo mi sono accorto che il RAC che usiamo qui al lavoro utilizza già di suo un pfile che contiene al suo interno una stringa che riporta la posizione del spfile che poi, di fatto, viene usato per l'avvio delle istanze del RAC Oracle :-( Che fregatura!
A questo punto, l'idea che mi è stata proposta è la seguente: riprendere il pfile utilizzato all'atto della creazione del database e che per fortuna non era stato buttato, avviare con esso le due istanze del RAC, quindi lanciare RMAN (usate sempre RMAN per i backup di Oracle vero?) per il restore del spfile:

$ sqlplus /nolog
SQL> connect / as sysdba
(connesso ad un'istanza sospesa)
SQL> startup pfile='path_al_pfile_recuperato' nomount

Le due istanze ripartono magicamente e in modalità NOMOUNT, importante per eseguire un corretto restore tramite RMAN! Ora bisogna occuparsi del restore del spfile tramite RMAN. Si può riprendere il file spfile dall'autobackup del control file che si imposta in RMAN con la sintassi:

CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
TO '/backup/CF_%F';

Ora ci si può collegare ad RMAN, impostare il DBID (lo si può ottenere da un log eseguito da RMAN quando il database era ancora funzionante) e quindi partire con il restore del spfile:

$ RMAN TARGET /
RMAN set DBID=(DBID)
RMAN> run {
2> set controlfile autobackup format
3> for device type disk to '/backup/CF_%F';
4> restore spfile from autobackup;
5> }

esecuzione comando: SET CONTROLFILE AUTOBACKUP FORMAT
uso del control file del database di destinazione invece del
recovery catalog

Avvio di restore in 25-SET-08
canale allocato: ORA_DISK_1
canale ORA_DISK_1: sid=402 istanza= devtype=DISK

canale ORA_DISK_1: ricerca del backup automatico del giorno: 20080925
canale ORA_DISK_1: ricerca del backup automatico del giorno: 20080924
canale ORA_DISK_1: backup automatico trovato: /backup/CF_c-1453447801-2008
canale ORA_DISK_1: ripristino di SPFILE dal backup automatico completato
restore terminato in 25-SET-08

Dopo lo shutdown e il restart delle due istanze (si può usare sempre srvctl, oppure RMAN, o ancora i comandi SQL shutdown e startup), le istanze incriminate sono tornate online e lo stress test ha avuto inizio.
Sospiro di sollievo...

Primo post del blog

Questo blog nasce da una mia personale esigenza di raccogliere materiale, esperienze, link, informazioni, ecc. sul DBMS Oracle che uso quotidianamente per lavoro, ma che è anche diventato una delle mie principali passioni.
Non sono un DBA e non ho conseguito (ancora!) certificazioni Oracle, ma un pò di esperienza in materia di gestione di DB Oracle la sto maturando, anche in ambiente RAC... e poi oggi i blog sono molto di moda no? :-D