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.
lunedì 29 settembre 2008
domenica 28 settembre 2008
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.
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.
venerdì 26 settembre 2008
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 ;-)
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.
Ah, il creatore del blog è sempre lui, Rodolfo (Rudy) Baselli.
giovedì 25 settembre 2008
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 ...:
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:
Per sistemare questo errore, googlando un pò trovo:
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:
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:
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:
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...
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
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
Iscriviti a:
Post (Atom)