26 dicembre 2007

Una buona azione a Natale

A Natale per me è arrivato il riposo tanto atteso e un pranzo un po' più abbondante del solito. Ma a rimanere tutto il giorno senza fare proprio nulla non ci riesco.

È ormai tradizione dedicare una parte della giornata ad un'installazione Oracle.
D'accordo, non sarà un'azione nobile come aiutare il prossimo, ma è una scusa per fare passare il tempo e un'occasione per imparare qualcosa di nuovo.

Per questo Natale ho aggiornato l'istanza Oracle sul mio Mac Mini. Come dovreste sapere, Oracle 10g si è fermato alla versione 10gR1 su Mac OS X. La versione originale è la 10.1.0.3.0, io l'ho aggiornata all'ultima disponibile, la 10.1.0.5.0; a quanto pare non ci saranno altri aggiornamenti.

DBUA non esiste, quindi bisogna aggiornare a mano il catalogo con catpatch.sql in "startup upgrade", e poi ricompilare gli oggetti invalidati dall'operazione di upgrade.

Tutto qui. Proseguiremo presto con altri post interessanti (a differenza di questo!).
Mi raccomando, sotto con i commenti, non fatevi pregare! :-)
E Buone Feste a tutti!

18 dicembre 2007

ASM su USB

Preso dagli acquisti natalizi (seee) ho ceduto all'offerta delle chiavette USB da parte di Carrefour a 8.90 € per 1 GB. Ne ho comprate 3, per provare almeno la redundancy HIGH oppure un disco spare. Non ho acquistato altro, tranne un paio di cuffie con microfono per Skype.

Ho inserito le tre chiavette in altrettante prese USB di quelle saldate sulla scheda madre, per ottenere un'alimentazione corretta.
Ho creato un volume ASM "DONKEYS" (da "dongle-keys") con ridondanza HIGH.
Come prima prova ho messo sul volume tre copie degli online-log dell'istanza 11g di prova.
Non è stato esaltante: 2 minuti e mezzo per creare ognuno dei logfile da 50 MB.

Ipotesi:
  1. Il protocollo di scambio dati tra scheda madre e USB è assai inefficiente

  2. La HIGH redundancy è un carico troppo elevato per le chiavette

  3. Tre chiavette assorbono troppa corrente dal bus USB


Ho creato i nuovi logfile su Oracle 11g, di cui sto lentamente provando il nuovo Enterprise Manager, in vista di una recensione.

09 dicembre 2007

oROCKole

"Ask Tom Live" European Tour 2008.

OK, pagherei per andare a sentire Tom Kyte, ma qui esagerano un po', e non è certo la prima volta. Evidentemente hanno piuttosto successo con queste iniziative.

Ma anche con altre: chi può resistere al fascino di tre gadget di questa levatura al solo costo di un corso?

Keep rockin'.

02 dicembre 2007

Orion e il mio PC

Orion è un tool per la valutazione della risposta dell'I/O di un server nell'ottica di utilizzo come database server, senza però dovere installare il motore del database e senza dovere predisporre i dati e le applicazioni di test.
Orion riesce a simulare l'I/O di Oracle perché utilizza le stesse librerie; può simulare sia un carico di lavoro a piccoli blocchi (8 KB), che a blocchi larghi (1 MB) sia sequenziali che casuali, o combinazioni dei due.
Il risultato dei test sono tre misure:
  1. Il throughput in MB/s

  2. Il numero di operazioni di I/O al secondo (IO/s)

  3. Il tempo medio di latenza (ms)


Stavolta mi gira di pubblicare le misure effettuate sul mio megaserver qui a casa, con i suoi "bei" dischi SATA2 e il sistema operativo a 64 bit (AMD64). Poi si sa, io sono un fisico e quando vedo delle misure non resisto.

Per prima cosa ho creato due logical volume da 10 GB con LVM su due dischi distinti, ma fisicamente uguali (Maxtor 250 GB SATA2). Ho dovuto usare l'eseguibile a 32 bit e non quello a 64 perché si lamentava dell'assenza di librerie strane. Non ho molta pazienza per queste cose quando il programma in questione non è null'altro che un file singolo eseguibile; d'altra parte la differenza 32-64 bit in questo caso potrebbe influenzare il risultato in qualche misura, come numero di operazioni a disco (più operazioni eseguite negli stessi cicli I/O) e quantità di dati trasferiti (il doppio dei dati con gli stessi cicli I/O); non penso però che in assoluto i valori massimi possano essere molto diversi. Vedremo in futuro, se possibile.

Ho quindi collegato a due raw device i due logical volume, e gli ho cambiato l'ownership per permettere al mio utente di poterci scrivere.

Ho configurato Orion come segue: 2 dischi, simulazione striping ASM, carico random.
I primo test è stato in sola lettura, mentre per il secondo ho impostato una scrittura al 50%.
I risultati sono abbastanza interessanti.

Un aiuto per leggere i grafici: Small e Large indicano il numero di processi concorrenti con letture/scritture di 8 KB (Small) e 1 MB (Large). Ho impostato Orion in modo che venissero fatte misure di processi concorrenti, presumendo che fosse il caso peggiore, altrimenti è possibile fare misure separate.

Prima prova: sola lettura
Ecco il throughput (MB/s):

Come si vede, all'aumentare dei processi small concorrenti, diminuisce il throughput, tendendo a un valore limite. Contemporaneamente, all'aumentare dei processi large, il throughput aumenta decisamente, ma solo grazie alla dimensione molto maggiore dei blocchi: si vede bene infatti che dopo il terzo processo concorrente il throughput cessa di salire all'improvviso (la differenza tra il grafico giallo e verde è piccola).

Traffico operazioni:

Facendo attenzione all'orientazione dell'asse dei blocchi large (cresce verso il lettore), qui si può notare come il numero di operazioni diminuisce all'aumentare dei blocchi large perché i dischi sono sempre più impegnati a leggere più blocchi large concorrenti; il numero aumenta invece all'aumentare dei processi small, ma dopo i 3 processi small concorrenti il trend di salita non è più molto significativo. Sembra che il limite di 3 processi sia una caratteristica del sistema.

Tempo medio di latenza:

Qui si nota come il tempo medio di latenza cresca quasi linearmente: si vede infatti che c'è una specie di plateau nell'intorno di 3 processi small concorrenti, specie con 4 processi large contemporanei.


Seconda prova: 50% scrittura
Throughput:

Questo grafico è molto simile a quello del caso in sola lettura. Non riesco a dedurre nulla di utile.

Traffico operazioni:

L'unica cosa notevole in questo grafico è che lo scalino nella crescita dell'IO/s rispetto al numero di processi è maggiormente evidente nel caso di processi large assenti. Il numero di processi limite (3) è ancora più determinante.

Tempo medio di latenza:

La latenza risulta maggiore nel caso lettura/scrittura in modo uniforme, tranne per il caso processi large, dove l'aumento è maggiore, probabilmente per l'"effetto soglia" sulla cache interna dei dischi (8 MB).

Il numero 3 dovrebbe essere una caratteristica dovuta ai gradi di libertà del sistema: il server ha due CPU (è un dual core), l'I/O è in striping su due dischi, quindi delle due l'una: o il sistema riesce a sopportare un processo in più di quello che gli è consentito dall'hardware, oppure uno in meno. In pratica i gradi di libertà dovrebbero essere quattro, considerando i possibili accoppiamenti CPU-disco (sto immaginando). Il limite deriverebbe secondo me dall'economicità dell'hardware, che in qualche fase dell'elaborazione ha un collo di bottiglia.

Spero di riuscire presto a fare qualche prova su hardware professionale come storage DAS SCSI320 o SAN; in tal caso proverò a fare una prova comparativa con i grafici.

29 novembre 2007

Oracle XE e Apache

Sto provando, a tempo perso, Oracle Application Express come framework per lo sviluppo rapido di applicazioni web. Lo scopo sarebbe di appoggiarsi su XE per piccole applicazioni web collaborative da utilizzare in gruppi limitati di persone, con tecnologia Oracle (gratuita).
Una delle prime cose che ho notato è che XE poggia direttamente sul db per quanto riguarda il protocollo HTTP, quindi non c'è Apache, ma risponde direttamente il listener.
La seconda cosa è che virtualmente il database è piuttosto lento nel rispondere alle chiamate da web, anche per un piccolo bacino di utenti; un buon indizio di ciò è anche che di default il listener risponde solo per localhost sulla porta 8080.

Un buon metodo per pubblicare l'interfaccia di XE con la flessibilità, la sicurezza e la velocità di un webserver è di utilizzare Apache come reverse proxy con il modulo mod_proxy.

Installate Apache a corredo della vostra distribuzione preferita, selezionando anche, se necessario, il modulo mod_proxy. Apache può fare da proxy per vari protocolli, in questo caso utilizziamo il proxy HTTP mod_proxy_http.

Configurate un VirtualHost di Apache. L'esempio è il seguente:
<VirtualHost *>
ServerName sbrillo2-xe
ServerAdmin your@email.address

<Proxy http://localhost:8080/*>
Order deny,allow
Allow from all
</Proxy>

ProxyPass / http://localhost:8080/
ProxyPassReverse / http://localhost:8080/
</VirtualHost>

In questo modo tutte le richieste mandate al server che risponde a sbrillo2-xe sulla porta 80 vengono automaticamente riindirizzate alla porta 8080 del loopback, con la possibilità ora di limitare gli accessi, impostare password HTTP, riscrivere gli URL.

C'è un ulteriore passo che si può fare: XE sarà comunque lento nelle risposte, visto che chi risponde non è sicuramente ottimizzato per servire pagine web. Possiamo utilizzare il modulo mem_cache, che sgrava il database da servire anche quegli oggetti statici che ogni pagina contiene. Aggiungete le seguenti righe nella vostra sezione del virtualhost:
<IfModule mod_mem_cache.c>
CacheEnable mem /
# 40 MB cache
MCacheSize 40960
MCacheMaxObjectCount 1000
MCacheMinObjectSize 1
# 20 KB max per oggetto
MCacheMaxObjectSize 20480
</IfModule>

modificando a piacere i valori di cache size, numero massimo di oggetti, dimensione massima degli oggetti da memorizzare, URL.

Ora la navigazione è molto più fluida e il vostro server è pronto per la pubblicazione su web. Nulla vi vieta, comunque, di usare reverse proxy come squid.
Da parte mia, servirebbe un po' di manualità nella programmazione.
Vi aggiornerò nel caso in cui riesca a mettere assieme una piccola applicazione.

25 novembre 2007

Modifica SPFILE in RAC

In ambiente cluster, per impostare il valore delle variabili nell'SPFILE per tutte le istanze, si usa la sintassi:
ALTER SYSTEM SET <parameter name>=<value> SCOPE=<scope> SID='*'
che ha effetto per tutte le istanze del cluster.

Ma, una volta assegnato il valore della variabile per tutte le istanze, come si fa a rimuovere il parametro per una sola istanza in caso di necessità?
Esiste una nuova estensione del comando ALTER SYSTEM:
ALTER SYSTEM RESET <parameter name> SCOPE=<scope> SID=<SID istanza>

20 novembre 2007

Multiplex controlfile con RAC e ASM

Avete creato un database RAC con ASM e vi siete trovati con un solo controlfile? Avete bisogno di duplicare il controlfile su più destinazioni o anche solo in posti diversi dello stesso storage?
Il problema maggiore è che ASM non è accessibile se non da un processo server di Oracle.

Ho elaborato un metodo molto efficace, che ho pubblicato sui forum Oracle.

Probabilmente al posto del punto 5 si può anche scrivere
restore controlfile from '+ASMDISK_DATA/prea/controlfile/current.256.636907509';
lasciando ad Oracle capire quali e quante sono le copie del controlfile da ripristinare, in quanto le conosce dal parametro control_files appena impostato.

19 novembre 2007

Oracle VM, prova 1

Ho provato ad installare Oracle VM su una coppia di server virtuali VMware :-), ma ho qualche difficoltà nell'installazione del server principale, che non riesce a vedere il resto della rete.
Qualche difficoltà ma alla fine tutto bene con il management server, basato su Enterprise Linux, OC4J e Oracle XE, tutto piuttosto automatico.

18 novembre 2007

Creazione RAC con script dbca

Ho avuto l'occasione di creare un database Oracle RAC senza poter usare dbca, ma avendo a disposizione degli script fatti creare a dbca in occasione della creazione del primo database di un cluster.
Infatti proprio lì stava il problema: volevo creare un database partendo da un nodo del cluster che non fosse il primo. Il problema era che dbca non riconosceva l'istanza ASM locale, forse perché installata su una home propria e nel contempo perché non era la prima.
L'installazione tramite gli script dbca avviene in modalità singola istanza; vengono solo aggiunte le cluster database views al catalogo, e i principali parametri di inizializzazione RAC. Alla fine degli script, però, ci si ritrova ancora un po' a largo, e serve qualche intervento manuale, riportato qui.
Gli interventi sui nodi diversi dal primo sono molto marginali: la modifica del pfile per farlo puntare all'spfile, la creazione delle directory *dump.

In pratica gli interventi finali, a database anche solo in nomount, consistono nella modifica di alcuni parametri (tra cui far diventare il database realmente in cluster con CLUSTER_DATABASE=TRUE), nella popolazione del tnsnames.ora per tutti i nodi del cluster (notare una delle poche applicazioni dei parametri *listener), e nella modifica dell'OCR per fargli riconoscere il nuovo database e le sue istanze.

Generalmente srvctl viene chiamato dai wizard come dbca durante le fasi di configurazione o installazione del database o dei servizi. Nel nostro caso (aggiunta di un database in cluster) Clusterware è piuttosto facile da configurare:
srvctl add database -d <name> -o <oracle_home>
A questo punto Clusterware vuole sapere solo quali sono le istanze associate:
srvctl add instance -d <name> -i <inst_name> -n <node_name>
Pochi parametri, quelli essenziali: il nome dell'istanza, a quale cluster è associata, e su quale nodo gira. Tutto qua.

14 novembre 2007

Old-style: Enterprise Manager Console

Siete anche voi dei fan della vecchia console di Enterprise Manager in Java?
Bene, prima di tutto, lo saprete già benissimo, non è sparita, ma è sempre presente nel client CD e nel companion CD: basta scaricarli e installarli.
Il funzionamento della console, però, sembra fermo alle funzionalità della release 9i. Nonostante ciò, a mio parere molte funzionalità sono sempre migliori di quelle riscritte in EM Database Control via web, incluso di default nella 10g. Il problema è che alcune di queste funzionalità hanno bisogno preferibilmente di un repository, ovvero di uno schema su un database Oracle, per salvare i propri dati.

Oggi ad esempio ho provato a configurare il Change Manager, che si basa sul repository di EM. Attenzione: il repository di EM versione Java è ancora quello della vecchia versione; non si tratta del nuovo repository di Enterprise Manager DB Control (10g).
Nell'help della Console c'è la sezione "Requirements before creating a standalone repository", in cui viene spiegato come creare il tablespace e l'utente per il repository. Le istruzioni funzionano anche per 10g, tranne per i permessi dell'utente/schema.

Per prima cosa bisogna creare il tablespace del repository, di circa 20M con un massimo di 2G, con un nome qualsiasi (io ho adottato OEM9REP). Probabilmente si può utilizzare SYSAUX, ma non vorrei che la presenza di segmenti "sconosciuti" nel tablespace possa dare fastidio al nuovo EM.
La "difficoltà" è nella creazione dell'utente: i privilegi/ruoli richiesti sono CONNECT, SELECT_CATALOG_ROLE, CREATE TRIGGER, CREATE PROCEDURE, EXECUTE ANY PROCEDURE, CREATE TYPE, EXECUTE ANY TYPE, SELECT ANY TABLE. C'è un problema: il ruolo CONNECT da 10gR2 in poi non ha gli stessi permessi che aveva nelle vecchie versioni; per la sola creazione del repository mancano i privilegi CREATE SESSION, CREATE TABLE, CREATE VIEW, CREATE SYNONYM, CREATE DATABASE LINK, CREATE CLUSTER, CREATE SEQUENCE, ALTER SESSION. Volendo si possono riassegnare al ruolo CONNECT mediante l'esecuzione dello script ?/rdbms/admin/rstrconn.sql.
Il repository viene creato dall'interfaccia grafica alla prima connessione; vengono eseguiti una serie di script sql presi dall'installazione del client locale.

13 novembre 2007

Oracle VM

A sorpresa, Oracle ha annunciato la sua versione della virtualizzazione del sistema operativo, basata su Xen.

Da domani si potrà già scaricare gratuitamente dal sito. Immagino che saranno in molti a provare questa nuova tecnologia, me compreso. Molti, però, che dovranno avere almeno due server "vuoti" a disposizione, come si legge nel data sheet. Praticamente due macchine virtuali VMware :-)

05 novembre 2007

Limiti della log history

Tsè, ho perso due ore per una bazzeccola: RMAN mi ha dato un errore sul backup degli archivelog perché non trovava il record corrispondente nel controlfile.
Credevo che ciò fosse dovuto al parametro MAXLOGHISTORY di creazione del controlfile; in realtà avevo aspettato troppo tra un backup e l'altro, più della recovery window, quindi Oracle aveva cancellato le entry troppo vecchie dal controlfile, quelle più vecchie di CONTROL_FILE_RECORD_KEEP_TIME (in giorni); tra l'altro l'avevo impostato io con la policy di RMAN!

MAXLOGHISTORY ha senso solo in RAC. Praticamente dà il numero di righe della tabella V$LOG_HISTORY.
Il numero di entry varia dinamicamente, adattandosi alle esigenze della receovery window.

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!

27 agosto 2007

OpenSuSE 10.2/64 e driver nVidia

Posto qui questo avviso perché dovrebbe interessare maggiormente chi come me fa prove su Oracle e Linux a 64 bit.
La nVidia evidentemente legge il mio blog :-) e ha deciso di rilasciare i driver nForce (i chipset nVidia) versione 1.23 anche per OpenSuSE 10.2.
Unico piccolo difetto è che la versione "build" del kernel di rilascio è quella precedente all'ultimo aggiornamento ufficiale (2.6.18.8-0.5-default), ma l'installazione dell'rpm e il caricamento del modulo vanno a buon fine. Bisogna comunque eseguire mkinitrd per ricreare il ramdisk di avvio, visto che comunque il modulo sata_nv viene richiesto all'avvio del kernel. Fatevi prima una copia dell'initrd.
I problemi di block corruption di Oracle non sembrano risolti, però. Non riesco proprio a capire a che cosa siano dovuti.

Intanto segnalo un'interessante commento di Howard Rogers sui sistemi a 64 bit di classe desktop (AMD64, EM64T); sono utili o no? Per i database sembra proprio di sì, ma non vorrei che i problemi da me riscontrati indichino che ci si sta avvicinando al limite di performance.

Sto facendo prove di installazione di 11g, ma serve per forza un sistema a 32 bit. Ancora un po' di pazienza :-)

24 agosto 2007

Query cache, result cache

Tra le nuove caratteristiche di 11g ce n'è una che sembra proprio presa o perlomeno ispirata dal "giocattolo" mysql: la query cache.
Tom Kyte ha prontamente scritto un notevole articolo sulla nuova feature di Oracle sull'ultimo numero di Oracle Magazine.
È utile un confronto con la query cache di mysql, il cui funzionamento è spiegato nel dettaglio nella pagina "how", dove si intuiscono perfettamente le ragioni delle limitazioni della query cache rispetto alle operazioni normali. Già una piccola differenza con Oracle è la modalità di utilizzo della feature: in mysql è a livello istanza, mentre in Oracle è a livello optimizer, quindi a livello query, e funziona quindi anche all'interno di procedure (mentre in mysql no: evidentemente considera solo l'hash value della testo, sbagliando).
Già questo basterebbe a fare una enorme distinzione sull'uso della memoria cache, visto che con Oracle bisogna specificare per ogni singola query se si vuole cachare il risultato, impedendo così la frammentazione e il riempimento inutile della cache, nonché la rimozione inopportuna di resultset utili per accogliere query che non dovrebbero essere salvate.
Oracle può inserire in cache anche i risultati delle funzioni (sempre a comando), con un'interessante caratteristica in più: si possono definire gli oggetti da cui dipende il risultato della funzione, ottimizzando i controlli che il db dovrebbe fare ad ogni esecuzione.

22 agosto 2007

Prove Oracle 11g e new features

Sto facendo le prime prove di Oracle 11g (database, ovvio :-)). Il logo dei "bidoni di petrolio" in immagine è quello originale.
Per primo ho installato il CD client, stranamente subito disponibile come download. L'installazione, su OpenSuSE 10.2 x86, è semplicissima e finalmente vedo che Oracle ha abbandonato l'ormai inutile controllo del prerequisito che il sistema operativo sia tra quelli supportati, almeno all'avvio dell'installazione. L'installazione client fa scegliere ancora tra le tipologie programmatore-amministratore; l'installazione più massiccia è quella di amministratore ma... sorpresa! Non ho capito dove sono gli eseguibili, o meglio dove sta l'Enterprise Manager della situazione, visto che il wrapper oemapp sembra sia sparito. In compenso è comparso SQLDeveloper, che quindi probabilmente sostituisce gran parte delle funzioni del "vecchio" EM in formato Java; peccato però non mantenerlo, secondo me un'applicazione a due livelli come il vecchio EM è insostituibile in molte situazioni; rimane comunque disponibile sul CD client del vecchio 10g :-).

Intanto leggiamo il manuale delle new features.
Nelle prime righe c'è una "clamorosa" aggiunta: la query cache! Sì, proprio quella di mysql. Bisogna controllare però gli algoritmi di manutenzione della cache, che in mysql sostanzialmente ne limita(va)no moltissimo l'utilizzo. Una differenza enorme, a quanto sembra, è la presenza della query cache sia sul server che su client. Troppo anvanti. Sono troppo curioso di vedere quali sono i limiti dovuti alle operazioni DDL e DML e il confronto con mysql.
Ora il connection pooling non è più riservato alle applicazioni multithread, ma anche a robe più semplici come PHP.
Gli standby possono essere interrogati in tempo reale, mentre viene applicato il redo. Finalmente! Non solo: gli standby possono essere aperti temporaneamente anche in lettura e scrittura (questa, poi!). Vedremo in futuro come funziona questa cosa nel dettaglio.
Ora i comandi DDL hanno il WAIT di default, che evita il controllo degli errori di locking esclusivi.
La ricostruzione online degli indici non ha più stati di attesa di DML lock.
C'è il nuovo comando ALTER TABLE table_name READ ONLY per evitare che anche il proprietario di una tabella la possa modificare.
C'è il nuovo parametro MEMORY_TARGET, che volendo sostituisce SGA_TARGET e PGA_AGGREGATE_TARGET.
ORACLE_BASE diventa la variabile di riferimento per le installazioni.

Nel frattempo non ho trovato nulla sul contenuto di questo strano client CD. Se dovessi trovare qualcosa vi avviso :-)

21 agosto 2007

MySQL 5 secondo Alex Papadimoulis

Ricordate Alex Papadimoulis, il creatore del magnifico Daily WTF? A quanto pare ha anche un blog, in cui ho trovato un'ottima digressione su MySQL 5 e i suoi tradizionali aspetti controversi. Ottimo.

20 agosto 2007

Oracle 11g GA

Mentre ero in vacanza :-) Oracle ha rilasciato la prima versione del database 11g, disponibile per il download, come sempre.
Ora il mio megaserver di casa avrà pane per i suoi denti, con una nuova ORACLE_HOME in aggiunta di quella sperimentale 10g.

A proposito di compatibilità, segnalo che i kernel OpenSuSE hanno una versione secondo me troppo vecchia del modulo SATA per i chipset nForce, e purtroppo la situazione non si può risolvere facilmente: nVidia mette a disposizione i sorgenti solo per le distribuzioni commerciali (es. SLES10). Speriamo che quelli della SuSE riescano ad inserire le modifiche nella nuova 10.3. Quasi quasi gli scrivo.

06 agosto 2007

Archivelog RAC su ASM

Gli archivelog di un cluster Oracle 10g su ASM possono finire, a seconda della configurazione, su molteplici destinazioni, ma quella preferenziale è sempre sullo storage condiviso, come per il resto del database.
Se archiviate anche su filesystem, e quindi per ogni server avete un thread di redo diverso, fate attenzione alla consistenza dei log archiviati localmente durante un'eventuale caduta di uno dei nodi del cluster. A me è capitata un'inconsistenza, risolta esportando l'archivelog da ASM, dove evidentemente non c'è stato un problema di salvataggio del thread. Come è possibile? Basta usare il la procedura DBMS_FILE_TRANSFER.COPY_FILE.
Attenzione che i parametri di COPY_FILE sono sempre dei directory object, non delle directory vere e proprie; corrispondono, ai fini pratici, ad alias di locazioni nello storage accessibile alle istanze, tra cui ovviamente c'è il filesystem ASM:
SQL> CREATE DIRECTORY dir_name AS '+ASM/ciao';
creando sia la directory sorgente che quella di destinazione.

27 luglio 2007

Data Pump e privilegi

Avete Oracle 10gR1? Passate oltre... Avete 10gR2? Bene. Per operazioni di export/import sarebbe bene avere un utente dedicato con i ruoli EXP_FULL_DATABASE e IMP_FULL_DATABASE, con una quota non trascurabile su qualche tablespace poco usato (ho visto 35 MB per una export).
C'è un problemino: i due ruoli non bastano, serve anche il privilegio SELECT ANY TABLE (nota Metalink 414996.1).
Speriamo che i piccoli problemi di Data Pump vengano risolti completamente nella 11g, visto che permangono nella 10.2.0.3.0.

12 luglio 2007

Sybase SQLAnywhere

Sto provando in questi giorni SQLAnywhere, nella suite IAnywhere, un interessante punto di vista sui software collaborativi per aziende.
A me ovviamente interessa la parte del database, visto che il distributore italiano me ne ha fornito gentilmente una copia su chiavetta USB da 512 MB di ultima generazione, microscopica.
Delizioso il lavoro fatto da Sybase per facilitare al massimo l'installabilità e l'amministrazione del database: la compatibilità con Linux mi pare ottima, visto che l'installazione grafica non ha dato alcun problema né sotto SuSE 10.2/64 né sotto Ubuntu 7.04/64, dove però l'installazione è stata testuale ma del tutto equivalente a quella grafica.
SQLAnywhere praticamente si avvia da un gruppo di icone sul desktop, create automaticamente dall'installazione sia su KDE che Gnome. Questa è una caratteristica molto comoda anche in ambiente server, dove tradizionalmente non si usa il display, ma con le tecnologie attuali (VNC del desktop Gnome e volendo anche Xorg in modalità client) è un peccato non avere l'ambiente grafico, che consente inoltre di avviare job direttamente sul server interessato, senza il timore che la connessione si interrompa.Tra le applicazioni ci sono un monitor del database e una specie di client grafico per fare query. Il resto delle icone sono dedicate all'avvio del database sia in modalità networking che personale. In entrambi i casi all'avvio si può specificare il nome del server e l'unico file del database, a cui corrisponde un unico file di log. Evidentemente anche a Sybase confidano sulla potenza dei filesystem "bigfile" per la gestione dei blocchi fisici su disco, che altrimenti avrebbero limiti di spazio.
Per ora non sono ancora riuscito a creare una tabella con un semplice create table, farò del mio meglio per capire come si fa.
Interessanti le slide della presentazione italiana della versione 10, in cui uno dei punti di forza è l'architettura hot-standby senza manutenzione, fatta da due (o più?) server equivalenti e un arbitro che decide chi è il primario. L'indisponibilità di un server e il suo ripristino come master o hot-backup sono automatici.

RMAN, RAC e channels

Una particolarità interessante di RMAN esclusiva della configurazione a cluster RAC è la possibilità di centralizzare la gestione dei dati di backup.
In generale, per fare il backup del db ci si può collegare ad una delle istanze RAC senza alcun problema, visto che praticamente tutto il database è su storage condiviso.
Ma che cosa succede quando si devono gestire eventuali dati locali come gli archivelog, se non collocati su storage condiviso?
Per queste situazioni si possono allocare dei canali appositi (es. 3 istanze):
RUN
{
ALLOCATE CHANNEL CH1 CONNECT 'user1/pwd1@node1';
ALLOCATE CHANNEL CH2 CONNECT 'user2/pwd2@node2';
ALLOCATE CHANNEL CH3 CONNECT 'user3/pwd3@node3';
BACKUP DATABASE PLUS ARCHIVELOG;
}

Il server process che ha l'accesso ai file ricercati si occuperà della loro gestione. In più si avrà, volendo, il parallelismo del backup. Oracle sceglie inoltre automaticamente il canale più veloce da utilizzare tra quelli disponibili per ogni datafile.

11g è arrivato

Ieri c'è stata la presentazione di Oracle Database 11g. Ho rivisto in streaming quasi metà della presentazione, molto più noiosa degli sfavillanti keynote della Apple.
Le novità comprendono:

  • Real Application Testing: vabbè solita sigla, permette di riprodurre il carico reale di lavoro di un sistema, per scopi di test.

  • Supporto avanzato al partizionamento: già qualche novità c'era stata nella 10g, evidentemente è piaciuta. Molto utile è l'advisor, che crea automaticamente nuove partizioni quando arrivano i nuovi dati.

  • Advanced Compression: finalmente arriva la compressione sia sui dati su disco che nella trasmissione di rete. Stima di compressione: 3x-5x.

  • Sicurezza: miglioramenti generali. Qui effettivamente c'era molto da fare, viste le interfacce un po' ostiche su VPD, encryption, row-level security.

  • Total recall: accesso immediato ai dati storici (presumo senza l'utilizzo di UNDO)


Per tutte queste cose bisognerà vedere l'implementazione in pratica, visto che c'è poco di pratico nelle presentazioni.

09 luglio 2007

Presentazione Oracle 11g

Mercoledì 11 verrà presentata la prossima release di Oracle Database, la 11g.
Nel frattempo leggiamo qualche new feature, anche se penso che l'elenco indicato nell'intervista sia molto incompleto.
Io ho come la sensazione che ci sarà una grossa novità sulla gestione dell'undo... seguendo il ragionamento dei wandering logs di Reiserfs, immagino che sia applicabile il concetto anche all'undo... il tablespace di UNDO potrebbe addirittura sparire, lasciando il posto a una gestione dei blocchi completamente all'interno del proprio tablespace. Staremo a vedere.

25 giugno 2007

Falcon alpha: vediamo se funziona

Installato Ubuntu server 64 bit, spacchettiamo mysql 6 alpha e configuriamo i sorgenti:
root@ubu642:~# ./configure --with-plugins=all
seguito da un make e make install. Consiglio di utilizzare --prefix=/usr/local/mysql per "inscatolare" la versione alpha di mysql in una sua directory particolare, altrimenti tutto va in /usr/local. Copiate la vostra versione preferita di my.cnf in /etc, create il database "starter" con mysql_install_db, cambiate i permessi del database con chmod, e impostate la password di root con mysqladmin; create poi un utente che ha tutti i grant sul database di test predisposto.

CREATE TABLE f (
fid int(11) NOT NULL,
descr varchar(32) DEFAULT NULL,
PRIMARY KEY (fid)
) ENGINE=Falcon;

Popoliamo la tabella:

insert into f values (1, 'uno');
insert into f values (2, 'due');
insert into f values (3, 'tre');
insert into f values (4, 'quattro');

Da un'altra sessione:

select * from f;
+-----+---------+
| fid | descr |
+-----+---------+
| 1 | uno |
| 2 | due |
| 3 | tre |
| 4 | quattro |
+-----+---------+
5 rows in set (0.00 sec)

Dalla prima sessione:

set autocommit=0;
update f set fid = 7 where fid = 4;

Dalla seconda sessione:

mysql> select * from f;
Empty set (0.00 sec)

Da qualche prova ulteriore, meno incomprensibile, è saltato fuori che bisogna committare anche la seconda sessione per vedere le modifiche della prima. Tutto questo in repeatable-read transaction isolation mode.
Ho provato anche in read-committed (la nostra preferita :-)) e non è un granché meglio.
Falcon fallisce inoltre il test di aggiornamento della chiave primaria:
update f set fid = fid+1;
dà una violazione di chiave primaria.

Bene. Aspettiamo ancora un po'. È meglio.

22 giugno 2007

Altro corso Oracle

La prossima settimana sarò alla Oracle di Sesto S. Giovanni per un altro corso Oracle:
Oracle Database 10g: New Features for Administrators Release 2.
Anche se lavoro già da un po' sulla 10g e ho letto qualche libro, non si finisce mai di imparare.

Chi fosse da quelle parti mi faccia sapere via e-mail.

Data pump exclude/include

Su Oracle Data Pump sono molto utili i parametri EXCLUDE e INCLUDE, mutuamente esclusivi, con cui si può specificare il tipo di oggetti che si vogliono escludere o includere nelle operazioni di export o import.
Ad esempio EXCLUDE=TABLE salverà tutto tranne le tabelle. Ma come facciamo ad escludere una tabella o un gruppo di tabelle? Usiamo la name clause, con cui specifichiamo un'espressione SQL a destra di un operatore:

EXCLUDE=TABLE:"IN ('EMP', 'DEPT')"
EXCLUDE=TABLE:" = 'EMP'"

Ora, se mettete tutto sulla command-line, Oracle si lamenta del fatto che l'espressione SQL non è corretta. Il problema è che le virgolette non arrivano all'interprete dei comandi, ma vengono interpretate dalla shell :-/

Le soluzioni sono due: una è fare l'escape delle virgolette:

EXCLUDE=TABLE:\"IN (\'EMP\', \'DEPT\')\"

Bisogna fare l'escape di tutte perché fatto delle prime, vengono interpretate le seconde.
L'altra soluzione è usare un parameter file (PARFILE='filename'), in cui gli escape ovviamente non vengono interpretati.

17 giugno 2007

Novità mysql: Falcon

Mysql ci stupisce con l'ennesimo motore di database: Falcon. Probabilmente dobbiamo questa novità all'acquisizione di InnoDB da parte di Oracle e al fatto che qualcosina che non andava molto c'era. Questo sospetto mi viene dal fatto che, come prima nuova feature, c'è un evidente MVCC. Anzi, TRUE MVCC. Viene anche evidenziata la data and index caching: ricordiamo che le "vecchie" versioni di mysql sfruttavano il buffering fatto dal sistema operativo sui device a blocchi come cache, ovvero non avevano cache di dati. Nel file di configurazione my.cnf vengono specificati nuovi parametri riguardo la memoria cache.
I dati relativi ad un singolo database (nel significato di mysql: un namespace) vengono scritti in un unico file; altri due file compongono il db: due log seriali. I metadati delle tabelle vengono scritti in un file frm, come il vecchio motore myisam.
A quanto pare i record modificati vengono tenuti in una memoria speciale chiamata record cache, mi pare di capire in maniera diversa da Oracle, che modifica direttamente i blocchi. I dati, gli indici e gli altri dati vengono scritti tutti insieme nello stesso tablespace; può avere senso in molti ambienti di produzione. C'è il log buffer, il log switch e il checkpoint, come Oracle. Interessante la presenza della compressione dei dati su disco.
Per ora non c'è ancora il backup online e il supporto per le foreign key. A quelli di mysql alcune cose non gli sono proprio simpatiche.
Ora si tratta di capire a quali feature presenti negli altri motori di mysql bisognerà rinunciare per potere avere le nuove funzionalità che Falcon offre, nonché quali cambiamenti bisognerà adottare nelle applicazioni scritte sapendo che mysql non offriva il multi-versioning e nemmeno la possibilità di fare rollback.
Io sono molto curioso, quindi ho subito approntato una macchina virtuale Ubuntu server 64 bit per provare il nuovo motore. Perché Ubuntu server? Perché la trovo minimale e molto ben fatta, a cominciare dal fatto che una volta installata manca persino l'ssh. Una configurazione ultraminimale che in ambito server non può che fare bene sia alle performance che alla sicurezza. Si ricordi poi che generalmente Ubuntu è molto ben supportata, ha sempre un'aggiornamento molto recente del kernel (anche troppo insistente), e un ambiente di sviluppo molto solido. Ho scelto la versione a 64 bit perché mysql 6 sembra intenzionato ad uscire a 64 bit come versione preferenziale.
Spero di avere presto un po' di tempo per fare prove col nuovo engine.

11 giugno 2007

Oracle a 64 bit

Nel finesettimana, per necessità lavorative, ho configurato il mio nuovo PC AMD64 con 4 GB di RAM, comprato per fare esperimenti su Oracle e Linux.
Ho tentato subito di utilizzare le versioni x86_64 sia del sistema operativo che di Oracle, ma mi sono trovato (prevedibilmente) subito in grande difficoltà, a cominciare dal riconoscimento delle periferiche. Ho provato Ubuntu 7.04, OpenSuSE 10.2, Fedora 7 e ho scaricato per ultimo SLES10, un po' disperato, ma ho lasciato perdere.
Domenica sera, dopo una giornata di relax a visitare castelli, ho avuto la giusta intuizione: ho risolto i problemi di installazione di OpenSuSE 10.2 e l'installazione di 10gR2 per x86_64 è andata a meraviglia, veramente senza problemi e velocissima. Nessun problema di package e compatibilità delle librerie, contrariamente ai problemi infiniti con le altre distribuzioni, parzialmente risolti.
Ho installato il db su ASM, a sua volta su raw devices a loro volta su logical volume LVM2. Spettacolare.
Ora il grosso della preparazione è finita, ho in cantiere altre attività sul db. Sono contento però di avere trovato la combinazione perfetta Linux/Oracle 64 bit, senza ricorrere alle distribuzioni commerciali.

29 maggio 2007

RMAN rollforward standby

Forse ne sono uscito. Per colpa di qualche script scritto male si sono persi dei redo log archiviati dal database RAC in produzione, quindi lo standby database non poteva più andare avanti.
Il concetto è questo: si usa RMAN per fare il rollforward dei blocchi dei datafile dello standby, che essendo fisico sono uguali a quelli originali.
Per fare ciò bisogna procurarsi un backup incrementale per lo standby:

SQL> SELECT CURRENT_SCN FROM V$DATABASE;

RMAN> BACKUP INCREMENTAL FROM SCN <scn dello stdby> DATABASE FORMAT '/tmp/ForStandby_%U' tag 'FOR STANDBY';

Portare poi i file prodotti al cospetto dello standby, portandoli a conoscenza del suo RMAN:

RMAN> CATALOG START WITH '/tmp/ForStandby_';

Io ho utilizzato un catalogo sul db principale e il control file sullo standby per evitare problemi: i due db hanno lo stesso ID!
Ora gli diciamo di fare il recover senza redo!:

RMAN> RECOVER DATABASE NOREDO;

Ora il database dovrebbe essere pronto:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Peccato che, nel mio caso, il control file dello standby è rimasto all'SCN originale, quindi ho dovuto ricrearlo con uno snapshot di RMAN sul principale:

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '...';

Portiamo il control file appena creato sullo standby e facciamo partire l'ultimo recover; dovrebbe funzionare.

22 maggio 2007

ASM su... USB!

Oggi, durante la lezione al corso Oracle di amministrazione RAC 10gR2, improvvisamente il docente tira fuori due strani oggetti blu, con due fili che uscivano da un'estremità. Dopo un paio di secondi di silenzio interrogativo, si sono rivelati una coppia di hub USB passivi con 8 "chiavette" USB. Stavamo parlando di ASM e quindi alcuni hanno capito al volo: le 8 chiavette sono state utilizzate per simulare 8 dischi reali!
Un'idea fantastica e spettacolare: mi immagino gli 8 led che lampeggiano in modo psichedelico durante l'utilizzo con ASM! Deve essere anche molto istruttivo e fa capire molto chiaramente come funziona ASM e un volume manager generico, volendo.
Complimenti al docente! Un grande (d'altronde è laureato in fisica come me :-)

19 maggio 2007

DBA Oracle a tempo pieno

Il silenzio relativo degli ultimi mesi ha una spiegazione: da lunedì scorso ho cominciato a lavorare come DBA Oracle/system engineer per un'azienda di Milano.
Per me è un grande cambiamento, ma ho trovato un ambiente molto professionale e colleghi molto preparati; tutto ciò è per me di grande aiuto.
Ora ho a che vedere con tecnologie che ho utilizzato solo per esperimenti personali: Real Application Clusters e Standby database. Tutto veramente intrigante ;-)
Proprio ieri ho recuperato un database in standby che non voleva saperne di ripartire per un danno al tablespace di system (grande scelta per un file corrotto...). Ho fatto un recover di 2 ore e 40 minuti e poi il db è tornato all'antico splendore.
Beh, per la prima settimana è una piccola grande soddisfazione.
Cercherò di essere più presente con il blog; dovrei avere anche molto materiale sotto mano per nuove idee ;-)

Per tutta la prossima settimana sarò a un corso nella sede Oracle a Sesto S. Giovanni. Chi fosse da quelle parti mi può avvertire con una mail.

01 aprile 2007

Ci sono ancora - Verity

Ciao a tutti! È da tempo che non scrivo, ma chi mi segue sa che sono stato in Cile e ho un periodo di lavoro piuttosto denso.
Nel frattempo ho cominciato a studiarmi, stavolta per lavoro, il motore di ricerca Verity. Lo so, è un po' off-topic rispetto a questo blog, ma ritengo di doverlo riportare ad uso di tutti quelli che non hanno un sito transazionale, ma solo di ricerca e indicizzazione di contenuti.
Il prodotto ora ha cambiato nome (districatevi voi nelle sigle del marketing sul sito, io ci rinuncio), io riporto comunque qualche funzionalità della versione 5.5.
La cosa secondo me più notevole è l'architettura, ovvero lo stack tecnologico di un'installazione Verity: in cima ci sono i broker, una sorta di dispatcher, poi i server Verity, infine eventuali sorgenti esterne di dati, che possono anche essere indicizzate continuamente. La forza di questa architettura sta nel fatto che i broker possono sia bilanciare il carico delle query che garantire il failover, e che i server possono ospitare anche collezioni condivise, suddividendosi il carico.
Maggiori informazioni più avanti!

12 febbraio 2007

Nuove tecnologie Oracle

È un bel po' che non scrivo, ma ultimamente ho molto da fare e durerà ancora per un po'.
Intanto riporto qualcosa dalla newsletter OTN, sempre molto interessante: