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!