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...