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.