La scalabilità di MyISAM secondo Oracle

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

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

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

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

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:

1. Il downtime è minore: non è più necessario fermare il database e i processi per installare il nuovo software.
2. 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

È 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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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.