L'oracolo dei database

Una nuova avventura

2009-05-17T10:21:00.004+02:00

Nella vita, si sa, capita di porsi delle domande su quanto fatto fino ad un certo punto della propria esistenza, sia essa affettiva, lavorativa, ecc. Si tirano un pò le somme e questo è quanto è accaduto anche a me negli ultimi mesi, in particolare per quanto riguarda il mio lavoro.

Una premessa è d'obbligo: in questi due anni e mezzo di lavoro ho potuto collaborare con colleghi, soprattutto quelli del mio stesso ufficio, che mi hanno trattato bene, dal lato umano come da quello professionale, che mi hanno sopportato ogniqualvolta ho rotto le scatole con le mie guerre ideologiche Windows VS GNU/Linux ;), dai quali ho imparato molto (e ai quali spero di aver lasciato qualcosa, nel mio modestissimo piccolo bagaglio di conoscenze).

In secondo luogo, il mio attuale lavoro, sistemista e dba Oracle, mi piace molto e ho sempre cercato di portarlo avanti con passione, condividendo conoscenze con tanti altri appassionati del settore, il che mi ha molto aiutato a crescere professionalmente.

Tuttavia, forse per la giovane età (27 anni compiuti l'altro ieri ;), forse per la necessità di fare qualche nuova esperienza, di tagliare un pò il cordone ombelicale che ti lega alle comodità, alla famiglia, al lavoro attaccato a casa, ho cercato un'altra opportunità di lavoro, trovandola!
Come indicato molto chiaramente dall'immagine di apertura del post, una via si sta per chiudere, ossia la mia attività di dba Oracle e un'altra si apre al suo posto, il mio nuovo lavoro: sistemista GNU/Linux (hehehehehe).

Cambierà un pò tutto: dal pubblico passo al privato, da dba Oracle e sistemista generico, passo a sistemista GNU/Linux a tempo pieno, da Ferrara mi sposterò in quel di Casalecchio di Reno, dalla vita in casa con i miei, alla vita indipendente in appartamento (devo solo trovarlo ;) ) e chissà quante altre cose. Ma cavolo, se non lo faccio ora, ho come l'impressione che non lo farei mai più!!!

Insomma, questo è un pò il post conclusivo del mio blog che, comunque, ho deciso di non eliminare dato che contiene il frutto di due anni di lavoro con Oracle, di smanettamenti, di ore passate su siti, forum, mailing list per cercare (e qualche volta dare) soluzioni ai problemi che ogni giorno si presentano nella vita di un dba!

Un saluto a tutti! Simone

Ubuntu e Oracle SQL Developer

2009-04-28T14:40:00.009+02:00

Qualche giorno fa, stanco delle continue infezioni di Conficker e forte del fatto che il mio pc è una semplice workstation dalla quale mi collego sulle macchine vere e proprie con cui lavoro (un misto di ambienti Windows Server 2003 e GNU/Linux, reali e virtualizzati), ho pensato di formattare il mio pc che montava Windows XP per passare ad Ubuntu 8.10.

Uno strumento che uso ormai da qualche tempo e che mi dà le stesse soddisfazioni di Toad (ma in più è free e non richiede licenze) è Oracle SQL Developer. Questo software è realizzato in Java quindi è disponibile per diverse piattaforme, tra cui GNU/Linux, anche se non esiste un pacchetto deb per le distribuzioni Debian e Debian like. Volendo è possibile usufruire del tool Alien per convertire l'rpm in deb, oppure si può sempre scaricare un file zip contenente l'intero ambiente già pronto per l'uso.

La versione per GNU/Linux non viene fornita con il Java SDK, necessario per far girare l'interfaccia di SQL Developer, ma con Ubuntu 8.10, ad esempio, si può facilmente porre rimedio alla mancanza con:

$ sudo aptitude install sun-java6-jdk

Supponendo di voler utilizzare il file zip fornito da Oracle, lo si può scompattare, ad esempio, in /usr/src/:

$ tar xzf sqldeveloper-1.5.4.59.40-no-jre.zip
$ sudo mv sqldeveloper /usr/src/

Lo script da lanciare è contenuto in /usr/src/sqldeveloper (il path è da adattare a seconda della directory di installazione scelta):

$ cd /usr/src/sqldeveloper
$ ./sqldeveloper.sh

Tuttavia, si può notare la comparsa sul terminale di un messaggio di errore:

Oracle SQL Developer
Copyright (c) 2008, Oracle. All rights reserved.

Type the full pathname of a J2SE installation (or Ctrl-C to quit), the path will be stored in ~/.sqldeveloper/jdk

In questo caso, bisogna terminare la creazione dello script con Ctrl-C, quindi creare una directory chiamata .sqldeveloper (attenzione al punto prima del nome, in quanto si tratta di una directory nascosta) nella propria home e all'interno di tale directory creare un file chiamato jdk. Tale file deve contenere il path alla jvm quindi:

$ mkdir /home/username/.sqldeveloper
$ cd ~/.sqldeveloper
$ touch jdk
$ echo /usr/lib/jvm/java-6-sun > jdk

Fatto ciò si può avviare SQL Developer in tutta tranquillità!

Windows Vista e SP2-1503

2009-04-28T13:20:00.009+02:00

Un mio collega ha appena acquistato il classico portatile con Microsoft Windows Vista Home Premium SP1 (eh vabbè...) e, dato che la sua attività routa attorno alla creazione di web apps che si interfacciano ad Oracle, ha provato ad installare, sul suddetto portatile, Oracle Instant Client 10.2.0.1. Ha seguito la procedura standard, optando per un'installazione da amministratore, impostato il tnsnames.ora con le entries corrette, eppure, lanciando un prompt di sqlplus, oppure Toad, ecc, si presenta il seguente errore:

Sul forum di OTN si consiglia di:

1) impostare correttamente le variabili d'ambiente ORACLE_HOME, TNS_ADMIN, LD_LIBRARY_PATH e PATH
2) controllare le impostazioni di protezione di Windows in quanto mancherebbe il permesso "create global objects"

Ora, la soluzione numero 1 non ha funzionato e, a quanto pare, in Windows Vista Home Premium SP1 non c'è la possibilità, o almeno io non l'ho trovata, di accedere alle policies locali di sicurezza, quindi non ho potuto verificare l'effettiva mancanza del privilegio "create global objects" per il mio utente.

San Google, come al solito, è venuto in mio aiuto con questo articolo di Christian Shay in cui l'autore indica che per Windows Vista è disponibile un pacchetto che consente di installare Oracle Client 10.2.0.3 direttamente, ossia senza la necessità, come avveniva in precedenza, di installare il client nella versione 10.2.0.1 per poi patcharla alla 10.2.0.3 che, di fatto, risolve il problema SP2-1503.
Riporto a mia volta il link per il download del client Oracle versione 10.2.0.3 per Windows Vista/windows 2008!

Installato questo pacchetto tutto è filato liscio, finchè non ho tentato una connessione al mio db di test con TOAD ritrovandomi con il seguente errore (bello Vista, sì sì):

Altra ricerca con Google ed approdo sul sito asktoad.com e più precisamente in questa FAQ; qui si legge che il problema è determinato da UAC: User Access Control, ossia il sistema di controllo degli accessi degli utenti di Windows Vista che, quando abilitato (e lo è per default), non consente ad un utente normale di accedere in scrittura alla directory Program Files. Sempre dalla FAQ si legge che quando Toad 9.5 viene installato crea un file chiamato lexlib.new che, nel momento in cui si lancia la GUI di Toad dovrebbe poter essere rinominato in lexlib.lxl, fatto non consentito proprio da UAC (a meno di eseguire Toad come utente Administrator).

Esistono due soluzioni:

* disabilitare UAC, ad esempio come indicato in questa guida
* eseguire Toad come utente amministratore

Io ho optato per la prima opzione, che è molto semplice da implementare!

Startup e shutdown

2009-04-02T11:18:00.029+02:00

L'avvio e lo spegnimento di Oracle sono due procedure importanti che è necessario saper eseguire in modo corretto per garantire il funzionamento del DBMS stesso, nonchè l'integrità dei dati gestiti tramite esso.

I servizi (demoni in ambito GNU/Linux) da avviare prima di poter interagire con Oracle sono il listener e una o più istanze.
Con Microsoft Windows, i servizi a cui fare riferimento sono:

* OracleServiceSID: il servizio di bootstrap di oracle che permette l'avvio dell'istanza indicata dalla stringa "SID". Una volta avviato il servizio OracleServiceSID è possibile avviare/stoppare manualmente l'istanza
* OracleHOME_NAMETNSListener: è il servizio che si occupa di controllare il listener Oracle

Agli amministratori di Oracle su sistemi Microsoft Window consiglio di dare un'occhiata a questa descrizione (in inglese, ma molto chiara) dettagliata e completa dei servizi Oracle, delle variabili d'ambiente che è necessario impostare e delle chiavi di registro fondamentali per Oracle!

Se si predilige il sistema operativo GNU/Linux (come nel mio caso ;), Oracle mette a disposizione il comando "lsnrctl" per la gestione del listener e lo script "dbstart" per l'avvio di una o più istanze. Entrambi si trovano nella directory "$ORACLE_HOME/bin".
Al fine di automatizzare startup e shutdown di Oracle (listener + istanza/e, quindi), io utilizzo questo semplice script trovato in rete e che ho chiamato "gestoracle.sh":

#!/bin/bash
#
# Run-level Startup script for the Oracle Instance and Listener
#
# chkconfig: 345 91 19
# description: Startup/Shutdown Oracle listener and instance

#ORA_OWNR="oracle"

# if the executables do not exist -- display error

if [ ! -f $OH/bin/dbstart -o ! -d $OH ]
then
echo "Oracle startup: cannot start"
exit 1
fi

# depending on parameter -- startup, shutdown, restart
# of the instance and listener or usage display

case "$1" in
start)
# Oracle listener and instance startup
echo -n "Starting Oracle: "
$OH/bin/lsnrctl start
$OH/bin/dbstart $ORACLE_HOME
echo "OK"
;;
stop)
# Oracle listener and instance shutdown
echo -n "Shutdown Oracle: "
$OH/bin/lsnrctl stop
$OH/bin/dbshut $ORACLE_HOME
echo "OK"
;;
reload|restart)
$0 stop
$0 start
;;
*)
echo "Usage: $0 start|stop|restart|reload"
exit 1
esac
exit 0

Per lanciare lo script è sufficiente loggarsi sul db server con un utente appartenente al gruppo dba ed eseguire da command line:

$ ./gestoracle.sh start|stop|restart|reload

A seconda del parametro passato, gestoracle.sh avvia o stoppa il listener e lo script di gestione del'istanza da avviare.
Il risultato dell'esecuzione di gestoracle.sh è questo:

oracle@debiandb:~$ gestoracle.sh start
Starting Oracle:
LSNRCTL for Linux: Version 10.2.0.4.0 - Production on 02-APR-2009 08:58:14

Copyright (c) 1991, 2007, Oracle. All rights reserved.

Avvio di /u01/app/oracle/product/10.2.0/db_1/bin/tnslsnr: attendere...

TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Il file dei parametri di sistema è /u01/app/oracle/product/10.2.0/db_1/network/
admin/listener.ora
Messaggi di log registrati in /u01/app/oracle/product/10.2.0/db_1/
network/log/listener.log
Ascolto su: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
Ascolto su: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=debiandb)(PORT=1521)))

Connessione a (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1)))
STATO del LISTENER
------------------------
Alias LISTENER
Versione TNSLSNR for Linux: Version 10.2.0.4.0 - Production
Data di inizio 02-APR-2009 08:58:14
Tempo di attivitÃ 0 giorni 0 ore 0 min. 0 sec.
Livello trace off
Sicurezza ON: Local OS Authentication
SNMP OFF
File di parametri listener/u01/app/oracle/product/10.2.0/db_1/network/admin/
listener.ora
File di log listener /u01/app/oracle/product/10.2.0/db_1/network/log/
listener.log
Summary table degli endpoint di ascolto...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=debiandb)(PORT=1521)))
Summary table dei servizi...
Il servizio "PLSExtProc" ha 1 istanze.
L'istanza "PLSExtProc", stato UNKNOWN, ha 1 handler per questo servizio...
Il comando è stato eseguito
OK

Ora che il DBMS è attivo è possibile avviare l'istanza desiderata (assicurarsi sempre che la variabile di sistema ORACLE_SID sia correttamente impostata):

oracle@debiandb:~$ export ORACLE_SID=TEST
oracle@debiandb:~$ sqlplus /nolog

SQL*Plus: Release 10.2.0.4.0 - Production on Gio Apr 2 08:58:39 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

SQL> conn/as sysdba
Connesso a un'istanza sospesa.

SQL> startup
Istanza ORACLE avviata.

Total System Global Area 1174405120 bytes
Fixed Size 1267116 bytes
Variable Size 620759636 bytes
Database Buffers 536870912 bytes
Redo Buffers 15507456 bytes
MOUNT del database eseguito.
Database aperto

La procedura di "apertura" di un database è composta da più livelli:

* LIVELLO 0 - database chiuso: l'istanza è spenta e gli utenti non possono eseguire login, accedere ai dati contenuti nel db, ecc.
* LIVELLO 1 - NOMOUNT: lanciando il comando

SQL> startup nomount

Oracle legge il contenuto del spfile che contiene le informazioni essenziali per l'avvio dell'istanza specificata dalla variabile di sistema ORACLE_SID (ad esempio, la dimensione delle varie aree di memoria RAM da riservare all'istanza, la dimensione dei blocchi di dati, il character set, ecc), quindi avviene l'avvio dell'istanza mediante allocazione di una certa quantità di memoria RAM e l'avvio dei background processes.
Il database non è ancora accessibile per gli utenti.
* LIVELLO 2 - MOUNT: raggiungibile dal livello 0 con il comando:

SQL> startup mount

oppure dal livello 1 con il comando

SQL> alter database mount;

In questo livello Oracle legge il contenuto del/i control file, la cui posizione su file system è indicata nel spfile, per determinare la posizione, sempre su file system, dei datafile di cui, tuttavia, non viene eseguita l'apertura.
* LIVELLO 3 - OPEN: lo stato di database aperto può essere raggiunto dal livello 0 direttamente con il comando

SQL> startup

oppure dai livelli 1 e 2 con il comando

SQL> alter database open

Oracle monta in sola lettura, o in lettura/scrittura i datafile, quindi i dati contenuti nel db diventano accessibili per gli utenti.

Come al solito, potete liberamente scaricare l'immagine di inizio post in quanto rilasciata con licenza Creative Commons Attribution-Noncommercial 2.0 Generic ;)

ORA-01940: Cannot drop a user that is currently connected

2009-03-26T13:35:00.017+01:00

E' un pò di tempo che non scrivo sul mio blog, ma, ahimè, in questo periodo il lavoro con Oracle ha latitato e, di conseguenza, anche gli spunti da cui traggo i miei post :(
Questa mattina, tuttavia, una semplice operazione di DROP di un utente del mio db di test ha originato l'errore Oracle ORA-01940: cannot DROP a user that is currently connected
Premessa: lo schema di cui sopra costituisce il backend di un'applicazione web-based realizzata in jsp e gestita da Tomcat. Ovviamente, prima di eseguire, da utente system, la drop dello schema desiderato, mi sono preoccupato di avvertire gli utenti che stavano lavorando nell'ambiente di test di effetturare il logout, quindi, atteso un ragionevole lasso di tempo, ho stoppato il server Tomcat.
Svolgimento: ho pensato che eventuali sessioni appese a livello di db dovessero dipendere dalla presenza di qualche utente ancora connesso e con delle operazioni in corso nell'ambiente di test nel momento in cui ho eseguito lo stop del server Tomcat.

La vista v$session fornisce tutte le informazioni sulle sessioni attive/inattive/killate ed è proprio da questa che bisogna partire per fare un pò di diagnostica.
L'istruzione SELECT seguente interroga proprio tale vista in join con un'altra vista di sistema, ossia v$process in modo tale da ottenere l'id della, il codice seriale e lo status sessione, nonchè il pid del processo ad essa collegato.

SQL> select s.sid, s.serial#, s.status, p.spid
from v$session s, v$process p
where s.username = 'MYUSER'
and p.addr (+) = s.paddr;

Il risultato che si ottiene è qualcosa di simile:

SID SERIAL# STATUS SPID
---------- ---------- -----------------
136 48808 INACTIVE 12065
135 31595 INACTIVE 12030
132 12779 INACTIVE 11092

Ora, le sessioni inattive possono essere terminate con il seguente comando (da ripetere per ogni sessione da terminare, ovviamente e da lanciare in qualità di utente con privilegi da DBA):

SQL> alter system kill session '<#sid,#serial>';

Rieseguendo la query dalla vista v$session si otterrà che le sessioni sono passate allo stato "KILLED", tuttavia, come è successo a me, può capitare che dopo pochi istanti nuove sessioni (o persino le stesse appena killate) tornino nuovamente allo stato "INACTIVE" rendendo nuovamente impossibile eseguire il drop dell'utente.
Personalmente credo che Oracle cerchi di portare a termine i job sottomessi da Tomcat sul db server e incapsulati nelle sessioni di cui sopra, ma avendo ormai perso la connessione con il Tomcat, tali sessioni restano sempre nello stato "INACTIVE".
La soluzione in realtà è semplice, infatti basta mettere in lock l'utente prima di dropparne le sessioni inattive:

SQL> alter user MYUSER account lock;

Quindi si può procedere con il drop dell'utente in tutta tranquillità!

Conclusione: partendo dalle viste di sistema si risolve tutto! ;)

L'immagine di inizio post con i nanetti da giardino l'ho recuperata da qui ed è rilasciata con licenza Creative Commons Attribution-No Derivative Works 2.0 Generic (quindi è possibile copiarla e distribuirla). L'ho messa perchè uno dei nani ha degli occhiali da sole --> servono per vedere --> viste di Oracle --> sclero :-D

Archivelog mode e nu metal

2009-02-13T11:51:00.005+01:00

In quanto appassionato di Oracle e di musica metal (soprattutto nelle sue varianti nu ed heavy), quando ho visto questo video ho pensato di riproporlo!

Il video spiega come mettere un db Oracle 10g in archivelog mode e come sottofondo sonoro propone i mitici System Of A Down.
Per completezza, vi rimando all'ottimo blog dell'autore del video ed alla sua pagina personale su Youtube con altri video interessanti su Oracle.

Buona visione e buon ascolto!

Oracle Streams

2009-02-03T10:05:00.013+01:00

Qualche giorno fa, incuriosito dalla lettura di un post di Chen Shapira, ho iniziato a studiare e a fare qualche prova con Oracle Streams, una tecnologia che permette la propagazione e la gestione di dati, transazioni ed eventi nell'ambito di un database, oppure tra un database sorgente ed uno di destinazione.

In sostanza, Oracle Streams consente di replicare uno schema presente su un db sorgente in un db di destinazione, inoltre, ogni istruzione DDL, oppure DML eseguita nell'ambito dello schema da replicare presente sul db sorgente verrà eseguita anche sullo schema replicato presente nel db di destinazione.
Su databases OLTP, il processo di estrazione dei dati non può essere eseguito direttamente poichè interferirebbe con le normali istruzioni DDL/DML, perciò l'architettura Oracle Streams utilizza gli archivelog, decisamente mento intrusivi.
Prima di poter utilizzare uno stream Oracle, è necessario assicurarsi che siano soddisfatti alcuni prerequisiti:

1) configurare opportunamente i due db server in modo tale che sia possibile eseguire tnsping dal db server sorgente a quello di destinazione e viceversa
2) porre in ARCHIVELOG MODE entrambi i database
3) creare un utente per la gestione dello stream Oracle ad entrambi i database
4) creare un db link per la creazione iniziale, da eseguire solo la prima volta, dello schema replica sul db di destinazione mediante le utilities di data pump
5) creare un db link dal db di destinazione a quello sorgente, utile nel caso in cui la creazione iniziale dello schema replica avvenga a livello di rete senza servirsi di un file dmp intermedio (io ho creato anche questo db link in ogni caso)
6) configurazione delle utilities expdp ed impdp sia sul database sorgente sia su qyello di destinazione
7) creare una directory Oracle e una corrispondente directory sul file system del db server sorgente per ospitare lo script generato dalla procedura DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS che si occupa della replica dello schema via stream Oracle.

Supponendo, per comodità che i punti 1) e 2) siano già soddisfatti, parto direttamente dal punto 3). D'ora in poi, la sigla "PROD" identifica il database sorgente e la sigla "TEST" identifica quello di destinazione. Lo schema da replicare sarà l'onnipresente "SCOTT"!

1) OK
2) OK
3) creiamo un utente dedicato alla gestione dello stream, sia su PROD sia su TEST, connettendoci come utente SYS as SYSDBA:

CREATE TABLESPACE streams_tbs DATAFILE '/u01/app/oracle/oradata/streams_tbs.dbf' SIZE 25M;

CREATE USER strmadmin
IDENTIFIED BY strmadminpw
DEFAULT TABLESPACE streams_tbs
QUOTA UNLIMITED ON streams_tbs;

GRANT DBA TO strmadmin;

BEGIN
DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE(
grantee => 'strmadmin',
grant_privileges => true);
END;

4) impostiamo un db link da PROD a TEST per l'importazione iniziale dello schema da replicare:

-- su PROD
connect strmadmin/strmadminpw@PROD

CREATE DATABASE LINK TEST
CONNECT TO STRMADMIN
IDENTIFIED BY STRMADMINPW
USING 'TEST';

5) ora creiamo anche un db link da TEST a PROD:

-- su TEST
connect strmadmin/strmadminpw@TEST

CREATE DATABASE LINK PROD
CONNECT TO STRMADMIN
IDENTIFIED BY STRMADMINPW
USING 'PROD';

6) configuriamo le utilities di data pump sui due db server mediante la creazione di una directory Oracle chiamata "source" sul db server che ospita PROD e di una directory Oracle chiamata "dest" sul db server che ospita TEST. Le due directories a livello di sistema operativo vanno create con gli appositi comandi del sistema operativo in uso (mkdir, per GNU/Linux):

-- su PROD
conn sys@PROD as sysdba
CREATE OR REPLACE DIRECTORY source AS '/u01/app/oracle/oradata/source';
GRANT READ, WRITE ON DIRECTORY source TO strmadmin;

-- su TEST
conn sys@TEST as sysdba
CREATE OR REPLACE DIRECTORY dest AS '/u01/app/oracle/oradata/dest';
GRANT READ, WRITE ON DIRECTORY dest TO strmadmin;

7) creiamo una directory Oracle e una corrispondente directory sul file system del db server che ospita il database PROD. Questa directory conterrà lo script da eseguire per la replica dello schema SCOTT da PROD a TEST via stream Oracle:

CONNECT strmadmin/strmadminpw@PROD
CREATE OR REPLACE DIRECTORY SCRIPT_DIR AS '/home/oracle/script_dir';

Una volta soddisfatti tutti i requisiti, sul db server che ospita PROD mi sono creato uno script da lanciare come utente strmadmin con il seguente contenuto:

DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names => 'scott',
source_database => 'prod',
destination_database => 'test',
capture_name => 'capture_scott',
capture_queue_table => 'rep_capture_queue_table',
capture_queue_name => 'rep_capture_queue',
capture_queue_user => null,
apply_name => 'apply_scott',
apply_queue_table => 'rep_dest_queue_table',
apply_queue_name => 'rep_dest_queue',
apply_queue_user => null,
propagation_name => 'prop_scott',
log_file => 'exp_scott.log',
bi_directional => false,
include_ddl => true,
instantiation => dbms_streams_adm.instantiation_schema,
perform_actions => false,
script_name => 'schema_replication.sql',
script_directory_object => 'script_dir'
);
END;

Direi che è d'obbligo una spiegazione dei parametri fondamentali impostati, altrimenti non si capisce molto:

* schema_names: il nome dello schema (o degli schemi, separati da virgole) da propagare (in questo caso scott)
* source_database: il database sorgente
* destination_database: il database di destinazione
* capture_name: il nome del processo di cattura configurato per acquisire le modifiche effettuate su PROD
* capture_queue_table: il nome della tabella di accodamento per ogni coda utilizzata da un processo di cattura
* capture_queue_name: il nome di ogni coda utilizzata da un processo di cattura
* capture_queue_user: va impostato a null per indicare che la procedura non può dare il grant di alcun privilegio
* propagation_name: il nome di ciascuna propagazione configurata per propagare le modifiche
* log_file: il nome del file di log generato da expdp
* bi_directional: se impostato a 'false' indica che la propagazione dele informazioni è monodirezionale dal db di produzione a quello di test
* include_dll: impostato a 'true' indica che sia le istruzioni DDL sia quelle DML vanno replicate dal db sorgente a quello di destinazione
* instantiation: se impostato a DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA indica che l'istanziazione dello schema di destinazione verrà effettuata utilizzando le utilities expdp/impdp
* perform_action: se impostato a 'true' consente l'esecuzione dello script PL/SQL, se impostato a 'false' ne memorizza il risultato in un ulteriore script che verrà posizionato nella directory indicata dal parametro 'script_directory_object'
* script_name: impostato con la stringa 'schema_replication.sql'. Questo script verrà creato nella directory Oracle 'script_dir' (/home/oracle/script_dir) e conterrà tutti i passaggi per istanziare lo schema di replica
* script_directory_object: la directory Oracle in cui memorizzare lo script 'schema_replication.sql'

Lanciando lo script non viene avviato lo stream Oracle, quindi nemmeno il processo di replica dell'utente SCOTT sul db TEST, ma viene creato lo script schema_replication.sql nella directory /home/oracle/script_dir che andrà eseguito a parte sempre come utente strmadmin@PROD.
La creazione dello script intermedio consente di verificare se non vi sono stati errori durante l'esecuzione della procedura DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA; in alternativa, è sempre possibile saltare la creazione dello script intermedio e lanciare direttamente la procedura DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA con questi parametri:

DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names => 'scott',
source_database => 'prod',
destination_database => 'test',
capture_name => 'capture_scott',
capture_queue_table => 'rep_capture_queue_table',
capture_queue_name => 'rep_capture_queue',
capture_queue_user => null,
apply_name => 'apply_scott',
apply_queue_table => 'rep_dest_queue_table',
apply_queue_name => 'rep_dest_queue',
apply_queue_user => null,
propagation_name => 'prop_scott',
log_file => 'exp_scott.log',
bi_directional => false,
include_ddl => true,
instantiation => dbms_streams_adm.instantiation_schema,
perform_actions => true
);
END;

Da notare che la direttiva "perform_actions" ora è impostata a true e non sono presenti le direttive "script_name" e "script_directory_object".
Se tutto funziona correttamente, sul db TEST sarà presente una replica esatta dello schema SCOTT del db PROD; ora non resta che testare se una qualsiasi istruzione DDL/DML eseguita sullo schema SCOTT@PROD viene replicata anche su SCOTT@TEST.
Buona replica!!!

Ah, lascio qualche utile link per approfondire l'argomento:
* http://www.dba-oracle.com/t_streams_schema_replication.htm
* http://ca.geocities.com/mosicr@rogers.com/OracleStreams101.htm
* http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_strm_a.htm#ARPLS305

Oracle e SQL Server

2009-01-26T08:11:00.013+01:00

Settimana scorsa mi è stato chiesto se fosse possibile condividere l'anagrafica fornitori contenuta in una tabella su un nostro db Oracle con un software di gestione magazzino che utilizza una base dati su piattaforma SQL Server 2005.
Una breve ricerca su Google mi ha portato ai linked servers, ossia componenti di Microsoft SQL Server (io ho usato la versione 2005 Standard Edition) che consentono a questo RDBMS di poter comunicare con sorgenti dati eterogenee come Oracle, oppure AS400 e persino con fogli di calcolo Excel!
Le componenti di un linked server sono due:

* provider OLE DB (una DLL che gestisce la comunicazione con una sorgente dati)
* sorgente dati OLE DB

Cercando una guida che spiegasse come impostare un linked server da SQL Server ad Oracle mi sono imbattuto in questo post sul blog di Greg Wright, davvero chiaro e ben fatto.
Sostanzialmente, Greg suggerisce in prima istanza di installare il client Oracle (possibilmente in una versione compatibile con quella del db Oracle cui ci si deve collegare) sulla stessa macchina su cui è installato SQL Server, quindi, usando Net Manager, oppure modificando manualmente il file tnsnames.ora, si deve configurare un service name che punti al db Oracle desiderato. Nel post, segue la configurazione del linked server ed, infine, un esempio di query lanciata via SQL Server sul db Oracle a cui ci si deve collegare.
In particolare, volendo eseguire una SELECT sul db Oracle via linked server, la sintassi da utilizzare è:

select * from openquery(linked server, 'select * from dbname.tablename where clause')

La chiave dell'istruzione precedente è la funzione openquery il cui scopo è quello di restituire una tabella con il record set della query (il secondo parametro della funzione) eseguito sul db (Oracle) a cui ci si collega mediante linked server (il primo parametro della funzione).
Volendo è anche possibile eseguire join tra tabelle SQL Server e tabelle Oracle con una sintassi del tipo:

select tabellaSQLServer.campo1, X.campo2, X.campo3
from tabellaSQLServer
join openquery(nomeLinkedServer, 'select * from AltraTabella where Condizione=1') X
on tabellaSQLServer.campoSQLServer = X.campoAltraTabella

Bene, è tutto, ora continuo con i miei test di connessione SQL Server - Oracle!

L'ABC del DBA

2009-01-25T15:30:00.011+01:00

Lavoro con Oracle da un paio d'anni e da circa uno mi sono messo in testa che da grande farò il DBA, ebbene sì! :-D

Come chiunque si avvicina per la prima volta ad un argomento nuovo, ho fin da subito cercato della documentazione che potesse chiarirmi i vari aspetti di Oracle.
Secondo la mia esperienza, le fonti principali da cui trarre informazioni sono:

* colleghi (molto utile poter chiedere direttamente a chi ne sa di più)
* libri (la vecchia carta stampata è sempre un buon punto di partenza)
* Internet
Dopo aver rotto non poco le scatole a qualche volenteroso collega con tutti i miei dubbi (perdonatemi) e vedendo che il ruolo di DBA mi appassionava sempre più, ho iniziato a sfogliare letteralmente centinaia di pagine in formato pdf sui più disparati argomenti che ruotano attorno a questo RDBMS, iscrivermi a forum, mailing list, gruppi su Facebook, ecc. Tutto ciò mi ha permesso, di volta in volta, di risolvere problemi di varia natura, ad esempio legati all'installazione di Oracle Database Server, oppure alla gestione dei backup, o ancora all'esecuzione di queries SQL per la generazione di report e così via, ma ho sempre avuto la sensazione che mi mancasse un percorso più ordinato (dal punto di vista del DBA, come sempre) del tipo:

BASI DI ORACLE --> INSTALLAZIONE DBMS --> CREAZIONE DB --> GESTIONE BACKUP --> PERFORMANCE TUNING

Purtroppo questo mi ha portato a dover riprendere in mano molte volte le stesse cose perchè magari scoprivo di non averle studiate ed approfondite a sufficienza in precedenza, oppure perchè scoprivo un documento che avrei dovuto studiare prima perdendo, di fatto, molto tempo.

Con questo post mi ripropongo di csotruire una sorta di abecedario (vedi immagine all'inizio del post) utile per approciare in modo ordinato ad Oracle ed alla sua documentazione.

1) BASI DI ORACLE: Oracle Database Concepts è il documento ufficiale Oracle che spiega proprio le fondamenta del famoso RDBMS

2) INSTALLAZIONE: in questo caso viene in soccorso un'intera sezione della documentazione Oracle (sempre versione 10.2 del dbms). Non è necessario leggere tutti i documenti proposti (sono veramente tanti), ma è sufficiente scegliere quello adatto in base alla propria piattaforma hw (32/64 bit) e sw (Microsoft Windows, FNU/Linux, Solaris, ecc)

3) CREAZIONE DB: la guida fondamentale a cui fare riferimento (e anche la più tecnica) è quella denominata Administrator's Guide

4) GESTIONE BACKUP: si può trovare la sezione relativa (Backup and Recovery) nella homepage della documentazione relativa ad Oracle Database Server 10.2 tramite il tab "Administration"

5) PERFORMANCE TUNING: argomento trattato dalla "Performance Tuning Guide" su come configurare e monitorare le prestazioni di Oracle Database Server

I punti sopra indicati costituiscono, a mio avviso, il patrimonio di conoscenze che dovrebbe essere proprio della figura del DBA e da cui partire prima di interessarsi di altri aspetti di questo potente e complesso RDBMS.
Buona lettura!

Oracle Critical Patch Update Gennaio 2009

2009-01-15T15:59:00.025+01:00

Martedì 13 Gennaio è stata una giornata piuttosto piena in termini di patch con il rilascio in contemporanea del bollettino di sicurezza MS09-001 di Microsoft, relativo al protocollo SMB di Windows e il Critical Patch Update rilasciato da Oracle per questo primo trimestre del 2009.

Approfitto di questo doppio rilascio per creare un mio personale parallelismo tra l'attività dell'amministratore di sistema e quella dell'amministratore di database relativamente all'installazione delle patches (non ho certificazioni per nessuno dei due ruoli, ma di fatto è ciò di cui mi occupo per lavoro):

1) entrambi devono potersi documentare su eventuali patch updates anche prima che essi vengano rilasciati, allo scopo di raccogliere informazioni sulle vulnerabilità coperte dalle patches, predisporre un sistema di test su cui provarne l'installazione prima di passare in produzione, schedulare l'operazione di update ed avvertire, di conseguenza, gli utenti di un eventuale downtime dei servizi offerti dai server interessati dall'aggiornamento.
In questo senso, un buon punto di partenza lo fornisce la rete. L'amministratore di sistemi Microsoft Windows non attenderà la notifica automatica di Windows Update, ma si avvarrà di siti come il blog di Feliciano Intini, ad esempio; allo stesso modo, il dba Oracle può fare riferimento ad OTN (Oracle Technology Network).
Insomma, l'imperativo è ESSERE SEMPRE INFORMATI!

2) all'uscita di una nuova patch, sia il sysadmin sia il dba devono valutare l'impatto che l'applicazione della patch stessa avrà sui propri server possibilmente testandola, se il tempo lo consente, su una "sandbox", ossia un ambiente di prova.
La fase di testing è fondamentale per assicurarsi che l'update vada a buon fine e che non crei problemi, una volta installato, con la configurazione del server/dbms

3) dopo una necessaria e fondamentale fase di testing, l'applicazione della patch va effettuata anche nell'ambiente di produzione (operazione che dovrebbe avvenire quando gli utenti non sono connessi e che non dovrebbe causare problemi, se è stato effettuato un testing sufficiente, come indicato al punto 2)

Lo scopo di questo post, innanzitutto, è quello di acquisire le competenze necessarie per eseguire l'installazione del CPU di Gennaio 2009 (punto 1), mentre la fase di installazione del patch update in un ambiente di test (punto 2) sarà l'argomento di un post che pubblicherò a breve!

Ok innanzitutto bisogna documentarsi perciò mi dirigo sulla sezione di OTN dedicata ai Critical Patch Update; il mio obiettivo è dare una risposta ad alcune domande:

* quali vulnerabilità vengono risolte dal CPU di Gennaio 2009?
* a quali prodotti (e relative versioni) Oracle si può applicare?
* conviene installarlo o ci sono controindicazioni?
* come si installa?

Il link relativo ai CPU su OTN contiene molte utili informazioni, ad esempio si apprende che i patch update vengono rilasciati su base trimestrale, infatti le prossime date di rilascio saranno:

* 14 Aprile 2009
* 14 Luglio 2009
* 13 Ottobre 2009
* 12 Gennaio 2010

Oltre a questo, OTN fornisce due utili link a risorse che indicano rispettivamente come abilitare la notifica via mail dei CPU non appena questi vengono rilasciati e un documento in formato pdf con le "Best Practices" per installare i patch updates.
In particolare, la pagina su OTN dedicata al CPU di Gennaio 2009 contiene un elenco, che riporto per comodità anche nell'immagine sottostante, con tutti i software e relative versioni di Oracle interessati all'applicazione della patch:

Supponendo, come nel mio caso, di voler applicare la patch alla componente Database Server 10g di Oracle, dalla tabella precedente si nota, ad esempio, come la versione 10.2.0.1 del DBMS non sia supportata (qualche informazione in più la si può leggere anche da questo thread sul forum di OTN), così come versioni di Oracle Database Server antecedenti alla 9.2.0.8, ecc.
Continuando nella lettura della stessa pagina su OTN, si scopre anche che i patch updates sono cumulativi per molti prodotti Oracle (non tutti però), ossia ogni CPU include tutti i fixes del CPU precedente. Fortunatamente questo caso si applica ad Oracle Database Server quindi basterà installare il patch update di Gennaio 2009 per avere anche i fixes dei patch updates precedenti!
Ancora la stessa pagina di OTN contiene una tabella, riportata anche qui di seguito, con la lista dei prodotti interessati dal CPU di Gennaio 2009, i link alle matrici dei rischi (tabelle che riportano l'elenco delle vulnerabilità con relativa descrizione per ciascuna famiglia di prodotti per cui Oracle raccomanda di installare la patch), links a Metalink, ecc.

L'immagine seguente, infine, riporta la tabella prelevata dalla nota Metalink 753340.1 relativa al CPU di Gennaio 2009 in cui viene fornito il riassunto delle note, sempre su Metalink, per accedere alla documentazione e al download del CPU JAN 2009 per varie piattaforme e versioni di Oracle Database Server:

Per questa volta è tutto, di materiale da digerire ce n'è in abbondanza. Nel prossimo post tratterò l'installazione del CPU JAN 2009 sul mio sistema di test, ossia una macchina virtuale Debian GNU/Linux con installato Oracle Database alla versione 10.2.0.4, il tutto su VMware ESXi!

Estendere le funzionalità offerte da Blogger

2009-01-14T16:24:00.012+01:00

Ieri mi sono ritrovato con un pò di tempo libero quindi ne ho approfittato per studiare le potenzialità di Blogger, la piattaforma messa a disposizione da Google per creare in modo semplice e veloce un blog, proprio come questo.
Blogger consente, una volta messo in piedi lo scheletro del proprio blog (interfaccia grafica mediante css già pronti all'uso, gadget da inserire nel pannello laterale per arricchire le proprie pagine, ecc), di estenderne ulteriormente le funzionalità mediante l'inclusione di widget creati da terzi, purchè compatibili con la piattaforma stessa. Decisamente interessante per non fare qualche prova!

Per prima cosa ho cercato in rete qualche risorsa che trattasse bene l'argomento e sono capitato su Creareblog. Gli howto presentati da Tenebrae, l'autore del blog, sono veramente tanti e ben fatti e vi consiglio di leggerli se siete interessati all'argomento!

Le modifiche apportate al mio blog sono sia estetiche sia funzionali:

- rimossa la barra superiore aggiunta di default ai blog della piattaforma blogspot (non si incorre in nessuna bega legale facendo ciò, quindi perchè no?)

- Blogger non consente, di default, di pubblicare solo un'introduzione nella homepage per gli articoli troppo lunghi e di pubblicare i post per intero in pagine a parte (raggiungibili dall'utente cliccando su un link del tipo "Leggi tutto"). Ora invece si può! :-D Molto comodo!

- Per differenziare le righe di codice dal resto del testo, durante la composizione dei post utilizzavo i tag pre e tt. Ho quindi modificato il css aggiungendo le righe seguenti:

/* Stile del codice */
.code {
font-family:courier new;
font-size:85%;
}

blockquote.code {
background: Gainsboro;
border: 1px solid LightSlateGray;
padding: 5px 5px;
white-space: pre;
}

Il risultato lo potete vedere qui sopra.

- Ho aggiunto una nuvola di tag al pannello laterale. Sicuramente meno comoda della classica lista di tag bene ordinati, probabilmente fa anche venire il mal di mare, ma a me me piace ;-)

- Ho inserito anche un motore di ricerca che sfrutta quello di Google come base, per gli articoli presenti nel blog (anche questa componente è accessibile dalla barra laterale). Si è trattato di un'aggiunta praticamente obbligata, in quanto rimuovendo la barra superiore di Blogger (vedi punto 1), mi sono ritrovato senza un motore con cui ricercare post nel mio blog.

Nonostante l'obiettivo di questo blog sia più quello di una sorta di block notes in cui appunto esperienze quotidiane, prove, errori combinati da me e altro, purchè ruoti attorno al mondo di Oracle, il solo fatto che qualcuno possa leggere quello che scrivo è per me fonte di soddisfazione. Siccome qualche lettore in più non mi dà certamente fastidio, anzi, commenti ed eventuali proposte di collaborazione sono sempre ben accetti, ho pensato di mettere in pratica gli utili consigli di Creareblog per il posizionamento del mio blog nei principali motori di ricerca, partendo dallo stesso Google, che è quello più utilizzato a livello planetario e passando poi per Live Search di Microsoft e Yahoo.

Oltre all'indicizzazione del mio blog sui principali motori di ricerca, ho seguito anche l'articolo di Creablog relativo alla pubblicazione della sitemap di un sito su Google, Live Search, o Yahoo.
Cos'è una sitemap? Cito testualmente dal post di cui sopra:

[cut]
La Sitemap è un documento che contiene informazioni sui post e sulla struttura gerarchica di un blog. E' molto simile al feed e nel caso del feed in formato ATOM coincidono. La Sitemap del proprio blog può essere inviata ad un motore di ricerca affinchè ne vengano correttamente indicizzate tutte le pagine.

Google Webmaster Tools è il più conosciuto strumento per la segnalazione della propria sitemap e in generale per avere informazioni e statistiche sul proprio sito dal punto di vista del motore di ricerca. Contrariamente a quanto si pensi, segnalare la propria sitemap a Google non comporta un posizionamento migliore nei risultati delle ricerche, al massimo permette di far risultare il nostro blog in un contesto più coerente ai temi che contiene. Segnalare il nostro sito inoltre non accelera il processo di indicizzazione delle pagine. Questo è quanto è esplicitamente dichiarato da Google e che si riscontra effettivamente sul campo.
[/cut]

Google Webmaster Tools permette di avere importanti statistiche per il proprio sito/blog fornite direttamente da Google.

Script di creazione degli utenti

2009-01-13T10:50:00.015+01:00

Problema: dato un utente residente sul db di produzione, creare un utente identico in tutto e per tutto al primo, ma sull'ambiente di test.

Soluzione: avviare EM (Enterprise Manager) con il comando emctl da lanciare da un prompt di DOS, oppure da una shell GNU/Linux (come nell'esempio seguente), previa impostazione del SID dell'istanza desiderata, perciò, da GNU/Linux:

$ export ORACLE_SID=SID
emctl start dbconsole

Enterprise Manager per Oracle 10.2.0.4 è accessibile via https all'url che viene riportato dal comando emctl stesso:

oracle@debiandb:~$ emctl start dbconsole
TZ set to Europe/Vatican
Oracle Enterprise Manager 10g Database Control Release 10.2.0.4.0
Copyright (c) 1996, 2007 Oracle Corporation. All rights reserved.
https://debiandb:5500/em/console/aboutApplication
Starting Oracle Enterprise Manager 10g Database Control ................. started.
------------------------------------------------------------------
Logs are generated in directory
/u01/app/oracle/product/10.2.0/db_1/debiandb_TEST/sysman/log

Una volta effettuato l'accesso come utente System, dalla pagina principale di EM, scegliendo il tab "Amministrazione", tra le molte voci presenti bisogna cliccare su "Utenti"; così facendo, si accede ad una pagina con la lista degli utenti del db di produzione.
Come si può notare dall'immagine sottostante, bisogna prima di tutto (punto 1) mettere il check sull'utente da copiare (nell'esempio, ho scelto l'utente ADMIN), quindi selezionare la voce "Genera DDL" dal menu a tendina (punto 2) ed infine, cliccare sul pulsante "Vai".

Ciò che si ottiene è un listato simile al seguente:

CREATE USER "ADMIN" PROFILE "DEFAULT" IDENTIFIED BY "*******"
DEFAULT TABLESPACE "TS_CNEXT" TEMPORARY TABLESPACE "TEMP"
QUOTA UNLIMITED ON "TS_CNEXT" ACCOUNT UNLOCK;
GRANT ALTER ANY INDEX TO "ADMIN";
GRANT ALTER ANY PROCEDURE TO "ADMIN";
GRANT ALTER ANY SEQUENCE TO "ADMIN";
GRANT ALTER ANY TABLE TO "ADMIN";
GRANT ALTER ANY TRIGGER TO "ADMIN";
GRANT CREATE ANY INDEX TO "ADMIN";
GRANT CREATE ANY PROCEDURE TO "ADMIN";
GRANT CREATE ANY SEQUENCE TO "ADMIN";
GRANT CREATE ANY TABLE TO "ADMIN";
GRANT CREATE ANY TRIGGER TO "ADMIN";
GRANT CREATE ANY VIEW TO "ADMIN";
GRANT CREATE PROCEDURE TO "ADMIN";
GRANT CREATE SEQUENCE TO "ADMIN";
GRANT CREATE TABLE TO "ADMIN";
GRANT CREATE TRIGGER TO "ADMIN";
GRANT CREATE VIEW TO "ADMIN";
GRANT EXECUTE ANY PROCEDURE TO "ADMIN";
GRANT INSERT ANY TABLE TO "ADMIN";
GRANT SELECT ANY SEQUENCE TO "ADMIN";
GRANT SELECT ANY TABLE TO "ADMIN";
GRANT UNDER ANY TABLE TO "ADMIN";
GRANT UNDER ANY VIEW TO "ADMIN";
GRANT "CONNECT" TO "ADMIN";

E' possibile copiare questo codice e salvarlo in un file di testo chiamato, ad esempio, "crea_admin_da_produzione.sql" (ricordate di impostare la password per l'utente sostituendola agli asterischi messi da EM).
Supponendo che i nomi delle tablespaces tra ambiente di produzione ed ambiente di test coincidano (altrimenti basta modificare lo script SQL di cui sopra), non ci sono altre modifiche da apportare al file!

Sul db di test si può quindi procedere alla creazione dell'utente, copia speculare dell'omonimo presente sul db di produzione, accedendo con un utente con il privilegio sysdba:

SQL> @crea_admin_da_produzione.sql

Et voilà, con un solo comando l'utente è stato creato, con tutti i privilegi replicati dalla produzione! In questo modo si dispone di uno schema vuoto in cui effettuare l'importazione del dump dell'utente di partenza esportato sempre dal db di produzione (cfr Oracle e i backup - Parte I).

Oracle (10g) e i backup - parte II

2009-01-06T15:49:00.014+01:00

Finalmente dopo un (bel) pò di tempo ho ritrovato la voglia di tornare a scrivere in questo blog e di riprendere in mano l'argomento dei vari strumenti di backup messi a disposizione da Oracle.
Il primo post verteva sull'uso dei comandi exp ed imp per l'esportazione ed importazione, a caldo, ossia eseguibile anche a database attivo, di uno schema Oracle sfruttando un file binario intermedio (il cosiddetto dump).

Questo secondo post, invece, è relativo ad RMAN (Recovery MANager), un utile strumento messo a disposizione da Oracle per il restore ed il recovery di un database (compresi anche i file fisici presenti su disco fisso, come control files, datafiles, spfile, redo logs, archivelogs, necessari al suo funzionamento).
Come al solito, vorrei focalizzare l'attenzione sull'uso che faccio di RMAN al lavoro, sia per gli ambienti di test, sia per quelli in produzione, senza per questo replicare la già abbondante documentazione esistente sull'uso di questo comando. Se siete interessati ad approfondire l'argomento, come di consueto in coda a questo post ho aggiunto alcuni link (e non dimenticate il buon Google).

Il modo più semplice per invocare RMAN è tramite l'utilizzo della command line, dopo aver specificato il SID dell'istanza Oracle di cui gestire il backup/restore/recovery (per sistemi Microsoft Windows utilizzare il comando set al posto di export):

$ export ORACLE_SID=
$ rman TARGET /

Una volta ottenuto il prompt di RMAN, se ne possono impostare i parametri di funzionamento, eseguire backup, restore (il ripristino di componenti di un db Oracle come datafile, control files, redo logs, ecc. corrotte, ad esempio in seguito alla rottura del disco fisso su cui erano memorizzate), oppure il recovery (effettuato dopo il restore, permette di riportare i dati contenuti in un database nello stato in cui si trovavano prima che si verificasse il guasto, come la rottura di un disco fisso del db server, oppure la corruzione di un file importante per il db, o ancora l'interruzione della corrente elettrica).
In alternativa, è possibile creare un file dei parametri da passare ad RMAN ogniqualvolta esso viene eseguito. Questa soluzione si rivela molto utile quando si vuole schedulare periodicamente l'esecuzione di RMAN mediante strumenti come cron per GNU/Linux, oppure Operazioni Pianificate di Microsoft Windows.

RMAN permette di creare diverse tipologie di backup (full, incrementale), di varie componenti di un db Oracle (datafiles, control file, spfile, redo logs, archivelogs, altri backup di RMAN), in diversi formati (backup pieces, image copies) e su differenti tipologie di supporto (disco fisso, nastro).
RMAN può essere configurato secondo le proprie necessità semplicemente impostando alcuni tra i numerosi parametri messi a disposizione da questo potente strumento. Prima di passare al codice degli script che utilizzo quotidianamente al lavoro vorrei delineare la politica di backup da me adottata:

* 1 backup incrementale di livello 0 una volta al giorno alle ore 20:00
* 1 backup incrementale di livello 1 alle ore 8:00, 13:00 e 18:00

Il backup incrementale delle ore 20:00 effettua il backup di tutti i blocchi dati contenuti in un datafile perciò le dimensioni del backup piece, o dell'image copy risultante, a seconda del sistema utilizzato, potranno essere anche notevoli. I backup incrementali di livello 1, invece, vengono definiti differenziali (ed è il caso di quelli che creo io con RMAN) quando vengono memorizzati i blocchi di dati a partire dal più recente backup di livello 0 o di livello 1, oppure cumulativi se vengono memorizzati i blocchi modificati a partire dal più recente backup incrementale di livello 0, come evidenziato nell'immagine sottostante.

Perchè utilizzo questa strategia? Fondamentalmente perchè le dimensioni dei backup set creati quotidianamente da RMAN per il mio database di produzione sono nell'ordine del GB, una quantità di spazio relativamente irrisoria da memorizzare su una NAS, una SAN, oppure da spostare su un file server remoto via rete (tra l'altro, i backup pieces prodotti da RMAN sono normali files che è possibile comprimere prima di un'eventuale copia in rete via ftp, rsync, scp, o altro. In questo modo diminuisce il tempo di trasferimento dei files e la loro dimensione, ma aumenta il tempo di un eventuale restore/recovery da quei files che andranno prima riportati sul db server e scompattati per poterli effettivamente utilizzare).

Quello che segue è il file dei parametri che utilizzo per RMAN:

# -------------------------------------------------
# Script per eseguire un backup incrementale a caldo
# di livello 0
#

# --------------------
# Default e Politiche
# --------------------
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
CONFIGURE MAXSETSIZE TO UNLIMITED;

# --------------------------------
# Backup di control file + sp file
# --------------------------------
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
TO '/backup//CF_%F';

# -----------------------------------------------------
# Creazione del redundancy set costituito da:
# - backup dei datafiles
# - backup degli archive redo logs
# - backup del control file

BACKUP
DEVICE TYPE DISK
AS COMPRESSED BACKUPSET
INCREMENTAL LEVEL 0
DATABASE
FORMAT '/backup//DATAFILE_%d_%T_%t_%s_%p'
TAG 'INCREMENTAL LEV 0'
PLUS ARCHIVELOG
FORMAT '/backup//ARCH_%d_%T_%t_%s_%p'
SKIP INACCESSIBLE;

BACKUP CURRENT CONTROLFILE FORMAT
'/backup//SOLO_CF_%d_%T_%t_%s_%p'
tag='CF a parte';
# -----------------------------------------------------

# -----------------------------------------------------
# elimino i files obsoleti (compresi gli archivelogs)

DELETE force noprompt obsolete;
# -----------------------------------------------------

Ho lasciato i commenti al codice per tenermi in mente cosa combina! Come si può notare, per prima cosa vengono impostati alcuni parametri per RMAN, come la recovery window, ossia per quanto tempo mantenere un backup piece nello stato 'AVAILABLE' prima di considerarlo obsoleto (che non significa necessariamente inutile per un eventuale restore/recovery), ma anche il tipo di device su cui eseguire i backup (in questo caso su disco) e così via.

Importante è la parte relativa all'impostazione dell'autobackup che permette di creare in automatico un backup di control file + spfile da inserire in un backup piece separato rispetto a quelli dei datafiles e degli archivelogs.

Con l'istruzione BACKUP ... DATABASE PLUS ARCHIVELOG ... si avvia il backup, appunto, incrementale di livello 0 (o di livello 1 a seconda del valore impostato) dei datafiles e degli archivelogs (grazie all'istruzione 'CONFIGURE BACKUP OPTIMIZATION ON' vengono tralasciati gli archivelogs già backuppati una volta su disco riducendo, di fatto, la dimensione dei backup pieces risultanti).
Inoltre, viene creato un ulteriore backup a sè stante per il control file. Backuppo quotidianamente il control file non solo perchè si tratta di un elemento fondamentale per un database Oracle (altrimenti non se ne può nemmeno effettuare lo startup), ma soprattutto perchè RMAN memorizza al suo interno record relativi ai backup files necessari per un eventuale restore/recovery (a meno di non utilizzare un recovery catalog esterno).
L'ultima istruzione, 'DELETE force noprompt obsolete' permette di fare un pò di pulizia rimuovendo i backup considerati obsoleti, ossia che non rientrano nella recovery window impostata precedentemente (pari a 4 giorni).

Per chi volesse approfondire l'argomento backup con RMAN lascio qualche utile link:
Oracle® Database Backup and Recovery Quick Start Guide
Oracle® Database Backup and Recovery Basics
Oracle® Database Backup and Recovery Reference
Oracle® Database Backup and Recovery Advanced User's Guide

Oracle e i backup - parte I - UPDATE

2008-11-19T13:00:00.009+01:00

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

2008-11-18T10:37:00.005+01:00

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

2008-11-17T09:56:00.017+01:00

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

2008-10-03T16:45:00.014+02:00

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

2008-09-29T11:40:00.007+02:00

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

2008-09-28T11:33:00.005+02:00

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'

2008-09-26T23:12:00.005+02:00

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

2008-09-26T10:46:00.004+02:00

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

2008-09-25T15:21:00.010+02:00

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

2008-09-25T15:03:00.000+02:00

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