1Z0-040: missione compiuta

Ieri ho aggiornato la mia certificazione Oracle OCP, passando l'esame 1Z0-040 e diventando OCP 10g.

L'esame non è dei più semplici per un paio di motivi: è meno popolare degli altri esami e deve concentrarsi sugli argomenti che costituiscono le novità della nuova release rispetto alla vecchia.
Il primo motivo ha come conseguenza che è più difficile reperire materiale di studio; il secondo che generalmente le domande riguardano aspetti minori del funzionamento del database, nonché poco interessanti e a volte addirittura noiosi.
Le domande a volte sono mal formulate, prestandosi a diverse interpretazioni, e a volte sembra che chi le ha formulate non aveva ben chiaro il concetto.
Come conseguenza di tutto ciò, mi sono trovato davanti a molte domande inaspettate ma, preso il toro per le corna, ragionando e sfruttando bene tutto il tempo a disposizione, ne sono uscito vincitore.

Per quanto riguarda il materiale di studio, mi sono affidato per la prima volta ad un testo Sybex che, sebbene più preciso dei testi Oracle Press per gli esami, latita dal punto di vista del software per la preparazione.
Il CD-ROM allegato al libro contiene una versione PC e una versione palmare delle esercitazioni. La prima è semplicemente in Flash, quindi fruibile con tutti i dispositivi dove ci sia un browser che supporti Flash, mentre sulla confezione del CD c'è scritto "per Windows". Misteri.

I testi Oracle Press, invece, avevano un software apposito per Windows, che comprensibilmente permetteva di fare di più rispetto a un'applicazione flash, sfruttando il fatto che poteva salvare su disco i risultati delle esercitazioni e indicare chiaramente quali fossero gli argomenti su cui insistere con lo studio, nonché mischiare le domande e le risposte per evitare che si memorizzassero meccanicamente.

La versione per palmare della Sybex è ancora più limitata di quella per PC, visto che si tratta solo di una serie di "schede" da compilare o a cui rispondere mentalmente, corredate da un tasto per far comparire la soluzione. Diciamo che si adattano al contesto in cui di solito viene usato il palmare, ovvero "on the road"; sono comunque un valido aiuto.

Ora pausa di qualche mese per finire i libri in coda, e poi chissà, ci sono molti esami interessanti da sostenere!

OpenSuSE 10.3 x86_64: gli rpm per Oracle 10g

Tra tutte le installazioni Oracle 10g che ho fatto, escludendo Red Hat 4, mi sembra che la migliore distribuzione a cui appoggiarsi sia OpenSuSE 10.3.
L'unico problema che si potrebbe avere è nella versione a 32 bit, che probabilmente richiede la ricompilazione del kernel. Con le macchine attuali x86_64 il problema non si pone.

Riporto qui la lista degli rpm da installare oltre a quelli di default da DVD OpenSuSE 10.3 a 64 bit:

gcc-32bit-4.2-24.x86_64.rpm
gcc42-32bit-4.2.1_20070724-17.x86_64.rpm
glibc-32bit-2.6.1-18.x86_64.rpm
glibc-devel-32bit-2.6.1-18.x86_64.rpm
libgcc42-32bit-4.2.1_20070724-17.x86_64.rpm
libgomp42-32bit-4.2.1_20070724-17.x86_64.rpm
libmudflap42-32bit-4.2.1_20070724-17.x86_64.rpm

Nell'installazione grafica normale, alla selezione dei pacchetti da DVD, selezionare anche il Development e C/C++ development.
I pacchetti dell'elenco di sopra sono reperibili solo da repository web, quindi o si aggiunge l'URL del repository al SuSE online update, oppure si scaricano manualmente e si installano da linea di comando.
Vedere il sito SuSE per i mirror.

RAC cluster interconnect: twisted!

Una delle "limitazioni" più famose delle implementazioni Oracle RAC a due nodi è l'impossibilità, secondo la documentazione, di utilizzare un'interconnect formata da un solo cavo diretto tra un server e l'altro.
Le FAQ di RAC riportano:

NO. CROSS OVER CABLES ARE NOT SUPPORTED.
The requirement is to use a switch:
Detailed Reasons:
1) cross-cabling limits the expansion of RAC to two nodes
2) cross-cabling is unstable:
a) Some NIC cards do not work properly with it. They are not able to negotiate the DTE/DCE clocking, and will thus not function. These NICS were made cheaper by assuming that the switch was going to have the clock. Unfortunately there is no way to know which NICs do not have that clock.
b) Media sense behaviour on various OS's (most notably Windows) will bring a NIC down when a cable is disconnected.
Either of these issues can lead to cluster instability and lead to ORA-29740 errors (node evictions).

Due to the benefits and stability provided by a switch, and their afforability ($200 for a simple 16 port GigE switch), and the expense and time related to dealing with issues when one does not exist, this is the only supported configuration.
Please see certify.us.oracle.com as well.

Vorrei però precisare quanto segue:

1. Per gli switch moderni a 1 Gb i cavi "cross" sono equivalenti a quelli normali; a me risulta che siano equivalenti anche a 100 Mb (verificato sul mio router di casa).
2. L'instabilità non è giustificata, a meno che si pensi ai SO Microsoft e ad eventuali versioni Linux che spengono la scheda di rete in caso di inattività prolungata o assenza di segnale all'altro capo in fase di avvio.
   
3. Per il funzionamento effettivo del cross-link, basta provare e vedere se funziona

Aggiungiamo che le schede di rete recenti (es. e1000) hanno tutte le migliori caratteristiche desiderabili, e soprattutto possono essere configurate in bonding.

Gli scenari da confrontare sarebbero due:

1. I 2 nodi collegati a uno switch
2. I due nodi collegati tra loro

Gli oggetti che si possono rompere, nel caso del "sistema interconnect", sono:

1. lo switch
2. i due cavi di rete
   
3. le quattro schede di rete

I cavi di rete di per sè sono molto poco propensi a rompersi, visto che strutturalmente sono molto semplici; eventualmente potrebbero essere soggetti a sollecitazioni meccaniche esterne. Sono due, quindi devono rompersi entrambi nello stesso periodo per dare problemi.
Le schede di rete hanno più o meno la stessa probabilità di rompersi di qualsiasi altro elemento attivo. Sono due per server, quindi la ridondanza abbassa di molto la probabilità di disservizio.
Lo switch è unico. Per avere una certa affidabilità e velocità bisogna acquistare qualcosa di più di "$200 for a simple 16 port GigE switch"; qualcosa di molto costoso rispetto ai server. Sta di fatto che è un elemento unico; se si vogliono due switch i costi raddoppiano.

Veniamo ora agli scenari problematici:

1. Shutdown di una delle due istanze, più o meno volontario
   
2. Reset o shutdown software di un server
3. Spegnimento togliendo la corrente

Le istanze RAC comunicano via interconnect e voting disk. Un reset o uno spegnimento di un nodo sarebbe facilmente risolto dal voting-disk, in teoria. Tra le configurazioni con e senza switch di mezzo c'è una differenza: la mancanza di alimentazione a uno dei capi dell'interconnect, ad esempio per spegnimento di un server, provoca l'errore di link down.
Consideriamo solo il caso senza switch: gli scenari peggiori quindi sono l'interruzione totale e improvvisa dell'alimentazione per un nodo, e il distacco di entrambi i cavi di rete.
La prima possibilità è realistica, e provoca il link down. La seconda possibilità è, consentitemi, praticamente irrealizzabile.

Pensiamoci un attimo: la differenza col caso switch è che in mezzo c'è un altro componente che potenzialmente può dare problemi. La cosa migliore è quindi che lo switch non sia presente! Con un solo switch in mezzo, in caso di spegnimento dello switch stesso per qualsiasi motivo, si realizzerebbe la condizione per cui i nodi non si sentono più via interconnect, hanno un link down, e le istanze sono entrambe nello stesso stato: è la situazione di gran lunga peggiore: quella del distacco dei due cavi di rete dell'interconnect. La configurazione con i cavi diretti è quindi, a mio modo di vedere, addirittura migliore di quella consigliata da Oracle senza appello.

Rimane da provare l'interruzione improvvisa dell'alimentazione per un nodo.
L'ho provata.
In questo caso le istanze non sono nello stesso stato: una non c'è più.
Ecco ciò che succede all'altra istanza:
Tue Mar 11 15:01:42 2008
ospid 1179: network interface with IP address 192.168.1.107 no longer running (check cable)
Tue Mar 11 15:01:52 2008
Reconfiguration started (old inc 2, new inc 4)
List of nodes:
0
Global Resource Directory frozen
* dead instance detected - domain 0 invalid = TRUE
...
Il link down viene rilevato. Tutto prosegue regolarmente. In caso di dubbio Clusterware avrebbe riavviato la macchina. Quindi tutto bene.
Gli indirizzi IP VIP vengono correttamente riconfigurati.

Al ripristino del nodo in failure si ottiene:
Tue Mar 11 15:12:42 2008
ospid 1179: network interface with IP address 192.168.1.107 is now running
Tue Mar 11 15:15:12 2008
Reconfiguration started (old inc 4, new inc 6)
List of nodes:
0 1
Global Resource Directory frozen
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
...
Ottimo: link up e riconfigurazione del cluster. Tutto regolare.

In sintesi, per un sistema RAC a due nodi non espandibile, a quanto sembra, è molto meglio avere un'interconnect a cavi diretti piuttosto che avere di mezzo un apparato di rete.

Restore in ambiente RAC

Per lavoro ho dovuto spostare un database RAC di test da un volume ASM ad un altro. Tralasciando i motivi, ho deciso di effettuare un restore completo della parte dati ASM a partire da un backup RMAN con catalogo.
Noto alcune cose interessanti:

• Nonostate il catalogo, bisogna sempre impostare il DBID prima di tutto
• È necessario ricreare la directory base sotto +<DISKGROUP>
• Se proprio non si ha il pfile creato a mano dall'spfile, si può usare lo startup force nomount da RMAN, per avere un minimo server process in modo da accedere ad ASM e fare il restore dell'spfile.
  
• Il restore dall'autobackup è molto comodo: si recupera sia il controlfile che l'spfile (separatamente)
  
• Il restore dell'spfile va fatto specificando il filename di destinazione nel diskgroup condiviso (TO '...')

Ho notato anche due difetti di Enterprise Manager db control una volta che il database RAC è tornato a funzionare: per prima cosa la configurazione interattiva con emca non funziona, almeno nel mio caso di ASM home separata. Bisogna per forza usare la linea di comando di emca ricavandola da uno degli script di creazione del database fatti da dbca (consiglio vivamente di far creare sempre gli script di creazione del database da dbca).
Secondo difetto: nelle pagine EM su ASM, lo spazio utilizzato dal database viene visto come "internal" (tipo archivelog) e non come spazio allocato da un database. Questo aspetto è tradizionalmente difettoso, almeno in RAC: i nomi dei database che utilizzano un dato diskgroup sono a volte solamente quelli di una delle due istanze; in questo caso, nemmeno quello.

Oracle 10.2.0.4.0/x86 is out

Un veloce post perché stamattina ho trovato il patchlevel 3 di 10gR2 su Metalink, solo per x86, e lo sto scaricando.
A presto per eventuali commenti.

Aggiornamento (10:33): a quanto pare è stato fatto il backport di Real Application Testing da 11g a 10g.

Aggiornamento (11:24): Enterprise Manager Database Control ora è di default via HTTPS!

Aggiornamento (10-3): risolto anche il problema della tabella ROUT troppo grande nel catalogo di RMAN.

11g Real Application Testing spiegato

Segnalo un interessante articolo di Arup Nanda sull'ultimo Oracle Magazine, a proposito di Real Application Testing e i suoi meccanismi.
Molto più chiaro delle decine di documenti marketing letti fin'ora, l'articolo di Nanda mette alla luce le procedure necessarie per replicare il carico reale su un server di test, facendo capire quali sono gli oggetti fisici in gioco, quindi in ultima analisi come funziona Real Application Testing.

Bind peeking e piani di esecuzione: DTY

In questi giorni uno sviluppatore mi ha sottoposto una query abbastanza semplice, che però veniva eseguita troppo lentamente dalla nuova versione della nostra webapp.
Ho subito cercato di replicare il comportamento della query via sqlplus, anche con le variabili di bind, e ho visto che effettivamente la query era lenta.
Dopo avere controllato rifatto le statistiche (macchina di test), tutto è tornato normale e la query era velocissima. Da un rapido esame dell'autotrace era evidente che il piano soffriva di statistiche sballate, ma ciò era nelle attese sul database di test, in cui le tabelle vengono caricate e scaricate continuamente.

La situazione per il thin client Java invece non migliorava, anzi a tratti peggiorava.
Ho fatto attivare il trace dalla sessione Java, ma simpaticamente proprio il piano di esecuzione che mi interessava non ha fatto a tempo a finire nel file di trace; pazienza, tanto già sapevo che era sballato e che un piano corretto esisteva (quello scelto via sqlplus e visto con autotrace), l'importante era capire perché. I dati di consistent gets/query, nel trace, erano completamente diversi. La query via Java muoveva 1000 volte la quantità di dati mossa da sqlplus, con le stesse 807 righe risultanti.

Mi sono ricordato di un post di Cristian Cudizio sul peeking, nel quale veniva citato sia il metodo di Alberto Dell'Era per estrarre le variabili di bind usando la feature non documentata dbms_xplan.display_cursor(null, null, 'ADVANCED'), sia un post di Jonathan Lewis in cui ho rapidamente identificato la stessa mia situazione.

Subito ho tentato di vedere le variabili di bind con il metodo di Alberto, ma serve almeno l'accesso alla V$SESSION, e non avevo molta intenzione di indagare, visto che, a mio modo di vedere, avrebbe dovuto funzionare con gli stessi privilegi necessari per l'autotrace.
Ho utilizzato invece il trace 10g via DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id IN BINARY_INTEGER DEFAULT NULL, serial_num IN BINARY_INTEGER DEFAULT NULL, waits IN BOOLEAN DEFAULT TRUE, binds IN BOOLEAN DEFAULT FALSE), applicandola solamente alle sessioni del pool di connessioni esclusivo dello sviluppatore in questione.
Per ogni sessione del pool ho avviato il trace con
DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => sid, binds => true). Non serve infatti il serial#.

È risultato che sqlplus eseguiva la query velocemente perché io correttamente impostavo il tipo delle variabili di bind a char(5), mentre il thin client Java finiva per impostare il tipo a varchar2.

Dove sono disponibili queste informazioni? Nel file di trace era presente la sezione delle variabili di bind, e per tutte era indicato, oltre il valore, una serie di dati tra cui
oacdty=01
che contraddistingue il tipo varchar (DTY = data type), mentre il tipo di sqlplus era char/nchar (96).

Vi risparmio il piano di esecuzione sbagliato, quasi comico.
Ho potuto vagliare comunque, in seguito, la bontà del SQL tuning advisor di Enterprise Manager, che con una comprehensive analysis mi ha fornito sia il piano sbagliato che quello corretto, proponendomi però di applicare un SQL profile alla query, invece che risolvere correttamente il problema.

Lentezze in RMAN

Oracle 10g ha problemi residui di lentezza di RMAN, ad esempio durante la sincronizzazione del catalogo. Metalink riporta i workaround principali a nella nota 463227.1.
Un ottimo punto di partenza è l'analisi delle performance da parte di Enterprise Manager sul database del catalogo. Si possono identificare problemi di indici già dall'esame sui picchi di attività.

Le cose principali da controllare sono:

1. il numero dei record nella tabella ROUT e nella RSR


2. la presenza di indici su ROUT e RSR

Devono essere presenti gli indici rout_i_db on rout(db_key) e rout_i_rsr on rout(rsr_key).

Anche sulla tabella RSR può essere utile l'indice rsr_i_stamp on rsr(rsr_sstamp, rsr_srecid).

Se collegate al repository di RMAN una versione aggiornata di Oracle, potete sempre fare un'UPGRADE CATALOG per assicurarvi che le modifiche indicate vengano automaticamente incluse, se necessario.

La saga di DBCA e ASM

Dopo decine di installazioni Oracle questo strano problema di DBCA che non riconosce l'istanza ASM presente e funzionante sul server forse è giunto alla sua soluzione.

Il problema è questo: durante la creazione di un database senza la creazione contestuale dell'istanza ASM (specie RAC, nel mio caso), oppure (più probabile) con ASM già configurata in un'altra ORACLE_HOME, DBCA visualizza il seguente errore:

DBCA could not startup the ASM instance configured on this node. To proceed with ASM diskgroup management you need the ASM instance to be up and running. Do you want to recreate the ASM instance on this node?

Oracle, nella nota Metalink 467756.1, afferma che il problema riguarda la versione 10.2.0.3.0; io confermo, ma accade a volte anche con la 10.2.0.1.0. La soluzione però non è valida, almeno per RAC: la nota dice di aggiungere l'istanza ASM a /etc/oratab, ma nel mio caso la entry apposita già c'era e su tutti e due i nodi del cluster.
Qualsiasi tipo di combinazione e configurazione delle variabili d'ambiente non aveva alcun effetto.

La soluzione (tenetevi forte) sembra proprio la seguente:
eseguire DBCA in questo modo:
#>cd $ORACLE_HOME/bin
#>./dbca
e non tramite path!

D'oh!

Homepage di EM lenta

In questi giorni sono incappato in una strana lentezza della homepage di Enterprise Manager (database control). Tutte le altre pagine venivano visualizzate con la solita velocità (abbastanza lente), ma quella principale ci metteva fino a mezzo minuto (!).

Ebbene, è risultato che lo statement incriminato era una semplice select da una view di sistema, precisamente V$RMAN_BACKUP_JOB_DETAILS, che ci metteva fino a 30 secondi per restituire una risultato; per inciso, la view conteneva una dozzina di righe.

Bene.

Andando a vedere il testo della view, si scopre che si basa su un'altra view, V$RMAN_BACKUP_SUBOBJ_DETAILS, la quale si basa su un'altra view, V$RMAN_STATUS, la quale si basa finalmente su 3 fixed table.

Da una ricerca sui forum Oracle, ho intuito che la lentezza è dovuta alla presenza delle statistiche sulle 3 fixed table.

È bastato quindi eseguire:
dbms_stats.delete_table_stats('SYS', 'X$KRBMRST')
dbms_stats.delete_table_stats('SYS', 'X$KSFQP')
dbms_stats.delete_table_stats('SYS', 'X$KCCRSR')
per riportare la situazione ad una velocità normale (a dire il vero piuttosto veloce).

Per essere sicuri che non vengano prese in futuro le statistiche su quelle fixed table, si può usare
dbms_stats.lock_table_stats('SYS', 'X$KRBMRST')
e così via.

Un caso in cui le statistiche è meglio non averle.

Nota Metalink: 420200.1

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!

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.

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

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.

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.

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>

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.

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.

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.

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.

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 :-)

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.

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.

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.

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

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.

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.

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.

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!

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!

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 :-)

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.

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 :-)

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.

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.

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.

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.

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.