Rudy's DBland

La scalabilità di MyISAM secondo Oracle

2011-02-09T19:40:00.000+01:00

Oracle ha divulgato i risultati di un test del MySQL performance team in cui sono state messe a confronto le prestazioni dei motori MyISAM e InnoDB di MySQL.

Il grafico nel blog è eloquente: dall'andamento delle curve non posso pensare ad altro che agli effetti della serializzazione completa delle operazioni di MyISAM, rispetto all'efficienza del multi-versioning operato da InnoDB.
Certo il multi-versioning costa, è pesante da gestire, rallenta le query singolarmente, ma la scalabilità è un'altra cosa.

Il whitepaper scaricabile è illuminante, soprattutto nei paragrafi "Comparing InnoDB & MyISAM" e "Conclusions", in cui si leggono senza giri di parole vantaggi e svantaggi delle due soluzioni, e anche i loro impieghi più adatti.
La versione di InnoDB presa in esame è l'ultima, la 1.1, in cui sono stati introdotti grandi miglioramenti (tutti riportati in dettaglio), ma il discorso rimane valido anche per le versioni precedenti: basta guardare i grafici dell'appendice B.

Non sorprende che da MySQL 5.5 il motore di default diventa InnoDB, raccomandato per le nuove applicazioni.

Solaris 11 Express è arrivato

2010-11-18T21:12:00.001+01:00

Un paio di giorni fa Oracle ha rilasciato Solaris 11 Express.

Grande varietà di formati di installazione: testo, automatizzata e live, e c'è anche la versione usb di tutt'e tre; viene anche messo a disposizione tutto il software per creare un repository locale.

È ora possibile valutare con mano le intenzioni di Oracle per il futuro di Solaris.
Dalle prime prove che ho fatto, lo sforzo per evolvere tecnologicamente Solaris è evidente e promette bene per Solaris 11, il cui rilascio è previsto per il 2011.

Altre pagine lente in Enterprise Manager aggiornato

2010-11-18T20:58:00.000+01:00

Mi sono trovato in una strana situazione dopo l'aggiornamento di due database a 10.2.0.5: una pagina di Enterprise Manager, la Top Activity, ci metteva 5 minuti ad essere visualizzata; in un altro caso le pagine di ASM risultavano irraggiungibili, come ogni tanto accade.

Il primo caso era effettivamente inusuale: nessun carico sulla CPU, nessuna query strana, nessuna attività a disco.
È risultato dal log applicativo che era colpa di un timeout di una connessione SSL alla porta di default di EM, nel file emoms.properties. Il mio EM era infatti configurato in http, mentre l'aggiornamento riconfigura EM in https, ma a quanto pare scrive qualcosa di irregolare nel file (EMD_URL in maiuscolo?), in modo che, riconfigurando EM in http, la linea emd_url rimane con un URL https.

L'effetto collaterale è stato di risolvere anche il secondo problema, che ha richiesto anche il riavvio dell'agente sul secondo nodo del cluster.

Solaris 11 Express sta arrivando

2010-11-09T22:14:00.001+01:00

Oracle sta finalmente rivelando in pratica come sarà lo sviluppo di Solaris.

Entro fine anno vedrà la luce Solaris 11 Express, che precede Solaris 11, il quale a sua volta uscirà nel 2011.

Le nuove caratteristiche di Solaris 11 Express sono visibili nelle slide di Lisa 2010 in questo blog post. E sì, è inclusa la deduplica in ZFS!

Nella prima slide trovo la conferma di quello che ho sempre pensato delle nuove strategie: Solaris sta diventando il sistema operativo per i sistemi high-end, mentre per tutti gli altri sistemi c'è Oracle Enterprise Linux, ora col nuovo kernel Oracle.
"Oracle Solaris: The Mission Critical OS. If It Must Work, It Runs on Solaris"

Oracle 11.2.0.2, i patchset cambiano

2010-10-13T22:19:00.001+02:00

Grandi novità per i patchset Oracle.

A cominciare dal patchset 11.2.0.2, i patchset saranno delle installazioni complete del software, quindi, per le nuove installazioni, non sarà più necessario installare il software di base (11.2.0.1), scaricare i patchset e applicarli.

Il patchset, enorme (4.7 GB), è infatti formato da 7 file zip: i primi due per il database (anche RAC), poi Grid, Client, Gateways, Examples e Deinstall, che finiscono ognuno nelle rispettive directory.

Per le installazioni esistenti, la grande novità è l'out-of-place upgrade, consigliato rispetto al tradizionale in-place upgrade: la nuova versione del software viene installata in una nuova ORACLE_HOME, senza intaccare quella vecchia, e alla fine dell'installazione viene migrato il database alla nuova versione. Ciò ha due vantaggi principali:

Il downtime è minore: non è più necessario fermare il database e i processi per installare il nuovo software.
Il vecchio software rimane al suo posto, in tal modo viene facilitato il ritorno alla vecchia versione (prima bisognava fare il backup manuale).

Il programma di installazione ora può scaricare patch per sé e per il database direttamente in fase di installazione, eliminando tutti i problemi di aggiornamento in questa fase.

Le novità di management si trovano nella "New features guide", ora aggiornata al patchset.

Stato di Btrfs

2010-08-31T22:35:00.000+02:00

In questi giorni era in programma un webcast Oracle sullo stato dello sviluppo di Btrfs, il nuovo filesystem open-source sviluppato da Oracle sulla falsariga di ZFS di Solaris.
Btrfs è ormai incluso nel kernel Linux dalla versione 2.6.30, anche se rimane comunque in sviluppo e non è idoneo per l'entrata in produzione.

Come ZFS, Btrfs si focalizza sul superamento di tutti i limiti dei filesystem tradizionali, quali le dimensioni massime di file e filesystem, la gestibilità e la scalabilità all'aumentare delle dimensioni dello storage, e la sicurezza e affidabilità dell'I/O.

La "novità" tecnologica principale su cui si basa la gran parte delle meraviglie di ZFS e Btrfs è il COW (Copy On Write), ovvero il metodo per cui non vengono mai modificati o rimossi i blocchi esistenti, ma ogni operazione di scrittura alloca una nuovo blocco, fino ad esaurimento dello spazio disponibile.

Le differenze da ZFS si possono riassumere nelle seguenti, almeno a quanto ricordo:

Snapshot scrivibili: interessantissimo, permette nuovi e inediti scenari di versioning, backup, test, tutti praticamente a costo zero e istantanei.
Deframmentazione online: il COW ha come effetto collaterale un'alta deframmentazione. Penso che comunque la deframmentazione non sia molto importante in un ambiente SAN.
Conversione da ext3/4: esiste un tool di migrazione dei dati esistenti che sfrutta lo spazio libero dei volumi ext3/4.
Ottimizzazione per SSD: esistono delle opzioni di mount per i dischi SSD, che per esempio non hanno bisogno di routine anti-frammentazione in scrittura.

RAID 5/6 sono ancora assenti; sono invece molto sviluppati ed efficienti in ZFS.

È importante sottolineare che per Btrfs non è previsto il funzionamento come cluster filesystem.

Ho guardato il webcast in differita, quindi non ho potuto fare domande, anche se quelle che ho sentito erano molto interessanti e facevano capire che l'audience aveva più o meno gli stessi dubbi e interrogativi sulla genesi e sul futuro del progetto Btrfs, visto che ora Oracle Solaris ha ZFS in produzione (e di conseguenza in manutenzione).

Il webcast è disponibile a questo indirizzo.

Dove sono finiti Solaris e ZFS

2010-07-26T21:22:00.000+02:00

All'inizio di luglio ho ricevuto una newsletter Oracle che parlava dei nuovi storage basati su hardware Sun.
Al momento non ho prestato molta attenzione all'annuncio, considerando che era abbastanza ovvio che la produzione di server Sun venisse mantenuta o ampliata. Confesso di avere trascurato la parola storage.

Arriverò anche per ultimo a rendermi conto di quanto sta accadendo per le tecnologie Sun in casa Oracle, ma sono mesi che attendo la "prossima" release di Opensolaris per poter provare, anzi utilizzare direttamente, le nuove mirabolanti caratteristiche di ZFS, e nulla si muove.
Sta di fatto che le release di Opensolaris (e Solaris, presumo) sembrano congelate a tempo indefinito. È possibile solamente scaricare le versioni beta di OS fino alla build b134.

Oggi mi sono imbattuto in una pagina web dove si citava Sun Unified Storage, che mi ha richiamato quella newsletter, che qualche ricordo aveva lasciato.
Ebbene ho "scoperto" che ZFS è la tecnologia su cui si basa la serie 7000 degli storage server.

Non serve dire altro: a mio parere ZFS era/è una tecnologia con un valore aggiunto elevatissimo, tale da giustificare da solo gran parte dell'acquisizione di Sun, valore comunque troppo elevato per lasciarla gratuita. Non resta che sperare che Opensolaris continui per la sua strada.

È uscito 10.2.0.5, l'ultimo patch set per 10gR2

2010-05-04T15:10:00.002+02:00

Come da titolo di questo post, è uscito da qualche giorno il patch set 10.2.0.5, l'ultimo patch set per Oracle 10gR2, per ora disponibile solo per Linux 32 e 64 bit.
Gli eventuali aggiornamenti futuri arriveranno sotto forma di patch set updates (PSU).

Solaris 10 non è più gratuito

2010-03-30T15:27:00.005+02:00

Dopo una lunga pausa invernale senza rilevanti novità da scrivere sul blog, oggi mi sono imbattuto in una novità poco gradita: Oracle ha modificato i termini di licenza di Solaris 10, obbligando gli utenti a sottoscrivere un contratto di supporto per potere utilizzare il software.

Per me è un po' un colpo basso: anche se OpenSolaris rimane libero e liberamente utilizzabile, Solaris 10 era, a mio parere, l'unica piattaforma alternativa a Linux e ben più stabile complessivamente.
OpenSolaris è praticamente inutilizzabile per installare Oracle, primo perché totalmente non supportato e poi perché mancante di molti pacchetti richiesti in fase di installazione e non facilmente sostituibili.
OpenSolaris è inoltre molto più orientato al desktop, non al server.
Certo, è probabile che il supporto non sarà un costo insostenibile per le aziende di qualsiasi dimensione, ma rimane sempre un possibile motivo di mancata preferenza rispetto ad altre piattaforme.

Come da me a grandi linee previsto, Solaris è destinato a diventare il sistema operativo d'elite per server Oracle, mentre Linux è destinato al mercato di fascia medio-bassa. Ciò potrebbe avere però ripercussioni su OpenSolaris e la comunità free in generale; staremo a vedere.

Ottimizzare ext3 su RAID

2009-12-01T23:07:00.000+01:00

Una domanda che mi sono sempre fatto, quando mi trovo a lavorare con un filesystem ext2/3 nuovo su volumi sempre più grandi, è come possa un filesystem praticamente invariato da decenni a supportare unità logiche di centinaia di GB senza in qualche modo "accusare il colpo". Per questo preferisco filesystem più moderni ma, ahimè, non supportati o non mainstream sotto Linux.

ext3 per altro verso presenta caratteristiche molto interessanti per Oracle: supporta il direct I/O e l'I/O asincrono, due feature molto importanti per massimizzare le prestazioni di un database sotto Linux. Ma i 4 KB di dimensione massima del blocco e la struttura abbastanza tradizionale del filesystem mi lasciano perplesso di fronte a unità logiche di qualche terabyte.
Pensiamo ad esempio ai nuovi filesystem come btrfs o ZFS (due a caso :-)). Praticamente non c'è paragone tra ext3 e i filesystem di nuova generazione.

Mentre aspettiamo che Linux si decida ad adottare un filesystem di livello enterprise e con caratteristiche moderne, possiamo massimizzare almeno le prestazioni di ext3 adattandolo all'astrazione dell'hardware sottostante con cui ci troviamo ad operare, tipicamente un'unità RAID.

Dobbiamo considerare che alcuni livelli RAID, come il RAID5, soffrono di lentezze strutturali in scrittura a causa del calcolo di parità, arrivando al massimo delle performance solo quando viene effettuata una scrittura di una stripe completa. Durante la creazione di un volume RAID è solitamente possibile specificare la stripe size, da pochi KB fino a circa 256 KB e oltre.

ext3 ha un paio di parametri che aiutano a ottimizzare il filesystem in scrittura: stride e stripe-width.

stride è il numero di blocchi di filesystem che servono per scrivere una stripe (nel caso ext3 un blocco è di 4 KB praticamente sempre).
stripe-width è la quantità di blocchi che servono a coprire una scrittura completa su tutti i dischi che "portano" dati, multiplo intero della stride.
Mi spiego meglio con un esempio: RAID5 usa una parità distribuita che risulta in uno spazio disponibile di n-1 dischi, quindi con una certa stripe size verranno scritte n-1 stripe che "portano dati" sui dischi, e 1 stripe di parità; questa è la stripe width, e per ext3 si misura in blocchi e corrisponde a stride*(n-1)*blocksize nel caso di RAID5.

C'è un documento di Centos sull'ottimizzazione di ext3 con l'ottimizzazione per il RAID nell'ultimo paragrafo, anche se c'è qualche errore di notazione. Il fatto che stripe-width sia stato rimosso da Centos 5.3 corrisponde a verità purtroppo anche per RHEL. Non riesco a spiegarmi questo fatto, quando sulla mia Ubuntu desktop è ben presente.

Qualcuno si è creato anche la calcolatrice apposita, che potete trovare qui: http://busybox.net/~aldot/mkfs_stride.html

Oracle 11gR2 per Solaris SPARC e x86

2009-11-25T23:20:00.001+01:00

Oggi ho notato che è uscita la versione per SPARC e x86 di Oracle 11gR2.

Per me è un'ottima notizia perché personalmente apprezzo molto Solaris come sistema operativo in ambito server. Per alcuni versi Solaris sta ai sistemi operativi come Oracle sta ai database.

Le strategie Oracle per Solaris e soprattutto per l'hardware x86 sono chiare e più che condivisibili: si stanno delineando due livelli di utilizzo del database, un low-end (Linux) e un high-end (Solaris), con relative prevedibili differenze di prezzo.
Non dimentichiamo che la versione per Windows non si è ancora fatta vedere, e che tradizionalmente la versione per Solaris x86 è stata fra le più trascurate.
A mio parere l'importante è non perdere il grande patrimonio architetturale di Sun.

Dovrò ritagliarmi un sabato o domenica piovosa per aggiornare il mio server di casa.

La storia di btrfs

2009-11-19T22:40:00.000+01:00

Segnalo questo interessantissimo articolo su btrfs, il filesystem ispirato anche a ZFS, creato da Oracle e ormai parte del kernel Linux, sebbene ancora in pieno sviluppo.

Fra le caratteristiche principali, il copy-on-write, gli snapshot anche scrivibili, la transazionalità.

Mi ero occupato di btrfs già in passato, ma ora la situazione si è evoluta talmente che Linus Torvalds lo usa come filesystem in uno dei suoi laptop.

OS Watcher

2009-11-15T08:47:00.001+01:00

Ho scoperto da qualche giorno OS Watcher, un tool del "center of expertise" della Oracle, perché ho dovuto utilizzarlo per indagare su un problema di allocazione di memoria. In realtà mi è stato richiesto dal supporto Oracle, perché personalmente non avevo dubbi sulle performance, ma solo su un potenziale memory leak. Il dubbio è che OS Watcher sia diventato un po' il tool che viene fatto girare a chiunque si rivolga al supporto, indipendentemente dal suo problema specifico.

OS Watcher è una collezione di script di shell che utilizza gli strumenti Unix per controllare e registrare ciò che accade a livello di sistema operativo, in modo da aiutare il DBA a identificare eventuali problemi che gli sfuggono e che stanno tra il database e l'hardware.

L'installazione è semplicissima: basta scompattare l'archivio osw3b.tar scaricato da MOS, entrare nella directory osw e avviare la raccolta dei dati con (esempio):

$ nohup ./startOSW.sh 60 10

dove il primo parametro è il tempo di sampling in secondi, e il secondo parametro è la retention policy dei dati in ore. La linea di comando che ho riportato quindi imposta il campionamento una volta al minuto e cancella i file dei dati campionati più vecchi di 10 ore. Non serve nemmeno il "&" finale perché lo script fa ritornare immediatamente il prompt. nohup serve ad evitare che, uscendo dalla shell, venga fermato il processo principale.
Per fermare il monitor basta eseguire:

$ ./stopOSW.sh

Lo script rileva automaticamente la presenza e l'accessibilità delle utility Unix per il controllo del sistema come vmstat e top, crea una directory archive e vi immagazzina i dati.

Dall'ultima versione del 2009 OS Watcher viene distrubuito con OSWg, un'utility Java che visualizza graficamente i dati registrati.

OS Watcher risulta comunque utile a tutti, indipendentemente dall'utilizzo del database Oracle.

Vedere anche la nota MOS 301137.1

Novità in Clusterware 11.2

2009-11-06T22:39:00.000+01:00

Nella release 2 di Oracle 11g sono stati fatti enormi cambiamenti per quanto riguarda il sottosistema di clustering, specialmente per quanto riguarda chi installa il cluster su macchine vuote e utilizza ASM come storage per il database (esempio chi utilizza standard edition). Infatti, esclusi coloro che fanno un'upgrade e coloro che intendono utilizzare un cluster filesystem per i datafile (e che quindi hanno enterprise edition), ASM diventa una scelta quasi obbligatoria; secondo me anche la migliore in assoluto.
Le novità riguardano soprattutto OCR e voting-disk: utilizzando ASM, non c'è più bisogno di due raw partitions per ospitarli, bensì Grid Infrastructure li immagazzina come file all'interno di ASM.

Nel filesystem di ASM si trova, oltre che al nome univoco del database in standard OFA, anche la directory del cluster (es. test-cluster), contenente l'SPFILE di ASM e l'OCR, chiamato REGISTRY.*.* in standard OFA. Il nome del cluster viene dato in fase di installazione.

Il numero dei voting disk dipende dalla redundancy del diskgroup di ASM: se la redundancy è external, si può avere solo un voting disk, se è normal fino a 3, se è high fino a 5.
In aggiunta, sembra che il voting disk venga salvato solo su uno dei dischi che compongono il disk group, come è visibile dalla "query" seguente su un disk group multidisco:

$ crsctl query css votedisk
##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
1. ONLINE   17a34e19b0e04ff0bf6b161d8ec83efc (ORCL:ASMDISK1) [DGDATA]
Located 1 voting disk(s).

mentre l'OCR sembra più "normale":

ASMCMD [+DGDATA/test-cluster/OCRFILE] > ls -l
Type     Redund  Striped  Time             Sys  Name
OCRFILE  UNPROT  COARSE   NOV 05 22:00:00  Y    REGISTRY.255.699705373

La documentazione dice chiaramente che, con Clusterware 11.2, non è più necessario fare il backup dei voting disk, poiché la loro gestione è automatica, backup compresi.

11gR2: alcune novità nei parametri di init

2009-10-18T11:19:00.000+02:00

Ecco una rassegna dei più interessanti parametri di inizializzazione di un istanza 11gR2. Alcuni sono nuovi, altri esistevano già in 10gR2 ma sono stati modificati nel comportamento o nei valori.

audit_trail - default: DB. Una volta era NONE, quindi se non si abilitava subito bisognava poi riavviare l'istanza.

db_block_checksum - default: TYPICAL; vengono introdotti nuovi valori: OFF, FALSE, TYPICAL, TRUE, FULL, dove TRUE e FALSE sono rimasti per compatibilità.

db_file_multiblock_read_count - default:128. La documentazione dice che 1 MB per il multiblock read è un valore standard, quindi con blocchi da 8K bisogna usare 128. Per OLTP consiglia da 4 a 16 (vecchio default). Siccome serve ad evitare di leggere troppi blocchi per un solo I/O e quindi fare flooding della buffer cache, se si ha tanta RAM è leggermente meno significativo. Il suo valore influisce nel costo dei tablescan.

db_securefile - default: PERMITTED. controlla il comportamento di default del db al momento di creare i LOB.

deferred_segment_creation - default: TRUE; nuova feature 11g, non crea i segmenti finché la prima riga non viene inserita nel database. Tradizionalmente, quando si creano tabelle o indici, viene allocato almeno il primo extent (a meno di indicazioni contrarie). Con 11g è possibile ritardare la creazione degli extent e quindi l'occupazione su disco finché il primo dato non viene scritto nella tabella.

sec_case_sensitive_logon: TRUE; da 11g il default è avere password case-sensitive per l'accesso al database.

Oracle DBA Italia

2009-10-14T08:33:00.000+02:00

Da oggi è online il nuovo sito della comunità dei DBA Oracle in Italia, http://www.dbaitalia.org/.

Il sito, senza alcun fine di lucro, è stato concepito per aggregare i DBA italiani in un luogo virtuale indipendente, in cui ciascuno può contribuire come meglio crede partecipando al forum, inviando articoli e inserendo nuove FAQ.

Invito tutti i DBA a iscriversi e a contribuire in uno spirito collaborativo :-)

Suggerimenti, critiche e commenti sono i benvenuti!
È probabile che il sito richiederà continui aggiornamenti sia estetici che soprattutto di funzionalità e contenuti, quindi ogni collaborazione sarà gradita.

Lancio di 11gR2 ieri a Milano

2009-09-24T22:39:00.000+02:00

Ieri sono stato al lancio di Oracle 11gR2 all'hotel Hilton a Milano. Speravo di incontrare qualche DBA del gruppo Oracle DBA Italia di Facebook, ma non è stato così, nonostante le sale fossero affollate.

Con grande piacere ho conosciuto Alberto Dell'Era, di cui ho letto spesso articoli interessantissimi su Oracle. Ho scoperto solo ieri che ha aperto anche un blog.
Ho parlato con Alberto a proposito di un sito aggregatore di riferimento per tutti i DBA italiani, in italiano, in modo da raccogliere anche le sue impressioni. A parte le divergenze, siamo d'accordo che ci vorrebbe una maggiore adesione ed entusiasmo da parte degli altri DBA.

Nonostante io abbia seguito per quanto possibile tutti gli annunci all'uscita di 11gR2, mi ero perso una strana e inusuale novità in Oracle Exadata 2: Hybrid Columnar Compression. Oracle sta passando ai database "colonnari"? Anche Kevin Closson se n'è occupato, e sembra che la versione Oracle abbia qualche feature in più (da ciò l'espressione "ibrida").

Da provare assolutamente la edition-based redefinition, che promette di aggiornare gli oggetti del db in modo trasparente durante una upgrade dell'applicazione. In pratica non si avrà più downtime per gli aggiornamenti. Le "edizioni" sono definibili a livello di database.

Ho visto una slide sul RAC one-node, in pratica un licensing particolare per cui si costruisce un RAC a due nodi in cui c'è sempre al massimo un'istanza attiva, mentre sull'altra macchina ci sono attive tutte le componenti RAC tranne l'istanza. È in ultima analisi un cluster attivo/passivo controllato da clusterware. A quanto ho capito ha anche il difetto(ne) di esistere solo per enterprise edition.

Un ottimo utilizzo del nuovo cluster filesystem ACFS è come ORACLE_HOME condivisa. Nel caso di upgrade della home, è anche possibile utilizzare la funzione di snapshot per poter eventualmente tornare indietro all'occorrenza, solo però per quanto riguarda i file binari, non per il db.

Le idee in casa Oracle non mancano. Vi aggiornerò prossimamente sulle prove di Grid Infrastructure 11gR2 che ho appena ultimato.

Colonne correlate in 11g

2009-09-15T22:09:00.000+02:00

In passato avevo già affrontato il problema delle colonne correlate e il sampling dinamico come soluzione alternativa.

In 11g, mediante una nuova modalità di raccolta delle statistiche, è possibile specificare dei gruppi di colonne su cui misurare la correlazione, in qualche modo un'estensione del concetto di distribuzione poco uniforme dei dati (skewness).

Facciamo un esempio più generale di quello fatto in passato, dove la correlazione è meno evidente. Nell'esempio del post sul sampling dinamico avevo utilizzato due colonne con valori uguali per ogni riga, mentre ora utilizzo un caso più reale: immaginiamo di avere tre gruppi di valori, il primo di valori attorno a 1000, il secondo attorno a 2000, il terzo attorno a 3000:

SQL> desc correl
 Name                Null?    Type
 ------------------- -------- --------------
 TAG                 NOT NULL VARCHAR2(16)
 VAL                 NOT NULL NUMBER(38)

SQL> insert into correl select 'TIPO1', 1000+TRUNC(DBMS_RANDOM.VALUE(0,100)) from all_objects;

61122 rows created.

SQL> select * from correl where rownum < 10;

TAG                     VAL
---------------- ----------
TIPO1                  1035
TIPO1                  1012
TIPO1                  1003
TIPO1                  1090
TIPO1                  1070
TIPO1                  1061
TIPO1                  1004
TIPO1                  1020
TIPO1                  1032

9 rows selected.

SQL> insert into correl select 'TIPO2', 2000+TRUNC(DBMS_RANDOM.VALUE(0,100)) from all_objects;

61122 rows created.

SQL> insert into correl select 'TIPO3', 3000+TRUNC(DBMS_RANDOM.VALUE(0,100)) from all_objects;

61122 rows created.

SQL> commit;

Commit complete.

A questo punto prendiamo le statistiche standard e vediamo che l'optimizer, per un valore qualsiasi (e non esistente) all'interno del range max-min della colonna, prevede che ci siano 204 righe:

SQL> exec dbms_stats.gather_table_stats(user, 'CORREL', estimate_percent=>100);

PL/SQL procedure successfully completed.

SQL> explain plan for select * from correl where tag = 'TIPO2' and val = 1200;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 469411154

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |   204 |  2040 |   141   (4)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| CORREL |   204 |  2040 |   141   (4)| 00:00:02 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("VAL"=1200 AND "TAG"='TIPO2')

13 rows selected.

Ma ora prendiamo le statistiche utilizzando i gruppi di colonne:

SQL> exec dbms_stats.gather_table_stats(user, 'CORREL', method_opt => 'FOR COLUMNS (TAG,VAL) SIZE SKEWONLY', estimate_percent => 100);

PL/SQL procedure successfully completed.

SQL> explain plan for select * from correl where tag = 'TIPO2' and val = 1201;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 469411154

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |   611 |  6110 |   141   (4)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| CORREL |   611 |  6110 |   141   (4)| 00:00:02 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("VAL"=1201 AND "TAG"='TIPO2')

13 rows selected.

È evidente che ora le cose vanno molto meglio: la stima dell'optimizer è di 611 righe, anche se non esistono righe per cui il valore val è 1201.

Ma il grande vantaggio è che ora la stima di circa 600 righe è valida per i numeri esistenti:

SQL> explain plan for select * from correl where tag = 'TIPO2' and val = 2023;

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 469411154

----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        |   611 |  6110 |   141   (4)| 00:00:02 |
|*  1 |  TABLE ACCESS FULL| CORREL |   611 |  6110 |   141   (4)| 00:00:02 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("VAL"=2023 AND "TAG"='TIPO2')

13 rows selected.

SQL> select count(*) from correl where tag = 'TIPO2' and val = 2023;

  COUNT(*)
----------
       645

1 row selected.

Probabilmente con qualche intervento sull'istogramma del gruppo di colonne è possibile correggere anche la stima errata dovuta alla distribuzione molto disuniforme dei numeri nella colonna val.

Oracle Exadata versione 2

2009-09-15T21:45:00.002+02:00

Ieri sera Larry Ellison in persona ha presentato la versione rinnovata della sua Database Machine, battezzata Oracle Exadata version 2. È molto interessante che l'hardware usato sia completamente Sun su Intel.

Ho guardato la presentazione in diretta, ma più che una serie di elogi al prodotto e un elenco di fattori di performance (2x, 4x, 10x, 30x ecc.) affibbiato a ciascuno dei componenti, non ho sentito molti dettagli tecnici.
La novità più rilevante è sicuramente la tecnologia FlashFire, in sostanza una cache intelligente a livello di storage server. I database server tengono in considerazione la presenza della cache al momento di elaborare il piano di esecuzione delle query.

È stato detto più volte che Oracle Exadata versione 2 è la macchina più veloce mai costruita, sia come datawarehousing che (udite udite) per OLTP! Bisogna trovare qualcuno disposto a spendere un bel po' per portarsela a casa.

Aggiornamento 22-9: da oggi è disponibile il webcast qui.

Alcune novità dell'optimizer 11g

2009-09-09T21:44:00.000+02:00

In 11g ci sono diverse novità per quanto riguarda il cost-based optimizer:

Null-aware anti-join: interessante per me perché l'ho affrontato qualche giorno fa. Quando si ha una query del tipo:
```
SELECT... FROM T1 WHERE T1.X NOT IN (SELECT T2.Y where...);
```
e T2.Y è una colonna che può assumere valori nulli, 10g e precedenti possono utilizzare un piano di esecuzione che porta a un eccesso di consistent gets (sostanzialmente CPU), e quindi a una query molto lenta. In 11g è invece possibile l'anti-join.
Consiglio l'ottimo articolo di Greg Rahn per chi volesse approfondire l'argomento.

Join Predicate Pushdown: quando c'è una join tra una tabella e una view, la condizione di join (esempio T.X = V.Y) viene computata direttamente con la tabella nella view che contiene la colonna: T.X = TV.Y. In questo modo si sfruttano eventuali indici presenti, anche con view che contengono group by, distinct e join

Spostamento del group by: nel caso di una join con group by, l'optimizer è in grado di spostare il group by e la funzione di gruppo all'interno di una view, che permette di ridurre le righe su cui fare la join.

Eliminazione dei DISTINCT: l'optimizer analizza i vari blocchi di cui è formata una query, ed elimina i DISTINCT ove possibile.

Per molti versi sembra che tutte queste ottimizzazioni siano volte ad evitare rallentamenti dovuti ai più comuni errori di programmazione.

Nuovi processi di background in 11g

2009-09-07T21:20:00.000+02:00

Oracle 10g ci aveva abituato ad una proliferazione di processi di background, specialmente riguardo a RAC, ma 11g batte tutti e introduce tutta una serie di processi dedicati ai compiti più fantasiosi:

DBRM (database resource manager) imposta le risorse del Resource Manager

DIA0 (diagnosability process) risolve i deadlock e rileva i blocchi

EMNC (event monitor coordinator) gestisce eventi e notifiche

FBDA (flashback data archiver process) archivia i dati storici delle tabelle per cui viene attivato il flashbak archive e mantiene l'archivio

GTX0-j (global transaction) permette le transazioni globali distribuite (XA) in ambiente RAC. Attualmente le transazioni XA sono possibili solo su un unico nodo per client

GMON gestisce i dischi nei diskgroup ASM

KATE gestisce l'I/O di un disco ASM che è andato offline per qualche motivo

MARK marca come invalide le unità di allocazione scritte su dischi ASM che sono andati offline

SMCO (space management coordinator) gestisce l'allocazione e la deallocazione dello spazio su disco in maniera proattiva

VKTM (virtual keeper of time) mantiene l'orologio di riferimento, che viene aggiornato ogni secondo

Col tempo ci sarà occasione di approfondire i compiti dei nuovi processi.

Lancio di 11gR2 a Milano il 24: ci vediamo?

2009-09-02T22:55:00.000+02:00

Giovedì 24 settembre si terrà a Milano un evento per il lancio di Oracle 11g release 2.

Io ci sarò; se qualcuno di voi ci sarà, potrebbe essere un'occasione per incontrarsi, fare conoscenza e scambiare qualche opinione.
Lasciate i vostri messaggi nei commenti, così ci si trova più facilmente.

Si preannunciano interessanti le discussioni aperte con i beta-tester dalle 11 alle 12 e le sessioni pomeridiane che ricapitolano le nuove feature.

11gR2 Generally Available

2009-09-02T11:04:00.003+02:00

È uscita oggi la release 2 di Oracle 11g.

Se ha le stesse novità che aveva 10gR2 rispetto alla R1, si preannunciano interessanti prove e confronti.

Aggiornamento 15:09: I primi requirements per l'installazione si trovano nei documenti Metalink 880936.1 (32 bit) e 880989.1 (64 bit).

Ora Clusterware è diventato Grid Infrastructure? :-)

Particolarità del mirror ASM

2009-08-30T22:03:00.000+02:00

Recentemente ho voluto utilizzare ASM su un vecchio server single-instance con 8 dischi SCSI di vecchio tipo da 18 GB; tutto sommato il server se la cava, avendo 4 processori e 8 GB di RAM.
Visto che il server non è di front-end, e nonostante fosse equipaggiato con un controller SCSI RAID, ho voluto ugualmente affidare ad ASM la gestione del mirror, confidando nella maggiore efficienza di ASM nel massimizzare le prestazioni con uno storage multidisco.

In seguito alla configurazione in normal redundancy, che consiste nella memorizzazione di due copie di ogni extent su due dischi diversi, rileggendo meglio il manuale mi sono accorto di un paio di piacevoli "effetti collaterali" del mirroring "intelligente" di ASM.
Consideriamo ad esempio il caso di 8 dischi: se si rompe un disco ASM automaticamente copia tutti gli extent persi sugli altri dischi disponibili, partendo dalle copie degli extent presenti, ottenendo un array di 7 dischi che... è ancora in normal redundancy! E la redundancy viene mantenuta fino a che c'è spazio disponibile sui dischi rimanenti per ospitare tutti gli extent necessari al database; virtualmente si potrebbe eliminare un disco alla volta, attendendo la risincronizzazione, fino ad avere solo due dischi e ancora mirroring; o anche un solo disco, senza più redundancy, ma con tutti i dati sempre disponibili.
Come corollari deriviamo che, per prima cosa, è possibile costruire un array con mirroring semplice con un numero qualsiasi di dischi (maggiore di 1); secondo, perde significato il disco di "hot-spare", sostituito dallo spazio libero residuo su ogni disco.
Decisamente molto più efficiente rispetto ai sistemi di storage normali.

Casualmente, poi, i dischi che compongono l'array sono di capacità identica ma di diverse prestazioni. Ciò si riflette anche nelle misure di prestazioni fatte internamente da ASM.
Nell'immagine seguente si può notare come ASM riesca a massimizzare le prestazioni utilizzando maggiormente i dischi più veloci, sia a causa della latenza che del throughput.

Estate, mare e Oracle

2009-08-26T22:02:00.000+02:00

La parte più "vivace" dell'estate è ormai alle spalle, ma concediamoci qualche altro momento di svago con un video HD di BMW Oracle Racing Technology. Altrimenti si diverte solo Larry con questi "giocattoli".
Chissà se tutti quei dati raccolti, di cui si parla nel video, vengono immagazzinati in un database Oracle, e chissà dove si trova :-)

A presto per i nuovi post!

Le novità di ASM in 11g

2009-06-24T22:52:00.000+02:00

La versione 11g di ASM include alcuni miglioramenti interessanti.

Comando CP: finalmente è possibile copiare i file da e verso lo storage ASM, come del resto qualsiasi processo server di Oracle può fare da sempre. La differenza è che si usa il comando CP da linea di comando ASDCMD o da linea di comando della shell come parametro di ASMCMD.

Fast Mirror Resync: in seguito a temporanee indisponibilità di un disco ASM contenente copie di dati mirrorati, la risincronizzazione avviene tenendo conto dei dati già presenti sul disco, evitando quindi la ricostruzione completa del mirror. ASM in pratica tiene traccia degli extent da aggiornare e al resync copia solamente quelli. È stato introdotto il parametro DISK_REPAIR_TIME, che definisce un periodo trascorso il quale il disco non disponibile viene ricostruito per intero.

Extent di dimensioni variabili: con 11g è possibile definire la dimensione degli extent, ovvero le unità di allocazione con cui viene riservato lo spazio per i file nello storage ASM. Nelle versioni precedenti questa dimensione era fissa e pari a 1 MB per i file "normali" e 128 KB per i file ad alto I/O rate. I 128 KB rimangono anche in 11g. Una conseguenza immediata è che aumenta ancora la quantità totale di dati che si possono immagazzinare nel database, potendo disporre di datafile più grandi.

Hugepages in RHEL5

2009-06-07T21:09:00.000+02:00

Abbiamo visto, in un post precedente, come sia possibile per Oracle allocare una buffer cache molto grande, fino a 62 GB, su un sistema Linux a 32 bit.

La buffer cache viene sostanzialmente allocata come un file su un filesystem di tipo ramfs, e l'accesso ai blocchi in memoria avviene in maniera indiretta.

Facciamo un passo indietro. La memoria nei sistemi a memoria virtuale (ad esempio Linux) viene allocata tramite pagine di 4 KB mappate sulla memoria fisica da una tabella di lookup locale che referenzia una tabella di lookup di sistema, la quale punta finalmente alla memoria fisica.

Le hugepage sono pagine di dimensione molto maggiore di quella standard. Nel caso di RHEL5 ho verificato una dimensione di 2 MB (almeno 500 volte la dimensione standard):

$ grep Huge /proc/meminfo 
HugePages_Total:   821
HugePages_Free:    558
HugePages_Rsvd:    555
Hugepagesize:     2048 kB

Le hugepage vengono allocate al boot tramite un parametro del kernel, in modo da riservare un numero di porzioni contigue di RAM sifficienti ad allocare la quantità di hugepage richieste, altrimenti la RAM viene allocata in pagine da 4 KB (il default). Inoltre le hugepage non sono swappabili; in linguaggio Oracle si potrebbero considerare pinned.
In generale quindi, per allocare quantitativi di RAM molto grandi e mantenere le tabelle di lookup a dimensioni accettabili, si possono usare le hugepage.

La relazione tra ramfs e hugepage è che le pagine allocate su ramfs sono appunto hugepage.

Se avete provato, come ho fatto io, a usare ramfs per la buffer cache, vi sarete accorti che solo la buffer cache va a finire su ramfs, mentre la shared pool finisce nella classica shared memory. Per controllare l'allocazione della shared memory basta utilizzare ipcs:

$ ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0xb0af65c0 1081347    oracle    600        85983232   11                      
0xb6c83f68 1114116    oracle    600        1629487104 26                      
0x00000000 1146885    oracle    640        4096       0

Come si può vedere l'utente oracle ha allocato 2 segmenti "grandi" di shared memory: la seconda è la shared pool, impostata a 1504 MB, mentre l'altra è la SGA dell'istanza ASM che gestisce i dischi sulla stessa macchina, mentre non compare la buffer cache.
Le 821 hugepage da 2 MB sul mio sistema di esempio servono ad ospitare la shared pool e la SGA dell'istanza ASM come viene riportato da ipcs.

Le hugepage non sono utili solo nei sistemi a 32 bit. Vedremo le applicazioni nel prossimo post.

Very Large Memory su RHEL5

2009-05-26T23:10:00.000+02:00

Ovvero: come fregare il kernel Linux a 32 bit e fare indirizzare a Oracle più di 4 GB di RAM.

Ho appena finito di configurare un antico sistema con processori Intel del 2001, irrimediabilmente limitati a 32 bit e di conseguenza a indirizzare non più di 4 GB di RAM.
Se poi si conta che il kernel Linux si riserva 1 GB di RAM per gli affari propri, in tutto rimane solo circa 1.7 GB di RAM per la SGA (2.7 GB con i kernel "enterprise" e 10gR2 senza relink particolari). Con i kernel "enterprise" di Red Hat, invece, detti hugemem kernel, è possibile indirizzare 4 GB per processo e in totale fino a 64 GB di RAM (!).

Ma se, parafrasando Doc di "Ritorno al Futuro", riuscissimo a installare 8 GB di RAM sul nostro server, potremmo poi utilizzarli effettivamente con Oracle? La risposta è sì, tramite l'utilizzo del supporto per la Very Large Memory.

Il trucco principale è l'utilizzo di un filesystem per la buffer cache di Oracle (attenzione: non la SGA globalmente, solo la parte a blocchi). Il filesystem è /dev/shm, che è montabile tramite i tipi di filesystem shmfs e tmpfs, oppure col più recente ramfs; la differenza con i primi due tipi è che, mentre per il primo bisogna specificare le dimensioni e per il secondo no, l'ultimo tipo non è swappabile. Fate un df dalla vostra console Linux e probabilmente vedrete montato un filesystem dei tipi che ho appena elencato.

L'istanza Oracle accede a /dev/shm mediante il parametro use_indirect_data_buffers=true allocando alla partenza un file delle dimensioni della buffer cache. Molto importante è notare che, in questo caso, non è più possibile utilizzare l'allocazione automatica delle componenti della SGA e nemmeno cache a blocchi di dimensioni differenti dallo standard predefinito per il database (solitamente 8 KB), quindi bisogna per forza usare il vecchio parametro db_block_buffers e rinunciare ad alcune delle caratteristiche importanti di 9i e 10g.
Ecco un esempio con una buffer cache di 2500 MB:

$ ls -l /dev/shm/
total 2560000
-rw-r----- 1 oracle dba 2621440000 May 25 04:56 ora_BIGGIE_1146885

Legato a questa feature è l'utilizzo delle hugepage, su cui sto ancora indagando e di cui mi occuperò nei prossimi post.

L'acquisizione di MySQL vista da Widenius

2009-05-18T23:03:00.000+02:00

Michael "Monty" Widenius, il principale autore di MySQL, ci illustra con un post del suo blog la sua opinione a proposito dell'acquisto di Sun da parte di Oracle, evidenziandone le motivazioni ed elencando le possibili decisioni di Oracle sul futuro di MySQL.
La sua preoccupazione maggiore ora è di mantenere MySQL libero, prevedendo che Oracle difficilmente riuscirà a trattenere i migliori sviluppatori MySQL rimasti dopo l'acquisizione. Widenius cerca ora di riunire sotto un unico consorzio, chiamato Open Database Alliance, tutte le aziende piccole che hanno anche fare con MySQL e che rimangono nell'ambito open-source.

A mio parere Widenius sottovaluta l'esperienza di Oracle nell'open-source: basti pensare anche solo a OCFS2, Enterprise Linux, btrfs. Bisognerà comunque attendere le prossime mosse di Oracle.

ZFS: ancora novità a manetta

2009-05-10T23:02:00.000+02:00

Lo sviluppo di ZFS continua a sorprendermi: basta attendere qualche mese ed escono delle novità che si potrebbero definire stupefacenti per qualcosa che è "solo" un filesystem.
In ambiente Solaris le novità tecnologiche si possono provare solo in OpenSolaris, che è la versione free ma anche più avanzata di Solaris.

Ecco le ultime novità su ZFS:

Snapshot automatici: necessari in realtà per la feature di time-slider di OpenSolaris.

Cache devices: è possibile introdurre un ulteriore livello di cache a disco aggiungendo ai pool dei device che hanno la sola funzione di contenere dati perlopiù a sola lettura. Ciò può aumentare le prestazioni per sistemi a lettura casuale. È interessante che il filesystem stesso decide quali blocchi devono stare in cache e quali no; ZFS ha sicuramente una maggiore cognizione di causa sulla natura dei dati in transito rispetto alla cache del controller. Potenzialmente vengono divise le attività di sola lettura da quelle di scrittura; ciò potrebbe eliminare una eventuale contesa di risorse (le meccaniche dei dischi) in due operazioni molto diverse tra loro, costituendo un enorme vantaggio per molti ambienti.

Log del filesystem (ZIL) su device separati: l'intent log di ZFS può essere allocato su device diversi dai dischi che compongono lo storage pool. Per i database è interessante poiché si possono usare dei device molto veloci e di capacità (e costo) limitata per la scrittura sincrona dei dati, tipicamente le chiamate sync() durante la scrittura dei redo log. Questa non è propriamente una novità di per se, ma non ne ho mai fatto menzione.

L'elenco esteso di tutte le novità è reperibile nella pagina apposita del manuale.

Ora come resistere al Mac?

2009-05-07T13:51:00.000+02:00

Da ieri è possibile scaricare dal sito Oracle la versione Mac OS X a 64 bit di Oracle 10.2.0.4.

Non so più quale scusa inventarmi per non comprare un Mac nuovo.

A questo punto è probabile che, in futuro, venga rilasciata anche la versione Mac di 11g.

Split-mirror istantaneo con ZFS

2009-05-03T21:19:00.001+02:00

Lo scorso ottobre avevo scritto un post sul backup istantaneo con ZFS.
Riprendo quel discorso per estenderlo con le funzionalità aggiuntive fornite da RMAN: tramite RMAN è infatti possibile registrare la copia di backup del datafile, facendola entrare nel catalogo e quindi averla disponibile per qualsiasi tipo di recovery.

RMAN> SQL 'ALTER TABLESPACE USERS BEGIN BACKUP';

$ sudo zfs snapshot u02/oradata@mysnap

Dopo avere effettuato lo snapshot, cataloghiamo la copia del datafile:

RMAN> SQL 'ALTER TABLESPACE USERS END BACKUP';

RMAN> CATALOG DATAFILECOPY '/u02/oradata/.zfs/snapshot/mysnap/MICKEY/users01.dbf';

A questo punto abbiamo una copia recoverable del tablespace in un determinato istante; se vogliamo quindi effettuare modifiche importanti sui dati contenuti in quel tablespace, possiamo considerare lo snapshot praticamente un backup logico, utile nel caso di errore umano. In questo caso i dati in esso contenuti sono recuperabili mediante point-in-time recovery (con EE).
Per il resto, invece, lo snapshot è una copia di backup.

RMAN> list copy of tablespace users;

using target database control file instead of recovery catalog

List of Datafile Copies
Key     File S Completion Time Ckp SCN    Ckp Time        Name
------- ---- - --------------- ---------- --------------- ----
1       4    A 31-MAR-09       403343     31-MAR-09       /u02/oradata/.zfs/snapshot/mysnap/MICKEY/users01.dbf

Mettiamo offline il tablespace:

SQL> alter tablespace users offline normal;

Da RMAN facciamo il restore usando lo split-mirror:

RMAN> restore tablespace users;

Starting restore at 01-MAY-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=202 devtype=DISK

channel ORA_DISK_1: restoring datafile 00004
input datafile copy recid=1 stamp=682952952 filename=/u02/oradata/.zfs/snapshot/mysnap/MICKEY/users01.dbf
destination for restore of datafile 00004: /u02/oradata/MICKEY/users01.dbf
channel ORA_DISK_1: copied datafile copy of datafile 00004
output filename=/u02/oradata/MICKEY/users01.dbf recid=2 stamp=685963392
Finished restore at 01-MAY-09

SQL> alter tablespace users online;
alter tablespace users online
*
ERROR at line 1:
ORA-01113: file 4 needs media recovery
ORA-01110: data file 4: '/u02/oradata/MICKEY/users01.dbf'

SQL> recover tablespace users;
Media recovery complete.
SQL> alter tablespace users online;

Tablespace altered.

In seguito, quando non ci servirà più il mirror, lo rimuoviamo dal catalogo e cancelliamo lo snapshot ZFS:

RMAN> CHANGE DATAFILECOPY '/u02/oradata/.zfs/snapshot/mysnap/MICKEY/users01.dbf' UNCATALOG;

$ sudo zfs destroy u02/oradata@mysnap

Questo discorso può essere esteso a tutto il database con alter database begin backup (10g). Il backup (o meglio lo snapshot) di database molto grandi diventa quindi un'operazione di pochi secondi, salvo poi copiare le copie dei datafile su altri supporti per altri utilizzi.

Sun difende Solaris rispetto a Linux

2009-04-28T22:51:00.000+02:00

Segnalo un interessante whitepaper di Crimson consulting group, dove viene presentato un confronto di esperienze tra utenti enterprise sia di Solaris 10 che di Red Hat Linux, che abbiano numeri "importanti" in termini di fatturato e di parco macchine. Il paragone stato fatto solo su piattaforma x86, dove RHEL è maggiormente affermata.

Gli analisti affermano che Solaris batte Red Hat Linux su costi di acquisizione, supporto, amministrazione, mentre è uguale nei costi di implementazione (installazione).
Essi cercano di dimostrare che, sebbene i costi iniziali sembrino a favore di Linux, a lungo termine ciò perde importanza e non è più vero: alla lunga i costi di RHEL, oltre che a essere più elevati, aumentano anche più rapidamente.

Viene menzionata la necessità di acquistare software aggiuntivo come VMware (opposto ai Containers di Solaris), Veritas (invece di ZFS), supporto per fiberchannel. Viene affermato che il costo del supporto, anche per software terzi, è decisamente maggiore per RHEL. Anche il numero di persone specializzate (sysadmin) viene considerato, come anche la differente difficoltà di amministrazione a livello di singolo server.
Un aspetto interessante è la compatibilità binaria tra differenti release dei sistemi operativi, che è garantita per Solaris. Solaris è inoltre meglio integrato con Java (per evidenti motivi).

Non ho elementi solidi a sostegno delle tesi presentate nella whitepaper, che comunque è una buona lettura per informarsi maggiormente, anche se a mio parere è leggermente di parte.
In più la diffusione di questa pubblicazione, che segue di poche ore l'annuncio dell'acquisizione di Sun da parte di Oracle, sembra un tentativo dell'ultimo momento per tentare di affermare le proprie ragioni e tutelare il proprio patrimonio tecnologico, in vista di probabili interventi sui sistemi operativi da parte di Oracle.

Oracle acquisisce Sun

2009-04-20T13:58:00.003+02:00

Oracle ha raggiunto un accordo per l'acquisizione di Sun.

Sui rispettivi siti (Oracle e Sun) ci sono le notizie.

Continuerà lo sviluppo di ZFS?
Alla fine anche la parte residua di MySQL viene acquisita da Oracle.

Oracle ha ora la possibilità di fornire uno stack tecnologico completo, dall'applicazione al disco.

Prova delle novità in OpenSolaris 200811

2009-04-01T22:42:00.000+02:00

Con le novità di OpenSolaris 10 200811 le possibilità di gestione dei database Oracle (e non) si moltiplicano e si aprono nuovi scenari di utilizzo.

La novità più divertente è il Time Slider, che può apparire come un gadget invero molto utile ma per PC desktop e notebook, invece si rivela interessantissimo per i DBA, come vedremo presto con la prova con Oracle.

Ora il desktop di Solaris 10 deve sembrare molto simile a quello che avevano in mente alla Apple prima dell'introduzione di Time Machine. Visto che era in previsione l'adozione di ZFS come filesystem universale, cosa che poi non si è verificata, è intuibile che Time Machine sia stato lo sviluppo naturale di un sistema di versioning per i file che sostituisse le immense potenzialità di ZFS, senza però adottarne la tecnologia. I limiti derivanti da questa scelta sono del tutto accettabili per l'utente desktop, ma non per l'utente enterprise.

Time Slider si può impostare tramite il menù System-Administration:

dove si può decidere di quali filesystem (alla ZFS) vengono fatti gli snapshot.
Una volta scelto il default (tutti) il risultato è che viene impostato un attributo del filesystem per l'auto-snapshot:

Una novità ulteriore è lo sviluppo di soluzioni integrate per lo storage di rete SAN e NAS, raggruppate sotto il nome di COMSTAR. Tramite un server Solaris Express o Opensolaris e COMSTAR è possibile costruire una SAN a basso costo (per ora solo Fiberchannel), utilizzando ZFS come storage.
Per maggiorni informazioni su COMSTAR è meglio leggere direttamente il manuale.

Sembra che Sun "sponsorizzi" la ricerca su nuove soluzioni a basso costo tramite la comunità Open Storage.

A breve le prove con Oracle e Time Slider: stay tuned!

Inconsistenze di V$SYSMETRIC_HISTORY

2009-03-26T21:03:00.000+01:00

Il patchset 3 di Oracle 10g riserva una strana sorpresa: su alcune installazioni, specialmente RAC, si hanno delle inconsistenze in V$SYSMETRIC_HISTORY.

In V$SYSMETRIC_HISTORY viene raccolto il contenuto di V$SYSMETRIC (le metriche di sistema) ogni 15 secondi, e vengono mantenuti i dati dell'ultima ora.
Periodicamente la view viene salvata su disco in DBA_HIST_SYSMETRIC_HISTORY.

Con queste premesse, è naturale che la differenza tra sysdate (il tempo del server) e il massimo registrato nella colonna END_TIME sia al massimo di 15 secondi. Invece:

SQL> select max(end_time), sysdate from v$sysmetric_history;

MAX(END_TIME)       SYSDATE
------------------- -------------------
2009-03-12 14:06:59 2009-03-12 14:10:04

1 row selected.

Qual è la conseguenza di ciò? Càpita che i grafici di Enterprise Manager nella homepage non siano visibili, e ho l'impressione che anche altri fenomeni, come strani grafici di performance, siano collegati a questa anomalia:

Come si può vedere la parte destra del grafico viene disegnata "allungata", come se per quell'intervallo di tempo non ci fossero dati disponibili e quindi il grafico rimanesse costante, mentre sia prima che dopo tutto è regolare.

Trovate maggiori dettagli nel documento Metalink 550083.1, assieme alla descrizione del bug e alla patch relativa, se i sintomi che doveste riscontrare corrispondono a quelli descritti nei documenti Oracle.

Oracle MAA a Milano

2009-03-20T14:39:00.005+01:00

Giovedì prossimo sarò all'Oracle Maximum Availability Architecture a Milano.
Potrebbe essere un'occasione per fare due chiacchiere.
Se ci siete, lasciate un commento, così ci si dà un appuntamento per tutti.

Aggiornamento post-evento: eravamo una trentina di persone, a giudicare dai badge la metà di quelle previste. Si è parlato delle novità 11g un po' più da vicino. Abbastanza interessante, c'è discreto materiale per nuovi test, ma la scarsa partecipazione fa pensare.

Il mistero di hangcheck-timer

2009-03-11T21:10:00.000+01:00

Recentemente ho aggiornato diversi sistemi con Oracle 10g RAC a 64 bit con RHEL 5.2. In genere, ogni volta che installo un nuovo cluster, scorro velocemente per l'ennesima volta tutti i passi del manuale di installazione, per essere più o meno certo di non avere dimenticato nulla.

Stavolta mi è capitato di notare una stranezza a proposito dell'installazione di Clusterware 10g per Linux nel capitolo "Pre-installation tasks".
Oracle RAC ha bisogno di un modulo del kernel Linux chiamato hangcheck-timer, illustrato nella nota Metalink 726833.1. Questo modulo controlla che il kernel Linux non rimanga bloccato nell'attesa di un blocco (tipo I/O) per più di un determinato periodo di tempo, impostabile con alcuni parametri del modulo; in caso contrario fa il reboot del nodo per evitare lock e inconsistenze più gravi.

La cosa strana è che, controllando i parametri dell'hangcheck-timer, sono risultati diversi da quelli da me impostati su altri cluster già attivi.

Il paragrafo riporta i seguenti parametri per hangcheck-timer:

hangcheck_tick=1 hangcheck_margin=10 hangcheck_reboot=1

mentre su alcuni cluster che gestisco i valori sono i seguenti:

hangcheck_tick=30 hangcheck_margin=180

Mi è sembrato molto strano di aver sbagliato ad impostare quei parametri, specialmente inserendo dei valori precisi che evidentemente erano derivati da qualche documento ufficiale, altrimenti non li avrei messi.

E infatti, con un po' di lavoro di investigazione, anche senza l'aiuto del sito The Wayback Machine temporaneamente non funzionante, sono approdato ad una vecchia versione della pagina di installazione di Clusterware, che riportava i valori da me impostati in passato.
Tutto è confermato anche da questo articolo di OTN.

Non ho molto apprezzato questa variazione senza preavviso dei parametri, quindi ho pensato di essermi perso qualche avviso da qualche parte nel patchset 3, ad esempio.
Non ho trovato alcun riferimento alla variazione dei parametri, tranne nella nota 726833.1, che riporta per 9i i parametri hangcheck_tick=30 hangcheck_margin=180 hangcheck_reboot=1 e per 10g e 11g i valori hangcheck_tick=1 hangcheck_margin=10 hangcheck_reboot=1.

È evidente che qualcosa è cambiato nelle procedure di configurazione di RAC da una certa patchset in poi, e che i parametri nella versione originale dell'installazione erano quelli di 9i, ma non riesco a trovare riferimenti.

Qualcuno di voi ci riesce?

Ext4, le novità per i database

2009-02-24T22:43:00.000+01:00

Recentemente è uscita la versione stabile di ext4, l'evoluzione del noto filesystem di Linux ext3. Chi ha il kernel Linux 2.6.28 o superiore può provare subito le nuove feature.

Leggendo le novità introdotte non si può fare a meno di pensare all'utilizzo con i database. Alcune novità, infatti, sembrano state "ispirate" dal mondo Oracle.

Per ora l'indirizzamento di ext4 è a 48 bit, non a 64 come si potrebbe immaginare, e ciò introduce limiti che, benché difficilmente raggiungibili, sono altrettanto facilmente evitabili; è comunque prevista un'upgrade in futuro.

Molto interessante è l'introduzione degli extent, ovvero insiemi di blocchi contigui che il filesystem considera come un'unica entità, concetto preso direttamente da Oracle.
I vantaggi potrebbero essere: una maggiore velocità, allocazione dello spazio più veloce.
È presente anche la deframmentazione online, che però a mio parere è una soluzione un po' finta a un problema quasi inesistente, in quanto in storage di un certo livello, anche piuttosto basso, i dati vanno a finire in locazioni del disco logico che non hanno relazione fisica tra loro, anche se logicamente contigui. Penso che questo concetto sia alla base della relativamente bassa perdita di performance di ZFS e tutti i filesystem copy-on-write, specialmente quando utilizzati su storage multidisco.
La preallocazione permette di preallocare lo spazio su disco in modo efficiente e contiguo, come fanno ad esempio i programmi di P2P. Per utilizzare questa feature è necessario richiamare una funzione apposita dell'API glibc, quindi bisogna probabilmente attendere che il codice dei database server venga aggiornato.

Ho installato una macchina virtuale di prova con Red Hat 5.3, che dispone di una technology preview di ext4, solo in modalità "dev", quindi comunque non stabile.
Purtroppo constato che non è possibile utilizzare blocchi di dimensione superiore a 4 KB, di fatto impedendo una utile ottimizzazione nei confronti dei blocchi di database di dimensioni maggiori (tipico 8 KB nel caso di Oracle).

Ext4 può essere un significativo passo avanti nella gestione di filesystem grandi e può aiutare sia nella gestione che nella performance dei database, soprattutto Oracle, ma trovo che grandi novità strutturali non ci siano state, almeno non come quelle di ZFS, fin dal suo rilascio.

Per ZFS si preannunciano interessantissime novità, come la possibilità di tornare indietro nel tempo proprio come Time Machine della Apple.

Troveremo il tempo di approfondire tutti questi argomenti.

Grafici Google, GUI per vari database

2009-02-19T22:12:00.000+01:00

Un paio di segnalazioni.

Con Google Charts è possibile ottenere grafici utili per automatizzare il monitoraggio dei propri database.
Di seguito c'è un esempio, generato "live" col caricamento di questa pagina, che illustra l'utilizzo di un grafico per visualizzare l'occupazione relativa su disco dei vari tablespace che compongono un database Oracle:

Il grafico viene generato semplicemente chiamando un URL di Google:

http://chart.apis.google.com/chart?cht=p&chs=400x200&chtt=Database%20Tablespaces%20(MB)&chl=1960|400|250|160|100|5&chd=t:68,14,9,6,3,0&chdl=MGMT_TABLESPACE|SYSTEM|UNDOTBS1|SYSAUX|MGMT_ECM_DEPOT_TS|USERS

passandogli i valori e i tag del grafico. I valori, naturalmente, vengono ricavati da una query sul dizionario dati.
I possibili utilizzi sono limitati solo dalle proprie necessità.
(da un articolo di Alex Gorbachev)

Navicat è un programma utile per la gestione dei propri database MySQL, PostgreSQL e Oracle.
Esiste sia per Windows che per Mac OS X, in varie versioni a pagamento, ma c'è anche la versione gratuita ("Lite").
Ho fatto qualche prova e Navicat mi pare un programma molto semplice, adatto a effettuare le operazioni più comuni.
Le caratteristiche che mi paiono più interessanti sono la possibilità di confrontare schemi e la possibilità di collegarsi a un database tramite un tunnel SSH.

Il listener che ascoltava troppo

2009-01-25T22:03:00.001+01:00

Il listener, per Oracle, è il processo che rimane in ascolto su una porta di rete per le richieste di connessione remote, indirizzandole successivamente al processo server o al dispatcher opportuno.

Il listener può essere controllato tramite la sua console lsnrctl (Listener Control Utility): lo si può fare partire, spegnere e riconfigurare in vari modi, anche senza farlo ripartire, grazie al comando RELOAD.

Con il comando STATUS è possibile avere una panoramica piuttosto dettagliata su che cosa sta facendo il listener:

LSNRCTL> status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.3.0 - Production
Start Date                10-JAN-2009 13:21:16
Uptime                    12 days 22 hr. 17 min. 45 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/10.2.0/network/admin/listener.ora
Listener Log File         /u01/app/oracle/product/10.2.0/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhost)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC0)))
Services Summary...
Service "ORA10G" has 1 instance(s).
  Instance "ORA10G", status READY, has 1 handler(s) for this service...
Service "ORA10GXDB" has 1 instance(s).
  Instance "ORA10G", status READY, has 1 handler(s) for this service...
Service "ORA10G_XPT" has 1 instance(s).
  Instance "ORA10G", status READY, has 1 handler(s) for this service...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully

L'avvio o la chiusura del listener sono operazioni privilegiate, che quindi richiedono un certo livello di privilegi all'utente. Se ci si collega al server come utente appartenente al gruppo dba o addirittura come utente oracle, i privilegi per dette operazioni vengono automaticamente garantiti. Ciò è infatti visibile nella riga Security ON: Local OS Authentication.

Nelle versioni 9i e precedenti, però, generalmente il controllo di accesso alle operazioni privilegiate è disabilitato:

LSNRCTL> status
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Solaris: Version 9.2.0.7.0 - Production
Start Date                27-MAY-2008 14:45:13
Uptime                    240 days 19 hr. 51 min. 0 sec
Trace Level               off
Security                  OFF
SNMP                      OFF
Listener Parameter File
/u01/oracle/product/9207/network/admin/listener.ora
Listener Log File         /u01/oracle/product/9207/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=ora9ihost)(PORT=1521)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "ORA9I" has 1 instance(s).
  Instance "ORA9I", status UNKNOWN, has 1 handler(s) for this service...
Service "ORA9I" has 1 instance(s).
  Instance "ORA9I", status READY, has 2 handler(s) for this service...
The command completed successfully

Il problema non è rilevante per quanto riguarda gli utenti locali del server su cui risiedono il database e il listener, in quanto protetti in qualche modo da password, ma perché è possibile controllare remotamente un listener non "blindato" tramite la sua console lsnrctl installata su qualsiasi altra macchina. Esiste infatti la possibilità di specificare il current_listener; vediamolo in opera utilizzando il comando version (ma status va benissimo):

LSNRCTL> version
Connecting to
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1521)))
TNSLSNR for Linux: Version 10.2.0.3.0 - Production
        TNS for Linux: Version 10.2.0.3.0 - Production
        Unix Domain Socket IPC NT Protocol Adaptor for Linux: Version 10.2.0.3.0 - Production
        Oracle Bequeath NT Protocol Adapter for Linux: Version 10.2.0.3.0 - Production
        TCP/IP NT Protocol Adapter for Linux: Version 10.2.0.3.0 - Production,,
The command completed successfully
LSNRCTL> set current_listener ora9ihost
Current Listener is ora9ihost
LSNRCTL> version
Connecting to
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=ora9ihost))(ADDRESS=(PROTOCOL=TCP)(HOST=ora9ihost)(PORT=1521)))
TNSLSNR for Solaris: Version 9.2.0.7.0 - Production
        TNS for Solaris: Version 9.2.0.7.0 - Production
        Unix Domain Socket IPC NT Protocol Adaptor for Solaris: Version 9.2.0.7.0 - Production
        Oracle Bequeath NT Protocol Adapter for Solaris: Version 9.2.0.7.0 - Production
        TCP/IP NT Protocol Adapter for Solaris: Version 9.2.0.7.0 - Production,,
The command completed successfully

Il comando VERSION fornisce le informazioni per qualsiasi database (e già queste informazioni a disposizione di tutti potrebbero essere inopportune), ma a noi interessa che con il listener 9i non opportunamente configurato è possibile a questo punto scrivere "stop" e il listener viene spento su ora9ihost.
Per 10g invece questa "feature" viene disabilitata di default, quindi cercando di fermare il listener remotamente si ottiene:

LSNRCTL> stop
Connecting to
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=ora10g))(ADDRESS=(PROTOCOL=TCP)(HOST=ora10g)(PORT=1521)))
TNS-01189: The listener could not authenticate the user

Inoltre, con un listener "aperto", impostando log_directory, log_file e log_status si può sovrascrivere qualsiasi file accessibile all'utente con cui gira il listener a cui ci si è collegati (meglio non immaginare che cosa è possibile fare).

In 10g, per il listener è attivo di default (ON) il nuovo parametro LOCAL_OS_AUTHENTICATION_<listener>, quindi non ci si deve preoccupare più di tanto; con il parametro impostato a "OFF" il listener si comporta come su 9i. In tal caso (10g aperto, 9i e precedenti) è opportuno impostare la password per il listener con il comando CHANGE_PASSWORD.
Una volta impostata la password, per eseguire qualsiasi operazione privilegiata è necessario prima autenticarsi con SET PASSWORD.

Un'interconnect RAC efficiente

2009-01-06T11:06:00.001+01:00

Com'è noto un cluster Oracle è formato da più istanze che montano lo stesso database condiviso.
Ogni istanza ha una propria buffer cache che si gestisce autonomamente, in più esiste una caratteristica di RAC chiamata cache fusion, che sarebbe un insieme di processi che si parlano tra loro da un nodo del cluster all'altro, garantendo l'integrità dei dati attraverso le istanze.

Dato che una query, eseguita su un nodo qualunque del cluster, deve ottenere risultati consistenti, le istanze devono poter parlare tra loro tramite una connessione molto veloce, che in genere viene ottenuta tramite una rete ethernet, soprattutto per la relativa economicità della soluzione.
Le istanze trasferiscono tra loro direttamente i blocchi della SGA, che vengono quindi impacchettati secondo gli usuali protocolli di rete per essere spediti alle altre istanze del cluster. Oracle usa UDP per il trasferimento, penso soprattutto per evitare l'overhead del TCP.
La dimensione dei pacchetti trasferiti sull'interconnect è data al parametro della scheda di rete MTU, che è la dimensione in byte del più grande pacchetto o frame che può essere inviato attraverso la rete. In generale il default per tutte le interfacce di rete è 1500 byte.
Ciò implica che, trasferendo un blocco dalla SGA di un nodo a quella di un altro nodo, il blocco viene spezzettato in più frame sufficienti a contenere le sue dimensioni (es. 8K standard). Questa operazione è relativamente lenta, e poiché le prestazioni dell'interconnect possono avere un forte impatto sulle prestazioni globali del cluster, è preferibile limitare l'uso dell'interconnect, facendo in modo ad esempio che qualsiasi nodo del cluster lavori prevalentemente o unicamente su un sottoinsieme dei dati disgiunto da quello su cui lavora ciascun altro nodo.

C'è anche un modo per aumentare le prestazioni dell'interconnect: l'uso dei jumbo frame.
I jumbo frame sono dei frame (molto) più grandi di quelli standard di 1500 bytes; generalmente il limite delle loro dimensioni è 9000 bytes; questo limite è interessante perché molto vicino alle dimensioni "standard" del blocco Oracle (8K), e comunque superiore alle dimensioni dei blocchi usati in OLTP (2K, 4K, 8K).

L'idea che mi è venuta è di verificare che i blocchi transitino "intatti" sulla interconnect, in modo da massimizzare le prestazioni, al variare della MTU. Non tutte le apparecchiature di rete, infatti, supportano i jumbo frame o comunque dimensioni troppo grandi dei frame.
Il modo più diretto e anche più affidabile è usare un tool di monitoring del traffico. Io propendo per Wireshark, per la facilità e l'estrema potenza.

Il test che ho pensato è il seguente: creo una tabella 3 o 4 blocchi in un tablespace con blocksize di 8K, inserisco un po' di dati ad-hoc, "carico" il suo contenuto nella SGA dell'istanza su cui sto lavorando (una semplice select va bene, anche se l'insert ordinaria dovrebbe bastare), e poi cerco di accedere agli stessi dati da una seconda istanza del cluster (un'altra select è sufficiente).
Ipotizzo che Oracle trasferisca i blocchi in questione sull'interconnect invece che leggerli da disco, poiché si presume che il trasferimento via interconnect sia molto più veloce.

Per riconoscere i blocchi nel traffico di rete utilizzo dei "marker" sui dati: creo una tabella contenente stringhe ben visibili. In questo caso utilizzo stringhe tipo "AAAA...", "BBBB...." e così via, per 20 righe di circa 2000 caratteri ciascuna, in modo che in ogni blocco da 8192 byte ci stiano 3/4 record. "Forzo" la massima occupazione dello spazio nei blocchi utilizzando l'opzione pctfree 0.

SQL> create table aob (rn integer, rp char(2000)) pctfree 0;

Table created.

SQL> insert into aob select rownum, rpad(chr(64+rownum), 2000, chr(64+rownum))
from all_objects where rownum <= 20;

20 rows created.

SQL> commit;

Commit complete.

SQL> select rn, substr(rp, 1, 1) letter, length(rp) len, rowid
from aob order by rn;

        RN LETT        LEN ROWID
---------- ---- ---------- ------------------
         1 A          2000 AAAM8OAAFAAABCXAAA
         2 B          2000 AAAM8OAAFAAABCXAAB
         3 C          2000 AAAM8OAAFAAABCXAAC
         4 D          2000 AAAM8OAAFAAABCXAAD
         5 E          2000 AAAM8OAAFAAABCYAAA
         6 F          2000 AAAM8OAAFAAABCYAAB
         7 G          2000 AAAM8OAAFAAABCYAAC
         8 H          2000 AAAM8OAAFAAABCYAAD
         9 I          2000 AAAM8OAAFAAABCUAAA
        10 J          2000 AAAM8OAAFAAABCUAAB
        11 K          2000 AAAM8OAAFAAABCUAAC
        12 L          2000 AAAM8OAAFAAABCUAAD
        13 M          2000 AAAM8OAAFAAABCVAAA
        14 N          2000 AAAM8OAAFAAABCVAAB
        15 O          2000 AAAM8OAAFAAABCVAAC
        16 P          2000 AAAM8OAAFAAABCVAAD
        17 Q          2000 AAAM8OAAFAAABCWAAA
        18 R          2000 AAAM8OAAFAAABCWAAB
        19 S          2000 AAAM8OAAFAAABCWAAC
        20 T          2000 AAAM8OAAFAAABCWAAD

20 rows selected.

Nell'ultima select per brevità è presente solo una lettera per ogni riga (rp è una stringa char di 2000 caratteri tutti uguali); è evidente come i record stiano nello stesso blocco a gruppi di 4 dal rowid: la riga all'interno del blocco è indetificata dagli ultimi tre caratteri del rowid, mentre il blocco dai 5 caratteri precedenti.
Ho quindi un modo per identificare visualmente i blocchi in transito sull'interconnect: il primo sarà pieno di A, B, C e D; il secondo di E, F, G, H, e così via.

Dopo aver eseguito le istruzioni precedenti su un nodo del cluster, passo al successivo facendo semplicemente

SQL> select * from aob;

Nel frattempo ho attivato Wireshark in modo da loggare tutto il traffico di passaggio sull'interfaccia di rete dell'interconnect su uno dei due nodi del cluster.

Ecco che cosa si vede da Wireshark con la MTU a 1500 byte (il blocco visualizzato è evidenziato in blu nell'elenco dei frame):

I frame di dati sono lunghi 882 byte, e vengono riassemblati in blocchi da 8248 byte (vedere in basso a sinistra nell'immagine). Nell'immagine si vede uno dei frame contenenti la "P"; servono perfino più di due frame per poter trasmettere anche una sola riga, lunga almeno 2002 byte.
Il frame di 1500 byte è quindi addirittura di gran lunga sottoutilizzato in questo caso.

Ora vediamo in dettaglio il traffico con la MTU a 9000 byte.
Ecco il blocco che comincia con la riga delle "I":
Più in basso si passa dalla "K" alla "L":
Ecco il blocco della "A" (notare che non sono in ordine, giustamente):
Ecco la fine del blocco della "A", "D":
Nei dati del blocco è presente la dimensione del frame, 8282 byte:
Ciò significa che, con l'MTU impostata a 9000 byte, i blocchi transitano integri sull'interconnect, garantendone il massimo delle prestazioni.
Probabilmente è possibile arrivare ad un valore ottimale per l'MTU, di poco superiore o di poco inferiore, guardando anche gli altri tipi di comunicazione sull'interconnect, ma per ora ci fermiamo qui.

Analytics - n.4: ranking

2008-12-21T12:22:00.001+01:00

Stavolta ci occupiamo delle funzioni RANK e DENSE_RANK.

Consideriamo ancora l'esempio dei maratoneti.
All'arrivo possiamo fare la classifica generale, ordinando per tempo di arrivo e assegnando a ogni corridore un numero progressivo che parte da 1, ad esempio con ROWNUM. Prendo un sottoinsieme della mia tabella di esempio per semplicità:

SQL> select ri, at, rownum rn from
  2  (select runner_id ri, arrival_time at
  3  from marathon
  4  where arrival_time between to_date('2008-06-19 13:01:00', 'YYYY-MM-DD HH24:MI:SS')
  5  and to_date('2008-06-19 13:03:00', 'YYYY-MM-DD HH24:MI:SS') order by arrival_time)
  6  ;

        RI AT                          RN
---------- ------------------- ----------
      2015 2008-06-19 13:01:04          1
      2293 2008-06-19 13:01:05          2
      3895 2008-06-19 13:01:06          3
      4931 2008-06-19 13:01:07          4
      4810 2008-06-19 13:01:10          5
      2747 2008-06-19 13:01:17          6
       125 2008-06-19 13:01:19          7
      1664 2008-06-19 13:01:20          8
       632 2008-06-19 13:01:21          9
       638 2008-06-19 13:01:23         10
      2207 2008-06-19 13:01:31         11
      4816 2008-06-19 13:01:32         12
      3550 2008-06-19 13:01:33         13
      3632 2008-06-19 13:01:33         14
       309 2008-06-19 13:01:34         15
      2254 2008-06-19 13:01:36         16
      1671 2008-06-19 13:01:43         17
      2068 2008-06-19 13:01:46         18
      3167 2008-06-19 13:02:02         19
      4269 2008-06-19 13:02:02         20
      4962 2008-06-19 13:02:02         21
      3921 2008-06-19 13:02:02         22
      2298 2008-06-19 13:02:29         23
      4933 2008-06-19 13:02:30         24
      2093 2008-06-19 13:02:34         25
      1528 2008-06-19 13:02:36         26
      1779 2008-06-19 13:02:40         27
      4313 2008-06-19 13:02:40         28
      2547 2008-06-19 13:02:40         29
      4482 2008-06-19 13:02:43         30
      3667 2008-06-19 13:02:44         31
      1117 2008-06-19 13:02:51         32
      4393 2008-06-19 13:02:53         33
       591 2008-06-19 13:02:55         34

34 rows selected.

Ma che cosa succede se due corridori hanno lo stesso tempo di arrivo (es. 13:02:02)? Bisogna assegnargli la posizione a parimerito. La funzione DENSE_RANK ci viene in aiuto (colonna DR):

SQL> select ri, at, rownum rn, dense_rank() over (order by at) dr from
  2  (select runner_id ri, arrival_time at
  3  from marathon
  4  where arrival_time between to_date('2008-06-19 13:01:00', 'YYYY-MM-DD HH24:MI:SS')
  5  and to_date('2008-06-19 13:03:00', 'YYYY-MM-DD HH24:MI:SS') order by arrival_time)
  6  ;

        RI AT                          RN         DR
---------- ------------------- ---------- ----------
      2015 2008-06-19 13:01:04          1          1
      2293 2008-06-19 13:01:05          2          2
      3895 2008-06-19 13:01:06          3          3
      4931 2008-06-19 13:01:07          4          4
      4810 2008-06-19 13:01:10          5          5
      2747 2008-06-19 13:01:17          6          6
       125 2008-06-19 13:01:19          7          7
      1664 2008-06-19 13:01:20          8          8
       632 2008-06-19 13:01:21          9          9
       638 2008-06-19 13:01:23         10         10
      2207 2008-06-19 13:01:31         11         11
      4816 2008-06-19 13:01:32         12         12
      3550 2008-06-19 13:01:33         13         13
      3632 2008-06-19 13:01:33         14         13
       309 2008-06-19 13:01:34         15         14
      2254 2008-06-19 13:01:36         16         15
      1671 2008-06-19 13:01:43         17         16
      2068 2008-06-19 13:01:46         18         17
      3167 2008-06-19 13:02:02         19         18
      4269 2008-06-19 13:02:02         20         18
      4962 2008-06-19 13:02:02         21         18
      3921 2008-06-19 13:02:02         22         18
      2298 2008-06-19 13:02:29         23         19
      4933 2008-06-19 13:02:30         24         20
      2093 2008-06-19 13:02:34         25         21
      1528 2008-06-19 13:02:36         26         22
      1779 2008-06-19 13:02:40         27         23
      4313 2008-06-19 13:02:40         28         23
      2547 2008-06-19 13:02:40         29         23
      4482 2008-06-19 13:02:43         30         24
      3667 2008-06-19 13:02:44         31         25
      1117 2008-06-19 13:02:51         32         26
      4393 2008-06-19 13:02:53         33         27
       591 2008-06-19 13:02:55         34         28

34 rows selected.

Diverso sarebbe il caso in cui volessimo considerare l'ordine di arrivo, fatti salvi i corridori a parimerito: infatti quelli a parimerito sarebbero tutti nella stessa posizione, mentre il successivo avrebbe comunque la posizione assoluta (tipo ROWNUM) conservata (colonna R):

SQL> select ri, at, rownum rn, dense_rank() over (order by at) dr,
  2  rank() over (order by at) r from
  3  (select runner_id ri, arrival_time at
  4  from marathon
  5  where arrival_time between to_date('2008-06-19 13:01:00', 'YYYY-MM-DD HH24:MI:SS')
  6  and to_date('2008-06-19 13:03:00', 'YYYY-MM-DD HH24:MI:SS') order by arrival_time)
  7  ;

        RI AT                          RN         DR          R
---------- ------------------- ---------- ---------- ----------
      2015 2008-06-19 13:01:04          1          1          1
      2293 2008-06-19 13:01:05          2          2          2
      3895 2008-06-19 13:01:06          3          3          3
      4931 2008-06-19 13:01:07          4          4          4
      4810 2008-06-19 13:01:10          5          5          5
      2747 2008-06-19 13:01:17          6          6          6
       125 2008-06-19 13:01:19          7          7          7
      1664 2008-06-19 13:01:20          8          8          8
       632 2008-06-19 13:01:21          9          9          9
       638 2008-06-19 13:01:23         10         10         10
      2207 2008-06-19 13:01:31         11         11         11
      4816 2008-06-19 13:01:32         12         12         12
      3550 2008-06-19 13:01:33         13         13         13
      3632 2008-06-19 13:01:33         14         13         13
       309 2008-06-19 13:01:34         15         14         15
      2254 2008-06-19 13:01:36         16         15         16
      1671 2008-06-19 13:01:43         17         16         17
      2068 2008-06-19 13:01:46         18         17         18
      3167 2008-06-19 13:02:02         19         18         19
      4269 2008-06-19 13:02:02         20         18         19
      4962 2008-06-19 13:02:02         21         18         19
      3921 2008-06-19 13:02:02         22         18         19
      2298 2008-06-19 13:02:29         23         19         23
      4933 2008-06-19 13:02:30         24         20         24
      2093 2008-06-19 13:02:34         25         21         25
      1528 2008-06-19 13:02:36         26         22         26
      1779 2008-06-19 13:02:40         27         23         27
      4313 2008-06-19 13:02:40         28         23         27
      2547 2008-06-19 13:02:40         29         23         27
      4482 2008-06-19 13:02:43         30         24         30
      3667 2008-06-19 13:02:44         31         25         31
      1117 2008-06-19 13:02:51         32         26         32
      4393 2008-06-19 13:02:53         33         27         33
       591 2008-06-19 13:02:55         34         28         34

34 rows selected.

Un'altra funzione è ROW_NUMBER, che semplicemente assegna un valore crescente a partire da 1 alle righe della partizione, nulla più.
In pratica potremmo sostituire la subquery più interna che fa l'ordinamento direttamente con ROW_NUMBER, senza utilizzare ROWNUM:

SQL> select runner_id ri, arrival_time at, row_number() over (order by arrival_time) rn
  2  from marathon
  3  where arrival_time between to_date('2008-06-19 13:01:00', 'YYYY-MM-DD HH24:MI:SS')
  4  and to_date('2008-06-19 13:03:00', 'YYYY-MM-DD HH24:MI:SS') order by arrival_time;

        RI AT                          RN
---------- ------------------- ----------
      2015 2008-06-19 13:01:04          1
      2293 2008-06-19 13:01:05          2
      3895 2008-06-19 13:01:06          3
      4931 2008-06-19 13:01:07          4
      4810 2008-06-19 13:01:10          5
      2747 2008-06-19 13:01:17          6
       125 2008-06-19 13:01:19          7
      1664 2008-06-19 13:01:20          8
       632 2008-06-19 13:01:21          9
       638 2008-06-19 13:01:23         10
      2207 2008-06-19 13:01:31         11
      4816 2008-06-19 13:01:32         12
      3550 2008-06-19 13:01:33         13
      3632 2008-06-19 13:01:33         14
       309 2008-06-19 13:01:34         15
      2254 2008-06-19 13:01:36         16
      1671 2008-06-19 13:01:43         17
      2068 2008-06-19 13:01:46         18
      3167 2008-06-19 13:02:02         19
      4269 2008-06-19 13:02:02         20
      4962 2008-06-19 13:02:02         21
      3921 2008-06-19 13:02:02         22
      2298 2008-06-19 13:02:29         23
      4933 2008-06-19 13:02:30         24
      2093 2008-06-19 13:02:34         25
      1528 2008-06-19 13:02:36         26
      1779 2008-06-19 13:02:40         27
      4313 2008-06-19 13:02:40         28
      2547 2008-06-19 13:02:40         29
      4482 2008-06-19 13:02:43         30
      3667 2008-06-19 13:02:44         31
      1117 2008-06-19 13:02:51         32
      4393 2008-06-19 13:02:53         33
       591 2008-06-19 13:02:55         34

34 rows selected.

Indovinello con COUNT: soluzione

2008-12-02T14:10:00.000+01:00

L'indovinello e la relativa soluzione derivano dal libro di Jonathan Lewis "Cost-based Oracle", di cui ho già parlato; libro peraltro a volte molto difficile, quasi sempre molto pesante, che però a volte riserva soprese e piccole grandi illuminazioni.
Ho riscritto tutto in un modo che mi sembra più chiaro.

Cominciamo a definire un vettore contenente tutte le età possibili da 1 a 36 anni:

select
  rownum age
from
  all_objects
where
  rownum <= 36;

Cominciamo a porre la prima condizione: il prodotto delle età è 36.
Imponiamo anche, per comodità, la condizione che le età siano crescenti (age1 <= age2 <= age3), per evitare risultati simmetrici:

with age_list as
(
select
  rownum age
from
  all_objects
where
  rownum <= 36
)
select
  age1.age a1,
  age2.age a2,
  age3.age a3
from
  age_list age1,
  age_list age2,
  age_list age3
where
  age1.age <= age2.age
  and age2.age <= age3.age
  and age1.age * age2.age * age3.age = (select max(age) from age_list);

Ora abbiamo tutte le età possibili:

 A1    A2       A3
---------- ---------- ----------
  1     1       36
  2     2        9
  1     2       18
  3     3        4
  2     3        6
  1     3       12
  1     4        9
  1     6        6

Ora sommiamo le età:

with age_list as
(
select
  rownum age
from
  all_objects
where
  rownum <= 36
),
product_check as
(
select
  age1.age a1,
  age2.age a2,
  age3.age a3
from
  age_list age1,
  age_list age2,
  age_list age3
where
  age1.age <= age2.age
  and age2.age <= age3.age
  and age1.age * age2.age * age3.age = (select max(age) from age_list)
)
select
  a1,
  a2,
  a3,
  a1+a2+a3 age_sum
from product_check;

 A1    A2       A3    AGE_SUM
---------- ---------- ---------- ----------
  1     1       36  38
  2     2        9  13
  1     2       18  21
  3     3        4  10
  2     3        6  11
  1     3       12  16
  1     4        9  14
  1     6        6  13

Ora: il secondo DBA è ancora dubbioso anche sapendo la somma delle età, ottenuta contando le persone presenti nella stanza, quindi ci troviamo in un caso di ambiguità (somme uguali), che troviamo mediante la nostra funzione analitica :-)

with age_list as
(
select
  rownum age
from
  all_objects
where
  rownum <= 36
),
product_check as
(
select
  age1.age a1,
  age2.age a2,
  age3.age a3
from
  age_list age1,
  age_list age2,
  age_list age3
where
  age1.age <= age2.age
  and age2.age <= age3.age
  and age1.age * age2.age * age3.age = (select max(age) from age_list)
),
sum_check as
(
select
  a1,
  a2,
  a3,
  a1+a2+a3 age_sum
from
  product_check
)
select
  a1,
  a2,
  a3,
  count(*) over (partition by age_sum) c
from
  sum_check;

 A1    A2       A3   C
---------- ---------- ---------- ----------
  3     3        4   1
  2     3        6   1
  2     2        9   2
  1     6        6   2
  1     4        9   1
  1     3       12   1
  1     2       18   1
  1     1       36   1

I due casi sono 2, 2, 9 e 1, 6, 6, dove il conteggio delle somme uguali è maggiore di 1.
L'ultimo indizio ci informa che esiste una figlia maggiore (il criceto serve a confondere un po' le idee), il che ci permette di escludere che il caso 1, 6, 6 e di affermare quindi che le età sono 2, 2 e 9 anni.

Analytics - n.3: un indovinello con COUNT

2008-11-30T22:09:00.001+01:00

Anche le funzioni classiche come COUNT, SUM, AVG hanno la loro controparte analitica.

Oggi utilizziamo Oracle per risolvere un indovinello, utilizzando la versione analitica delle tradizionali funzioni di gruppo. Chi lo dice che tutte le spiegazioni devono per forza essere noiose? :-)

Due DBA si incontrano all'Oracle Openworld. Il primo viene a sapere che il secondo ha 3 figlie, quindi gli chiede la loro età. Il secondo, in vena di enigmi, dice:
"Il prodotto delle età delle mie figlie è 36."
L'altro ragiona un attimo, ma chiede più informazioni, perché il solo prodotto delle età non gli basta.
"La somma delle età delle mie figlie è uguale al numero di persone che stanno in questa stanza"
L'altro conta le persone, ci pensa, ma i dati non gli bastano ancora, e chiede maggiori indizi.
"La più grande delle mie figlie ha un criceto maculato".
L'altro raggiunge un prompt SQL e, dopo pochi minuti, ha la soluzione!

Come avrà fatto?

Domani pubblicherò la soluzione.
Mi raccomando non utilizzate Google, altrimenti non è leale (sempre che si riesca a trovare con Google).
Pubblicate le vostre soluzioni nei commenti, a condizione che utilizziate SQL e le funzioni analitiche.

Solaris sostituisce Linux a casa

2008-11-23T22:08:00.000+01:00

Sono passato a Solaris per il mio megaserver casalingo. Complice la scarsa affidabilità del paio di dischi originali, sostituiti con una coppia da 320 GB nuova, mi sono trovato a provare la nuova splendida versione di Solaris (10/08) su x86/64.

Con la nuova versione di Solaris è possibile avere il disco di root in mirror software, attraverso un pool ZFS. Non solo: il programma di installazione installa il boot-loader grub anche sul secondo disco, rendendo praticamente indifferente il disco da cui viene fatto il boot.
ZFS infatti si basa su metadati registrati sui dischi; da ciò ne deriva che, anche facendo il boot dal secondo disco, ci si ritrova esattamente come se si fosse fatto il boot dal primo.
Non ho ancora provato ma, quasi sicuramente, anche l'ordine dei dischi rispetto al BIOS e la loro posizione sul bus SATA sia del tutto indifferente.

Con ZFS lo spazio dei dischi si sfrutta molto meglio, non essendoci spazi vuoti tra un filesystem e l'altro, quindi mi sento un po' meno "costretto" dallo spazio disponibile.
ZFS inoltre ottimizza le letture da disco, utilizzando entrambi i dischi in parallelo come i migliori controller RAID, ottenendo quasi un raddoppio delle prestazioni. Anche in scrittura la velocità non manca, almeno da quanto ho potuto constatare. Pensavo infatti che la doppia scrittura fosse molto penalizzante, ma mi sono ricreduto; evidentemente ZFS fa la seconda scrittura in modo asincrono.

Pochi giorni fa è uscito l'ultimo patchset 10g per Solaris x86/64, che ora fa bella mostra di sé nel nuovo server. Purtroppo per 11g si prevedono tempi più lunghi, sempre che non decidano (chissà) di trascurare Solaris su Intel.

VirtualBox, il software di virtualizzazione open-source della Sun, funziona perfettamente, e per ora sto provando a creare nuove macchine virtuali Linux, per avere installazioni RAC di prova.

ZFS esporta nativamente target iSCSI tramite volumi ZFS, differenti dai filesystem ZFS, quindi penso che i nuovi RAC virtuali avranno il loro storage condiviso via iSCSI. Non so invece se sono utilizzabili con RAC i volumi vboxfs condivisi, per i soliti problemi di sincronia dell'accesso ai dischi.

Ho completato anche una installazione di Oracle BI Publisher (per una demo) in modalità manuale, ovvero facendo uso del servlet engine di Sun, invece del nativo OC4J, non disponibile per la mia coppia CPU/OS.
Ho utilizzato infatti Sun Java System Web Server 7.0, molto interessante. Ovviamente l'installazione del web server è stata facilissima, come la sua gestione (se si conosce ciò che si sta facendo). In questi aspetti, il software enterprise è enormemente più piacevole da usare del software open-source.

Ho fatto i primi passi anche con i Solaris Containers, che sono una specie di macchine virtuali uguali al sistema operativo ospite. Di questo parleremo più avanti.

Oracle e SQL Server a confronto

2008-11-19T22:30:00.000+01:00

Avendo avuto a che fare con un test di migrazione da Microsoft SQL Server a Oracle, mi si è aperto un mondo nuovo con l'utilizzo di SQL Developer Migration Workbench.

Nella documentazione HTML è presente un'interessante comparativa tra SQL Server e Oracle, molto istruttiva da qualsiasi punto di vista, anche per riassumere le caratteristiche principali dei due database.
In particolare vengono sintetizzate le differenze per quanto riguarda i concetti di locking e di concorrenza.

I servizi RAC anche su istanza singola

2008-11-04T21:47:00.000+01:00

Una delle particolarità di Oracle RAC è la possibilità di definire i servizi, ovvero una sorta di modalità di connessione via rete al db avente caratteristiche definibili dall'utente.
Se, per esempio, abbiamo un RAC da 3 nodi e volessimo che una nostra applicazione si collegasse solo ai nodi 2 e 3 del cluster, definiremmo un servizio che viene attivato solo sui nodi 2 e 3, in modo che le connessioni dirette al cluster vengano rimandate dai listener solo ai nodi su cui è attivo il servizio.
Ci sono molti altri parametri di configurazione di un servizio, tra cui le istanze verso le quali viene rediretto il servizio nel caso di indisponibilità dei nodi attivi, timeout vari e quant'altro.

È abbastanza interessante però che si possano definire i servizi anche per un database non RAC, composto da una sola istanza (esistono comunque anche i RAC single-instance).
I servizi, nel caso istanza singola, si possono creare e gestire con DBMS_SERVICE e le sue procedure CREATE_SERVICE e START_SERVICE.
CREATE_SERVICE prende come parametri il nome del servizio visto dal lato db e il nome visto dal lato listener, ovvero il famoso SERVICE_NAME all'interno dei connect descriptor dei client.

Ovviamente il connection load-balancing, e i vari metodi di failover non hanno senso, ma è possibile trarre qualche vantaggio da questa architettura.
Direi che i vantaggi possono essere un paio:

Se creo un servizio e gli utenti di un certo gruppo/applicazione si collegano a quel servizio, posso fermarlo per manutenzione quando mi pare e impedirgli di connettersi, mentre il db rimane aperto e gli altri utenti continuano a lavorare senza problemi.
Tramite la procedura DISCONNECT_SESSION posso disconnettere tutte e sole le sessioni collegate ad un determinato servizio con un solo comando, e a volte può essere veramente utile.

Backup "istantaneo" con Oracle e ZFS

2008-10-18T14:19:00.000+02:00

Continuiamo la miniserie di post su ZFS, l'ottimo filesystem di Solaris e OpenSolaris.

La proprietà di poter fare lo snapshot di un filesystem consente di utilizzare il backup a caldo del database via ALTER DATABASE BEGIN BACKUP con Oracle 10g.
In Oracle 10g, infatti, è possibile mettere tutto il db in backup mode con un solo comando, invece di farlo singolarmente per ogni tablespace.

Ecco il log di un backup effettuato a caldo con uno snapshot su una macchina Solaris 10:

Connected to:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

SQL> set timing on
SQL> alter database begin backup;

Database altered.

Elapsed: 00:00:00.62

SQL> host sudo zfs destroy u01/oradata@`date +%A`
cannot open 'u01/oradata@Thursday': dataset does not exist

SQL> host sudo zfs snapshot u01/oradata@`date +%A`

SQL> alter database end backup;

Database altered.

Elapsed: 00:00:00.44
SQL>

Il tutto è durato pochi secondi, e comunque la durata dello snapshot è quasi indipendente dalle dimensioni del database.
Lo snapshot è ora pronto su disco da copiare su un altro server. Questo è il passo che richiederà più tempo, ma il backup è praticamente già fatto.


$ zfs list
NAME                   USED  AVAIL  REFER  MOUNTPOINT
u01                   17.2G  49.7G  80.6M  /u01
u01/oradata           17.1G  49.7G  17.1G  /u01/oradata
u01/oradata@Thursday   526K      -  17.1G  -
u02                   16.9G  79.6G  14.3G  /u02
u02/oradata           2.59G  79.6G  2.59G  /u02/oradata

Per il trasferimento dello snapshot su nastro o su altri dischi o server si possono usare i comandi tradizionali, oppure "rigenerare" lo snapshot direttamente su un altro filesystem ZFS di un altro server via ssh con zfs send.
Ma vi lascio scoprire questa magica e gustosa feature da soli per esercizio :-)

Come è possibile tutto ciò?
Come si può vedere lo snapshot, dopo qualche secondo dalla creazione, occupa circa 500 KB, e le sue dimensioni continuano a crescere.
ZFS alloca lo spazio su disco in "record" (analoghi ai blocchi dei filesystem tradizionali), grandi di default 128 KB.
In pratica ZFS fa in modo di tenere validi su disco i record appartenenti al filesystem al momento dello snapshot, occupando nuovo spazio per i blocchi che vengono modificati o aggiunti al filesystem originario. Il nuovo spazio allocato, man mano che passa il tempo, compare nella lista come occupazione dello snapshot. Ricorda il funzionamento degli snapshot LVM. Geniale.

RAC su macchine virtuali: ma ha senso?

2008-10-08T22:12:00.000+02:00

Leggo volentieri da Techblast che Oracle ha certificato RAC su macchine virtuali Oracle VM.

Avere un cluster su macchine virtuali va un po' contro l'idea di alta affidabilità insita nel concetto di cluster.

La parte interessante nel documento Oracle è ovviamente l'architettura. E le chicche non mancano.

In sintesi l'architettura è spiegata dall'immagine seguente:
È evidente come la virtualizzazione venga utilizzata per ospitare più nodi virtuali (di cluster diversi) su un solo server fisico, ma il meccanismo di alta affidabilità viene conservato poichè ogni nodo di uno stesso database cluster risiede su un server fisico diverso.

Lo storage condiviso di RAC viene gestito in domain0:
Il multipathing viene utilizzato solamente sul percorso fisico dei dati da e verso i dischi, non su quello virtuale da domain0 ai domini virtuali.

Analogamente, le interfacce di rete sono in bond solo sulle porte fisiche, mentre i bridge virtuali di xenbr0 e xenbr1, sempre in domain0, sono rispettivamente la rete pubblica e la rete privata del RAC.
Essendo le istanze del RAC su nodi fisici differenti, anche per la comunicazione su rete privata si passa da rete fisica; ciò non è necessario invece nel caso di nodi sullo stesso server, che comunicherebbero direttamente attraverso il bridge 1; ma questa non è assolutamente una configurazione ragionevole per un ambiente HA.

Date le premesse del documento Oracle, sotto quest'ottica la soluzione RAC su macchine virtuali diventa tutt'altro che insensata in vari ambienti, soprattutto per consolidare server e sfruttare al massimo la potenza di elaborazione dei server attuali, facendo economia di scala.

Analytics - n.2: LEAD e LAG

2008-09-25T22:47:00.000+02:00

LEAD e LAG sono funzioni analitiche che permettono di accedere al valore di un campo di un record del recordset risultato della nostra query, specificando l'offset dal record in cui la funzione viene valutata.
Nel caso di un offset che va fuori dal recordset, è possibile specificare un valore di default ritornato dalla funzione.

Il punto essenziale, come per gran parte delle funzioni analitiche, è l'ordinamento del risultato: il valore dell'n-esima riga prima o dopo la riga corrente è dato proprio dell'"order by" specificato nel partizionamento del resultset.

Prendiamo sempre l'esempio dei maratoneti che ho usato in un post precedente.
Mettiamo che io voglia conoscere la differenza di tempo in arrivo tra un corridore e il successivo, un po' come viene fatto alla fine di gare a tempo.
Posso usare la funzione LAG con parametro 1 e computata ordinando la tabella per arrival_time:

 SELECT runner_id,
  arrival_time   ,
  extract(minute FROM
(arrival_time - lag(arrival_time, 1, arrival_time) over (order by arrival_time)) DAY TO second)
  ||''''
  || extract(second FROM
(arrival_time - lag(arrival_time, 1, arrival_time) over (order by arrival_time)) DAY TO second)
  ||'"' time_diff
   FROM marathon
  WHERE rownum < 10
ORDER BY arrival_time;

Nell'esempio prendo solo 10 righe per avere un po' di intervallo tra i tempi di arrivo e il risultato è il seguente:

 RUNNER_ID ARRIVAL_TIME        TIME_DIFF
---------- ------------------- ----------------------------------------------------------------------------------
      4038 2008-06-19 12:32:09 0'0"
      3144 2008-06-19 12:44:10 12'1"
       660 2008-06-19 12:51:40 7'30"
      4450 2008-06-19 12:54:54 3'14"
      2441 2008-06-19 12:58:28 3'34"
       591 2008-06-19 13:02:55 4'27"
      3825 2008-06-19 13:05:03 2'8"
      3169 2008-06-19 13:11:21 6'18"
      4036 2008-06-19 13:11:39 0'18"

La funzionalità di LEAD è analoga a LAG, solo che va nel verso opposto, ovvero considera i record precedenti a quello in cui viene valutata.

Oracle DBA Italia

2008-09-21T11:35:00.004+02:00

Tempo fa sul blog di Cristian Cudizio si parlava di qualche iniziativa per riunire tutti i DBA Oracle italiani in una specie di network.
Ho provato a pensare a qualche soluzione, e l'unica che mi è venuta in mente è utilizzare Facebook.
Ho deciso quindi di fare una prova: in pieno spirito Web 2.0, ho creato un gruppo Facebook per tutti i DBA Oracle in Italia.

Invito tutti gli interessati ad iscriversi, prima di tutto a Facebook, se non fossero già iscritti.

Per ora il gruppo è pubblico, quindi tutti possono iscriversi e utilizzare tutte le funzioni messe a disposizione da Facebook. Anche il contenuto delle pagine create dai membri rimane pubblico.

Le funzioni sono le seguenti:

Discussioni
Bacheca
Foto
Video
Link utili
Eventi

Ritengo che siano più che sufficienti per iniziare a interagire, scambiarsi informazioni che altrove (es. sui blog dei partecipanti) non trovano collocazione e, perché no, organizzare futuri incontri ed eventi.
Non dimentichiamo che anche le aziende potrebbero essere molto interessate a noi!

Forza quindi! Io per oggi ho contribuito con il logo. Sfogate la vostra voglia di comunicare!
Attendo commenti, contributi, modifiche, critiche, segnali di vita...

Dischi, burro e marmellata

2008-08-25T19:20:00.005+02:00

Sono quantomai sorpreso dell'apprendere, sull'ultimo numero dell'ottimo Oracle Magazine, che Oracle ha avviato pochi mesi fa un progetto open source per un nuovo potente filesystem.

La grande sorpresa consiste nel fatto che tale BTRFS dove, viene precisato, btr si pronuncia butter, ricalca fedelmente l'interessantissimo ZFS di Sun, disponibile già da tempo nella famiglia di sistemi operativi Solaris.

Avevo intenzione di fare un post solo su ZFS per le sue rivoluzionarie caratteristiche, ovviamente dal punto di vista Oracle, anche per il fatto che ci sto lavorando abbastanza intensamente e ne ho potuto apprezzare le ottime funzionalità.

A questo punto cominciamo da ZFS. La migliore definizione che mi viene in mente è che ZFS è un filesystem e volume manager integrati, con possibilità di snapshot stile LVM e possibilità di replica anche incrementale.

Un'importantissima caratteristica di ZFS è che è un filesystem copy-on-write (COW): ciò significa che tutte le modifiche ai dati vengono scritte su disco in nuove allocazioni, lasciando integra su disco la precedente versione dei dati. Ciò è da tenere ben presente per un DBA poichè, col passare del tempo, i dati tendono a venire sparpagliati sul disco, aumentando quindi il tempo d'accesso specie per le letture di dati in sequenza; si pensi ad esempio all'utilità del db_file_multiblock_read_count di Oracle, anche se è ormai quasi obsoleto.

ZFS è anche un volume manager, ovvero può prendere in gestione più dischi e comporre zpool più grandi, in cui gestisce automaticamente lo striping; oppure può garantire livelli di tolleranza ai guasti come il mirroring e il RAIDZ, una modalità che somiglia molto al RAID5 o addirittura RAID6 con due dischi di "parità".

Il COW diventa meno importante man mano che il numero dei dischi a disposizione aumenta, poiché lo striping riduce naturalmente il raggruppamento dei dati in blocchi contigui su disco.

ZFS è un filesystem transazionale, ovvero le modifiche ai dati o avvengono in blocco o non avvengono; ciò, unito al COW, consente di fare a meno del journal, caratteristica di punta di filesystem avanzati come ReiserFS o ext3.

Con ZFS si possono anche fare snapshot consistenti istantanei dei filesystem, direttamente accessibili sul filesystem stesso, quindi copiabili e salvabili. Ciò rende possibile un hot-backup con il comando 10g ALTER DATABASE BEGIN BACKUP, come potrebbe avvenire con storage molto più costosi.

Da un punto di vista amministrativo ZFS è troppo semplice per essere vero: consente in pochi e semplicissimi comandi di sintetizzare numerose operazioni di amministrazione del sistema. E non solo, offre un supporto nativo a iSCSI e NFS senza toccare alcun file di configurazione.

Torniamo a BTRFS: le caratteristiche sul sito Wiki sembrano proprio ricalcare quelle di ZFS, che è anch'esso open-source. Ma allora perché non integrarlo nel kernel Linux?
Il problema sta nella licenza, che non è GPL (e sembra che Sun abbia fatto apposta).

La mia sensazione però è che alla fine non se ne faccia un granché, visto che ZFS è già in produzione avanzata sotto Solaris, mentre BTRFS è all'inizio dello sviluppo.

Tornerò sul tema ZFS per dirvi degli interessanti documenti in rete sui database e dei risultati delle mie prove.

Oracle 11g su OpenSuSE 11

2008-08-14T10:26:00.004+02:00

Visto che uno dei due dischi del mio megaserver di casa ha deciso, bontà sua, di rimettersi a funzionare, sono riuscito a fare vari esperimenti di cui vi parlerò, tra cui la prova di installazione di Oracle 11g su OpenSuSE 11.

L'installazione è andata molto bene e senza alcun errore, quindi la piattaforma preferenziale per le mie prossime installazioni di prova 11g sarà sicuramente OpenSuSE 11.

L'unica variazione nella configurazione, rispetto a quella di default, è l'aggiunta delle componenti di sviluppo C/C++ durante l'installazione, e un package libstdc++-devel che ho aggiunto io per precauzione.

Il vantaggio maggiore di utilizzare una distribuzione Linux non supportata da Oracle è di avere un sistema operativo completamente aggiornato, e in modo gratuito. Per noi che smanettiamo spesso con questo genere di software sarebbe bello che tutto ciò che dobbiamo installare sia liberamente utilizzabile per fini di ricerca.

ASM a linea di comando

2008-07-12T11:50:00.000+02:00

Ogni tanto arriva qualche e-mail dai lettori di questo blog. La maggior parte delle domande riguarda ASM, il volume manager/filesystem di Oracle dedicato all'immagazzinamento dei dati del suo motore RDBMS.

Forse non tutti sanno che ASM è accessibile anche da linea di comando con asmcmd.

asmcmd è sostanzialmente un prompt dei comandi che si collega all'istanza ASM attiva sulla $ORACLE_HOME impostata nell'ambiente, con il relativo $ORACLE_SID impostato a +ASM o +ASM<n> nel caso di RAC.

Eseguiamo asmcmd:

oracle@host:~> asmcmd -p
ASMCMD [+] >

Il flag -p permette di mostrare il path tra parentesi quadre.
I comandi disponibili sono: cd, du, find, help, ls, lsct, lsdg, mkalias, mkdir, pwd, rm, rmalias.
Per ogni comando si può avere l'help con help <comando>.
All'avvio troviamo l'elenco dei diskgroup montati dall'istanza ASM e in seguito i database montati in notazione OMF:

ASMCMD [+] > ls
DG1/
ASMCMD [+] > ls
ASMCMD [+] > cd DG1
ASMCMD [+DG1] > ls
DBTEST/
ASMCMD [+DG1] >

All'interno delle directory DB troveremo le sottodirectory in notazione OMF come su filesystem ordinario:

ASMCMD [+DG1/DBTEST] > ls
ARCHIVELOG/
CONTROLFILE/
DATAFILE/
ONLINELOG/
PARAMETERFILE/
TEMPFILE/
spfileDBTEST.ora
ASMCMD [+DG1/DBTEST] >

Il comando du mostra l'utilizzo del diskgroup:

ASMCMD [+DG1/DBTEST] > du .  
Used_MB      Mirror_used_MB
  24529               24529

Il comando lsdg mostra tutti i diskgroup:

ASMCMD [+] > lsdg
State    Type    Rebal  Unbal  
Sector  Block       AU  Total_MB  
Free_MB  Req_mir_free_MB  Usable_file_MB  
Offline_disks  Name
MOUNTED  EXTERN  N      N    
   512   4096  1048576    347430  
 322841                0          322841  
            0  DG1/

Contrariamente a un filesystem normale, esistono i comandi per creare e rimuovere alias mkalias e rmalias.
Gli alias in ASM sono file finti nel filesystem che puntano a file normali che risiedono sempre in ASM; possono essere visti come link simbolici. Ricordiamo infatti che ogni file in un volume ASM è un file OMF, ovvero è un file del database Oracle (controlfile, datafile, redo, e così via) con un nome scelto dal RDBMS, ma non un file ordinario. Per ogni file del db, quindi, esiste uno e un solo file OMF con il nome scelto da Oracle. Per avere file con nomi più leggibili o facili da ricordare si usano gli alias, a cui si può fare riferimento con i comandi DDL da prompt SQL al posto dei file OMF. Gli alias possono risiedere ovunque in ASM.

Vantaggi del sampling dinamico

2008-07-03T22:11:00.001+02:00

Ho recentemente letto un curioso aricolo di Tom Kyte su Oracle Magazine sul dynamic sampling e i suoi vantaggi rispetto alle statistiche usate dal cost-based optimizer (CBO) in alcuni casi particolari.

La prima parte dell'articolo parla di V$SQL ed è molto interessante. Qui mi occupo della seconda parte, ovvero della cardinalità nel piano di esecuzione a seconda che venga usato il CBO o il sampling dinamico.

Nell'articolo si fa l'esempio di una tabella in cui due colonne (X e Y) hanno 12 valori distinti distribuiti uniformemente tra le righe, per cui una query del tipo

SELECT * FROM T WHERE X=5;

restituisce 1/12 delle righe, mentre

SELECT * FROM T WHERE X=5 AND Y=6;

restituisce 1/144 delle righe (1/12 * 1/12).
O almeno, questa è la selettività che si ottiene dalle statistiche sulla tabella.

Ma che cosa accade se X=Y per ogni riga? Una query come

SELECT * FROM T WHERE X=5 AND Y=6;

ritornerebbe 0 righe, quindi la stima del CBO sarebbe errata (introducendo eventuali piani di esecuzione sballati).

Utilizzando il sampling dinamico:

select /*+ dynamic_sampling(t 3) */ * from t

si ottiene invece il costo corretto, molto più basso, e quindi anche il piano corretto.

Il sampling dinamico è regolabile a vari livelli, espressi dal numero che segue il nome della tabella nell'hint all'optimizer. Il valore minimo del sampling è 32 blocchi con n=1; per i livelli da 1 a 9 vale la formula 32*2^(l-1) blocchi dove l è il livello di sampling. Nel nostro caso di n=3 si ha un sampling di 4*32=128 blocchi, per cui quasi certamente l'optimizer ha letto l'intera tabella. Per questo motivo il costo finale è molto preciso. Se il livello è 0 non si ha sampling, se è 10 il sampling viene fatto su tutti i blocchi della tabella (quindi può risultare mooolto lento).

Il dynamic sampling è quindi una possibilità in più utilizzabile nei casi in cui il CBO ci fornisce piani di esecuzione subottimali.

OCA 10g solo con esame SQL

2008-07-03T21:40:00.001+02:00

Dal 28 novembre 2008 verrà richiesto un esame SQL per ottenere la certificazione OCA 10g, contrariamente a quanto è successo fin'ora, da quando fu introdotta la certificazione di base 10g.

Vedo con piacere che il buon vecchio 1Z0-007 (SQL 9i) torna in auge.

Analytics - n.1: NTILE

2008-06-23T22:06:00.001+02:00

Con questo post inauguro la serie "Analytics", ovvero come utilizzare le potenti funzioni analitiche di Oracle 10g.

NTILE è una funzione che permette di ottenere il numero corrente di partizione dei dati, basandosi su un criterio di partizione determinato nella query.

Facciamo subito un esempio: ho una tabella che contiene i tempi di arrivo di una maratona con tanti partecipanti, diciamo 5000. Di questi, 1000 sono arrivati al traguardo, mentre gli altri si sono persi per strada.
La tabella contiene un ID univoco del corridore e il suo tempo di arrivo.

Supponiamo che io voglia dividere l'insieme degli "arrivati" in n gruppi omogenei, cioè aventi lo stesso numero di componenti.
Gli ID, anche se generati con una sequenza, sono distribuiti casualmente, dato che solo 1/5 dei corridori è arrivato alla fine; lo stesso vale per i tempi di arrivo.

La funzione NTILE ci permette di dividere il nostro set di dati in partizioni uguali, assegnando ad ogni riga il numero di partizione in cui si trova. Il criterio per trovarsi in una partizione o in un'altra è il tempo di arrivo in ordine crescente.

Dividiamoli ad esempio in 10 gruppi:

SQL> select * from marathon;

 RUNNER_ID ARRIVAL_TIME                                                                                                                                       
---------- -------------------                                                                                                                                
        93 2008-06-19 13:11:39                                                                                                                                
      3144 2008-06-19 12:44:10                                                                                                                                
      4450 2008-06-19 12:54:54                                                                                                                                
       453 2008-06-19 12:52:58                                                                                                                                
       808 2008-06-19 12:48:00                                                                                                                                
      4036 2008-06-19 13:11:39                                                                                                                                
      4048 2008-06-19 13:06:48                                                                                                                                
       660 2008-06-19 12:51:40                                                                                                                                
      4091 2008-06-19 13:12:38                                                                                                                                
       591 2008-06-19 13:02:55                                                                                                                                
[...]

Con la query seguente otteniamo la divisione in gruppi:

SQL> select runner_id, arrival_time, ntile(10) over (order by arrival_time) nt from marathon;

Come si può vedere, ci sono esattamente 100 corridori in ogni gruppo:

SQL> select nt, count(*) from
(select runner_id, arrival_time,
ntile(10) over (order by arrival_time) nt from marathon)
group by nt order by nt;

        NT   COUNT(*)                                                                                                                                         
---------- ----------                                                                                                                                         
         1        100                                                                                                                                         
         2        100                                                                                                                                         
         3        100                                                                                                                                         
         4        100                                                                                                                                         
         5        100                                                                                                                                         
         6        100                                                                                                                                         
         7        100                                                                                                                                         
         8        100                                                                                                                                         
         9        100                                                                                                                                         
        10        100                                                                                                                                         

10 rows selected.

Possiamo anche calcolare l'ntile su una partizione dei dati originari: immaginiamo per esempio che ai corridori siano state assegnate delle pettorine colorate di rosso se il loro id era tra 1 e 1000, verde se tra 1001 e 2000, blu se maggiore di 2000, divisi quindi per categoria.
Una query come la seguente divide in dieci sottogruppi ogni categoria, basandosi sempre sul tempo di arrivo:

SQL> select runner_id, arrival_time, color,
ntile(10) over (partition by color order by arrival_time) from marathon;

ROWSCN, una soluzione ai lost update

2008-06-02T11:00:00.001+02:00

Per le applicazioni web-based l'aggiornamento di una serie di record nel database presenta problemi diversi da quelli delle applicazioni tradizionali client-server, che di solito utilizzano il metodo "SELECT ... FOR UPDATE".

Facciamo un esempio: due utenti di una webapp caricano una form di attributi di una stessa persona (identificata solamente da una chiave primaria) e li modificano nello stesso intervallo di tempo. Trascurando l'opportunità della cosa, l'ultima che avrà cliccato su "aggiorna" scriverà i dati della form nel database, sovrascrivendo eventuali modifiche fatte dal primo utente.

Ci sono un paio di metodi per accorgersi questa situazione: fare la "SELECT FOR UPDATE" appena prima di modificare il record inserendo una condizione WHERE che contiene tutti i dati originali, oppure usare una colonna timestamp per sapere la data di ultima modifica.
Non ci interessa invece che cosa fa l'applicazione una volta accortasi della cosa: ciò dipende dalla business logic, ovvero dal tipo di applicazione.

In Oracle 10g è presente una nuova pseudo-colonna: ORA_ROWSCN. Essa contiene l'SCN relativo all'ultima operazione DML effettuata sul blocco che contiene la riga selezionata. In questo modo è possibile sapere se il blocco è stato modificato dall'ultima lettura effettuata; ma come si fa ad utilizzare a livello di riga? La dipendenza a livello di riga viene abilitata all'atto di creazione di una tabella con la clausola ROWDEPENDENCIES.

Facciamo un esempio:
SQL> select CLAIM_NUM, CLAIM_AMT, CLAIM_BAL, ROWID, ORA_ROWSCN from claim; CLAIM_NUM CLAIM_AMT CLAIM_BAL ROWID ORA_ROWSCN ---------- ---------- ---------- ------------------ ---------- 1 100 0 AAAdsYAAEAAAAD0AAA 1070257362 2 200 99 AAAdsYAAEAAAAD0AAB 1070257362 3 300 0 AAAdsYAAEAAAAD0AAC 1070257362 4 400 350 AAAdsYAAEAAAAD0AAD 1070257362 5 500 0 AAAdsYAAEAAAAD0AAE 1070257362 6 600 295 AAAdsYAAEAAAAD0AAF 1070257362 7 700 700 AAAdsYAAEAAAAD0AAG 1070257362 8 800 800 AAAdsYAAEAAAAD0AAH 1070257362 8 rows selected. SQL> update claim set CLAIM_BAL = 1 where claim_num = 1; 1 row updated. SQL> select CLAIM_NUM, CLAIM_AMT, CLAIM_BAL, ROWID, ORA_ROWSCN from claim; CLAIM_NUM CLAIM_AMT CLAIM_BAL ROWID ORA_ROWSCN ---------- ---------- ---------- ------------------ ---------- 1 100 1 AAAdsYAAEAAAAD0AAA 1070257362 2 200 99 AAAdsYAAEAAAAD0AAB 1070257362 3 300 0 AAAdsYAAEAAAAD0AAC 1070257362 4 400 350 AAAdsYAAEAAAAD0AAD 1070257362 5 500 0 AAAdsYAAEAAAAD0AAE 1070257362 6 600 295 AAAdsYAAEAAAAD0AAF 1070257362 7 700 700 AAAdsYAAEAAAAD0AAG 1070257362 8 800 800 AAAdsYAAEAAAAD0AAH 1070257362 8 rows selected. SQL> commit; Commit complete. SQL> select CLAIM_NUM, CLAIM_AMT, CLAIM_BAL, ROWID, ORA_ROWSCN from claim; CLAIM_NUM CLAIM_AMT CLAIM_BAL ROWID ORA_ROWSCN ---------- ---------- ---------- ------------------ ---------- 1 100 1 AAAdsYAAEAAAAD0AAA 1201770241 2 200 99 AAAdsYAAEAAAAD0AAB 1201770241 3 300 0 AAAdsYAAEAAAAD0AAC 1201770241 4 400 350 AAAdsYAAEAAAAD0AAD 1201770241 5 500 0 AAAdsYAAEAAAAD0AAE 1201770241 6 600 295 AAAdsYAAEAAAAD0AAF 1201770241 7 700 700 AAAdsYAAEAAAAD0AAG 1201770241 8 800 800 AAAdsYAAEAAAAD0AAH 1201770241 8 rows selected. SQL> create table claim_rowdep ROWDEPENDENCIES as select * from claim; Table created. SQL> select CLAIM_NUM, CLAIM_AMT, CLAIM_BAL, ROWID, ORA_ROWSCN from claim_rowdep; CLAIM_NUM CLAIM_AMT CLAIM_BAL ROWID ORA_ROWSCN ---------- ---------- ---------- ------------------ ---------- 1 100 1 AAAlQ9AAEAAAAIEAAA 1201772166 2 200 99 AAAlQ9AAEAAAAIEAAB 1201772166 3 300 0 AAAlQ9AAEAAAAIEAAC 1201772166 4 400 350 AAAlQ9AAEAAAAIEAAD 1201772166 5 500 0 AAAlQ9AAEAAAAIEAAE 1201772166 6 600 295 AAAlQ9AAEAAAAIEAAF 1201772166 7 700 700 AAAlQ9AAEAAAAIEAAG 1201772166 8 800 800 AAAlQ9AAEAAAAIEAAH 1201772166 8 rows selected. SQL> update claim_rowdep set claim_bal = 0 where claim_num = 1; 1 row updated. SQL> select CLAIM_NUM, CLAIM_AMT, CLAIM_BAL, ROWID, ORA_ROWSCN from claim_rowdep; CLAIM_NUM CLAIM_AMT CLAIM_BAL ROWID ORA_ROWSCN ---------- ---------- ---------- ------------------ ---------- 1 100 0 AAAlQ9AAEAAAAIEAAA 2 200 99 AAAlQ9AAEAAAAIEAAB 1201772166 3 300 0 AAAlQ9AAEAAAAIEAAC 1201772166 4 400 350 AAAlQ9AAEAAAAIEAAD 1201772166 5 500 0 AAAlQ9AAEAAAAIEAAE 1201772166 6 600 295 AAAlQ9AAEAAAAIEAAF 1201772166 7 700 700 AAAlQ9AAEAAAAIEAAG 1201772166 8 800 800 AAAlQ9AAEAAAAIEAAH 1201772166 8 rows selected. SQL> commit; Commit complete. SQL> select CLAIM_NUM, CLAIM_AMT, CLAIM_BAL, ROWID, ORA_ROWSCN from claim_rowdep; CLAIM_NUM CLAIM_AMT CLAIM_BAL ROWID ORA_ROWSCN ---------- ---------- ---------- ------------------ ---------- 1 100 0 AAAlQ9AAEAAAAIEAAA 1201772868 2 200 99 AAAlQ9AAEAAAAIEAAB 1201772166 3 300 0 AAAlQ9AAEAAAAIEAAC 1201772166 4 400 350 AAAlQ9AAEAAAAIEAAD 1201772166 5 500 0 AAAlQ9AAEAAAAIEAAE 1201772166 6 600 295 AAAlQ9AAEAAAAIEAAF 1201772166 7 700 700 AAAlQ9AAEAAAAIEAAG 1201772166 8 800 800 AAAlQ9AAEAAAAIEAAH 1201772166 8 rows selected.

Come si vede dal ROWID i dati stanno tutti nello stesso blocco, mentre il ROWSCN cambia per tutto il blocco nella tabella claim e solo per la riga interessata dall'update nella tabella claim_rowdep.

Non è possibile aggiungere ROWDEPENDENCIES alla tabella già creata, bisogna farlo alla creazione: la clausola infatti comporta che ogni riga aumenti le proprie dimensioni di 6 bytes.

Tornato da USA

2008-05-26T20:52:00.000+02:00

Sono tornato domenica da una trasferta di lavoro in USA, per conoscere i miei nuovi colleghi d'oltreoceano e fare un po' di team-building con il mio omologo americano dell'azienda che abbiamo comprato.

Probabilmente per lavoro avrò a che fare, prima o poi, anche col mondo SQL Server, di cui ho visto qualche utilizzo. Per ora non so che cosa dire, il mondo dei wizard mi è sconosciuto, ma ammetto che la comodità di impostare ad esempio un backup solo con il mouse e con un'ottima interfaccia grafica non è trascurabile. Manca solo SQL Server per Linux :-)

Una giornata l'ho spesa a spiegare al mio collega USA come funziona RMAN, con una dimostrazione pratica di recovery. I suoi occhi brillavano, così come quando gli ho mostrato Data Pump con l'esportazione del "suo" database in 10 minuti, quando con export normale ci metteva 1 ora e mezza (ma non ho visto lo script che usava).

Mentre ero via è arrivato intanto il kit Oracle del certificato OCP 10g, con la tesserina e il diploma. Sono soddisfazioni, anche se preferirei avere anche una maglietta e un set di adesivi per la moto :-)

Oracle con una mail strana mi invita all'OpenWorld 2008 a S. Francisco. Ho qualche mese di tempo per convincere il mio capo della "necessità" della mia visita a S. Francisco, chissà forse in concomitanza con un altro viaggio in USA, ma si sa noi personaggi dell'IT non viaggiamo molto come i commerciali. Anzi praticamente non viaggiamo mai.

Una novità sulle certificazioni Oracle: Oracle Certification E-Magazine.
Le novità sono molteplici:

L'OCA 11g viene conseguita con 2 esami e non più uno come 10g
L'OCP 11g può essere conseguito come upgrade da 10g OCP ma anche da 9i OCP
C'è una nuova certificazione per il database: SQL certified expert

Cost-based Oracle cap. 2: le statistiche di sistema

2008-05-04T22:24:00.000+02:00

Sto leggendo il libro "Cost-based Oracle" di Jonathan Lewis.
Pensavo di dedicare un post ad ogni capitolo, ma non riesco a riportare tutte le cose interessanti che leggo; più realisticamente proverò a commentare i passi più importanti.

Oggi vi volevo parlare delle statistiche di sistema Oracle 10g. Non intendo le statistiche sugli oggetti di SYS e compari, e nemmeno le statistiche sulle fixed tables, ma su un gruppo di misure che l'optimizer può utilizzare per il suo lavoro.
Tra queste sono comprese la velocità della CPU, il tempo di lettura a singoli blocchi, il tempo di lettura multiblocco.
I valori ricavati dalle misure vengono inseriti nella tabella SYS.AUX_STATS$, che tra l'altro non ha sinonimi.

La tabella SYS.AUX_STATS$ si presenta più o meno così, dopo la creazione di un database:
SQL> select SNAME, PNAME, PVAL1 from sys.aux_stats$ where SNAME = 'SYSSTATS_MAIN'; SNAME PNAME PVAL1 ------------------------------ ------------------------------ ---------- SYSSTATS_MAIN CPUSPEEDNW 1116.77078 SYSSTATS_MAIN IOSEEKTIM 10 SYSSTATS_MAIN IOTFRSPEED 4096 SYSSTATS_MAIN SREADTIM SYSSTATS_MAIN MREADTIM SYSSTATS_MAIN CPUSPEED SYSSTATS_MAIN MBRC SYSSTATS_MAIN MAXTHR SYSSTATS_MAIN SLAVETHR 9 rows selected.
Si può notare come i valori di *READTIM e MAXTHR, tra i più interessanti, non siano valorizzati; inoltre i valori di IOSEEKTIM e IOTFRSPEED sono sempre uguali, anche per altri database non RAC.

Questa tabella viene popolata dalla procedura DBMS_STATS.GATHER_SYSTEM_STATS(). Può lavorare in due gathering_mode: NOWORKLOAD e a intervalli.
Nel primo caso la procedura misura le performance di I/O del sistema, determinando i valori di cpuspeednw, ioseektim, iotfrspeed.
Nel secondo caso si può far partire la misura con START e fermarla con STOP, scegliendo così un periodo di carico di lavoro tipico, altrimenti è possibile specificare INTERVAL con l'intervallo, misurato in minuti, trascorso il quale la misura viene terminata.

Alla fine delle misure l'aspetto potrebbe essere più o meno questo:
SQL> select SNAME, PNAME, PVAL1 from sys.aux_stats$ where SNAME = 'SYSSTATS_MAIN'; SNAME PNAME PVAL1 ------------------------------ ------------------------------ ---------- SYSSTATS_MAIN CPUSPEEDNW 1606.781 SYSSTATS_MAIN IOSEEKTIM 7.469 SYSSTATS_MAIN IOTFRSPEED 52290.723 SYSSTATS_MAIN SREADTIM 5.912 SYSSTATS_MAIN MREADTIM 2.651 SYSSTATS_MAIN CPUSPEED 1614 SYSSTATS_MAIN MBRC 10 SYSSTATS_MAIN MAXTHR 105472 SYSSTATS_MAIN SLAVETHR 9 rows selected.

A che cosa serve tutto ciò? Le statistiche di sistema vengono utilizzate dal cost-based optimizer per determinare il miglior piano di esecuzione basandosi anche sul costo della CPU e della modalità di I/O (signolo blocco o multiblocco).

Manca ancora il costo di lettura dalla cache, ovvero la stima del costo basata sulla probabilità che un determinato blocco si ritrovi già in cache; ciò dipende soprattutto dalle statistiche derivabili da V$SEGSTAT, che misura l'attività relativa ai segmenti (dati e indici scritti su disco). Dovrò fare delle prove su 11g per vedere se ciò è stato implementato.

Ruoli delle istanze nei cluster RAC

2008-04-16T21:54:00.000+02:00

Continuiamo la serie dei post sul RAC a due nodi.

Stavolta mi è capitato di provare il parametro ACTIVE_INSTANCE_COUNT.

Con il RAC a due nodi è possibile specificare l'esistenza di una istanza primaria e di un'istanza secondaria.
Impostando il parametro ACTIVE_INSTANCE_COUNT a 1, solo nell'spfile, si impone che, al riavvio successivo del database, la prima istanza che monta il database diventi l'istanza primaria, mentre l'altra diventi ovviamente la secondaria.
Si può controllare lo stato delle istanze dalla colonna INSTANCE_ROLE di GV$INSTANCE, che assumerà i valori PRIMARY_INSTANCE e SECONDARY_INSTANCE.

Il risultato è che tutte le connessioni verranno dirette verso l'istanza primaria, mentre la seconda continuerà a rifiutare connessioni finché la prima istanza rimarrà attiva.

Anche i servizi RAC vengono avviati sull'istanza primaria, come se la secondaria fosse spenta.

Qual è il vantaggio? Non si trova molto sui manuali o su internet, comunque da questo articolo si deduce che il failover delle connessioni può essere più veloce.
Ho fatto una prova, ma personalmente non lo userei mai.

1Z0-040: missione compiuta

2008-04-12T13:54:00.002+02:00

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

2008-03-27T22:10:00.000+01:00

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!

2008-03-19T19:33:00.000+01:00

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:

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

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

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

lo switch
i due cavi di rete
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:

Shutdown di una delle due istanze, più o meno volontario
Reset o shutdown software di un server
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

2008-03-05T21:22:00.000+01:00

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

2008-02-25T09:29:00.007+01:00

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

2008-01-27T10:52:00.000+01:00

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

2008-01-18T22:29:00.000+01:00

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

2008-01-16T21:20:00.000+01:00

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:

il numero dei record nella tabella ROUT e nella RSR

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

2008-01-09T22:14:00.000+01:00

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

2008-01-07T21:58:00.000+01:00

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

2007-12-26T10:11:00.000+01:00

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

2007-12-18T21:19:00.000+01:00

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:

Il protocollo di scambio dati tra scheda madre e USB è assai inefficiente

La HIGH redundancy è un carico troppo elevato per le chiavette

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

2007-12-09T14:02:00.000+01:00

"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

2007-12-02T16:48:00.000+01:00

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:

Il throughput in MB/s

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

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

2007-11-29T20:57:00.000+01:00

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

2007-11-25T11:19:00.000+01:00

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

2007-11-20T22:31:00.000+01:00

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

2007-11-19T22:08:00.000+01:00

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

2007-11-18T22:03:00.000+01:00

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

2007-11-14T22:16:00.000+01:00

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

2007-11-13T08:39:00.000+01:00

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

2007-11-05T19:03:00.000+01:00

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

2007-10-25T21:44:00.000+02:00

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)

2007-10-24T21:24:00.000+02:00

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

2007-10-22T22:00:00.000+02:00

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:

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

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.

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

2007-10-21T21:47:00.000+02:00

È 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

2007-10-16T21:20:00.000+02:00

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)

2007-10-13T16:02:00.000+02:00

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

2007-10-11T21:01:00.000+02:00

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:

Non viene usato il filesystem, quindi non ci sono limiti fisici alle dimensioni dei file trasferiti

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

Si possono usare tutte le possibilità offerte dal tar

Lo stream di dati è criptato

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

2007-10-08T16:15:00.000+02:00

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

2007-08-27T09:43:00.000+02:00

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

2007-08-24T21:26:00.000+02:00

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

2007-08-22T21:02:00.000+02:00

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

2007-08-21T21:03:00.000+02:00

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

2007-08-20T21:21:00.000+02:00

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

2007-08-06T21:21:00.000+02:00

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

2007-07-27T09:01:00.000+02:00

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

2007-07-12T22:55:00.000+02:00

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.