25 ottobre 2007

DBCA non sente ASM

Ho installato (per lavoro) un nuovo RAC a due nodi, con una nuova politica di storage da provare.
Proprio durante la creazione del DB mi sono imbattuto in una specie di bug di dbca che avevo già trovato a casa, ma a cui non avevo dato peso, visto che non capita tutte le volte che si crea un database, e a me è capitato una sola volta.
Utilizzando il Database Configuration Assistant, nella pagina della scelta dello storage il programma non riconosce l'istanza ASM attiva sul cluster (ma càpita anche su single-instance), e chiede di riconfigurarla:
DBCA could not startup the ASM instance configured on this node. To proceed with the database creation using ASM, ASM instance needs to be up and running. Do you want to recreate ASM instance on this node?

È strano che non si trovi praticamente nulla su internet né su Metalink. Qualcosa ho trovato in un blog di un collega (click sul titolo del post), che però lascia senza una soluzione concreta.
Ebbene, la soluzione esiste.
Si trova sul manuale del corso Oracle RAC 10gR2, ma non riguarda questo errore, solo un invisibile prerequisito per eseguire dbca, che passerebbe inosservato a chiunque. Avevo scritto qualche nota a margine nel manuale sulla pagina in questione, ora capisco perché.

Soluzione: Si tratta di impostare le variabili d'ambiente Oracle da zero, partendo da un ambiente senza variabili Oracle definite, esclusivamente in questo modo (esempio):

export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=<SID del database da creare (NON di ASM)>
export ORACLE_HOME=/u01/app/oracle/product/10.2.0
export PATH=$PATH:$ORACLE_HOME/bin:$CRS_HOME/bin


Non serve null'altro! In questo modo funziona anche l'installazione con un'ORACLE_HOME separata per ASM.

Mi raccomando, se questo post vi è stato utile... almeno un piccolo commento!

(17-11) Aggiornamento: la procedura descritta non ha funzionato in occasione dell'aggiunta di un database RAC a un cluster esistente, su un nodo diverso dal primo. Nonostante le varie prove fatte, non sono riuscito a fare riconoscere l'istanza ASM a DBCA, anche se esistente e regolarmente funzionante.
Alla fine ho dovuto optare per la creazione del database mediante script, procedura per nulla automatica nel caso di RAC. Ma per questo ci sarà una blog-entry in seguito.

24 ottobre 2007

Nuovo RAC a 64 bit (2)

L'installazione di 10.2.0.1.0 è andata bene e il RAC era a posto.
I problemi sono arrivati dall'aggiornamento a 10.2.0.3.0. Subito si è ripresentato l'errore di scrittura su disco di VMware, quando il server virtuale tenta di allocare lo spazio sul disco reale in seguito alla crescita dell'occupazione del filesystem virtuale.
Quindi, regola generale:
Allocate SEMPRE PRIMA tutto lo spazio su disco necessario per tutto lo storage virtuale che intendete usare.
Fortunatamente questa regola è di facile applicazione con i dischi moderni da desktop, praticamente della dimensione minima di 500 GB, a poco più di 100 euro sul mercato.
Nel mio caso i problemi si avevano quando trasferivo gli zip di aggiornamento su un nodo e poi scompattavo gli archivi.

Per prima cosa ho aggiornato Clusterware. L'operazione è possibile in rolling-upgrade, ovvero spegnendo Clusterware solo su un sottoinsieme di nodi che si vogliono aggiornare in contemporanea; normalmente può essere gradito aggiornare un nodo del cluster alla volta; altrimenti si spegne tutto e buonanotte. Una particolarità è che, aggiornando solo il primo nodo, con i comandi crsctl per mostrare la versione, si può evidenziare come la versione che è installata è quella aggiornata (dopo l'upgrade), mentre la versione in esecuzione è quella vecchia, per via dei rimanenti nodi del cluster non ancora aggiornati.

In seguito ho aggiornato il database; quasi tutto regolare, a parte piccoli errori strani che non sono sicuro siano ricondicibili al database.

22 ottobre 2007

Nuovo RAC a 64 bit

Tramonta l'idea di mettere su un RAC con Solaris/64 su macchine virtuali. L'avventura con Solaris sembrava partita bene, invece al momento di aggiungere una scheda di rete in più e qualche hd virtuale in più, le macchine virtuali andavano in kernel panic (con dump relativo). Peccato, quando funzionavano erano molto veloci.

Bene, domenica ho resistito forzatamente alla voglia di uscire nonostante il freddo, e ho provato qualche novità per il mio megaserver a casa, in particolare con l'accoppiata 10gR2/64 - OpenSuSE/64 che è appena uscita in versione 10.3.
Ho aggiornato anche il kernel del mio megaserver, aggiungendo ai repository della SuSE anche quelli nVidia, così ad ogni aggiornamento del kernel i driver nVidia andranno a posto automaticamente :-)
VMware, con la nuova versione 1.0.4, sembra avere meno problemi. A proposito, consiglio di preallocare sempre i dischi virtuali di VMware, perché le operazioni di I/O pesante con estensione dei volumi non sono molto affidabili, a volte si bloccano (almeno sul mio megaserver).

OpenSuSE 10.3 sembra fatta apposta per fare andare Oracle. Stavolta (10.3) il tema è verdino. L'installatore presenta persino la possibilità di fare bonding delle schede di rete.
Prima avvertenza: controllate scrupolosamente tutti i prerequisiti software di Oracle! Ho perso lunghe ore a cercare di capire perché l'installazione non andava a buon fine anche se avevo risolto in modo corretto tutti i problemi di librerie. L'importante è avere i pacchetti richiesti prima di fare partire l'installer.

Stavolta ho usato ASM come storage condiviso: solite due schede di rete, 2 dischi per OCR e voting, e un disco per ASM.
Due trucchi molto interessanti:
  1. Se l'installer non parte con un errore Xlib.lock di Java, è colpa di SuSE che ha lasciato qualche errorino in giro; meno male che basta una variabile d'ambiente

  2. Per fare funzionare vipca e srvctl è necessario aggiungere la riga
    unset LD_ASSUME_KERNEL
    nei rispettivi script di avvio (loro stessi) con un editor di testo, appena dopo che la variabile viene impostata.

  3. Durante la partenza di vipca, alla fine della creazione del cluster, se non ci sono interfacce di rete "vip" già configurate, l'installer esce con un errore di "lista di interfacce". Un eccellente workaround è configurare a mano almeno un'interfaccia con oifcfg (leggere le istruzioni con l'help o il manuale). Dopo vipca parte senza problemi.

Ora è necessario un upgrade a 10.2.0.3.0. Sarà il mio primo upgrade di un cluster. O al massimo il secondo. A presto con le novità.

21 ottobre 2007

Oracle 11g/x86_64

È arrivata da un paio di giorni la nuova versione di 11g per x86_64.
Ovviamente non ho resistito e l'ho installata subito su OpenSuSE 10.2/64. Nessun problema, funziona alla grande.

Ho già preparato un lungo post sulle novità in fase di sperimentazione, anche se purtroppo non includono più Solaris. A presto anche per un'analisi più approfondita su 11g.

16 ottobre 2007

Se manca TEMP

Dopo un restore completo del database o una creazione di uno standby fisico mancano sempre i datafile dei tablespace temporanei.
Ammettiamo di avere un solo TEMP con un datafile, su uno standby. All'apertura del db l'alert_log darà un errore perché Oracle non trova il datafile temporaneo. È sufficiente crearlo, a database aperto (in read only nel caso dello standby):

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '<file name>' SIZE <n>M[G, ...];

Controllate poi che tutto sia a posto in V$TEMPFILE.

13 ottobre 2007

Da 64 a 32 bit (e viceversa)

Nei giorni scorsi ho dovuto affrontare un'emergenza: una macchina di produzione Itanium (IA64) ha smesso di funzionare per ragioni relative allo storage esterno. Rimaneva lo standby fisico a 32 bit, che comunque doveva andare presto in produzione al posto dell'IA64.

Pazienza, dopo avere applicato gli ultimi log all'istanza standby, ho cominciato la procedura di failover.
Subito ho avuto un piccolo problema per via della R1 del database 10g, che aveva una sintassi leggermente diversa per il failover manuale (grrr!), ma alla fine il role transition è andato bene.
Ma non tutto è andato per il verso giusto. Infatti, entrando come utente qualsiasi nel database, spuntava fuori l'errore:

ORA-06553: PLS-801: internal error [56319]
Error accessing package DBMS_APPLICATION_INFO


Suonava come un problema di dizionario dati. E infatti, a quanto si intuiva dalla documentazione, bisogna fare uso di ?/rdbms/admin/utlirp.sql, seguito da utlrp.sql, come si può leggere nelle istruzioni nell'header del file stesso (da seguire assolutamente).
Il dizionario è andato a posto e il db ha ricominciato a funzionare correttamente.

11 ottobre 2007

Copiare datafilecopy

No, non sto parlando di spostare un datafile da un posto a un altro (procedura con il tablespace offline), ma di copiare ad esempio le copie dei datafile effettuate con RMAN in un luogo remoto.
Il mio consiglio, che può essere comunque utile per spostare file di grandi dimensioni oppure tanti file, è quello di usare il comando tar in combinazione con ssh.

Ad esempio:
# tar czf - -T <file lista> | ssh <user>@<host> 'tar xzf - -C <dest dir>'

dove <file lista> (opzionale) è un file contenente la lista dei file che volete copiare, e <dest dir> è directory in cui viene eseguita l'estrazione del tar all'arrivo.
In pratica viene creato uno stream di dati in standard output, che viene preso in standard input da ssh, trasferito sul canale sicuro, e preso in standard input da tar sulla macchina destinazione, per essere poi estratto.

I vantaggi di questa soluzione sono molteplici:
  1. Non viene usato il filesystem, quindi non ci sono limiti fisici alle dimensioni dei file trasferiti

  2. Lo stream è compresso alla sorgente con gzip, quindi il trasferimento è "da più veloce a molto più veloce"

  3. Si possono usare tutte le possibilità offerte dal tar

  4. Lo stream di dati è criptato

  5. C'è un implicito controllo di integrità nel trasporto data dall'uso di gzip


C'è ancora un vantaggio relativo: se i datafile non sono pieni al 100%, gzip sarà incredibilmente efficiente nel trasporto dei dati: si riescono ad ottenere transfer rate da GB al secondo!

08 ottobre 2007

Lavori in corso

Ci sono ancora: ho poco tempo ma sto cercando di installare 11g su Enterprise Linux e un cluster 10g ad uso test sotto Solaris 10 x86_64. Tutto ciò in tre macchine virtuali che girano sul mio potente server dai led blu :-)
Intanto i problemi di scrittura su disco si stanno risolvendo con l'aggiornamento firmware della scheda madre, del kernel Linux/64 e di VMware, arrivato alla versione 1.0.4.
Ci vuole tempo!