01 dicembre 2009

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

25 novembre 2009

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.

19 novembre 2009

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.

15 novembre 2009

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

06 novembre 2009

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.

18 ottobre 2009

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.

14 ottobre 2009

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.

24 settembre 2009

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.

15 settembre 2009

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.

09 settembre 2009

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.

07 settembre 2009

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.

02 settembre 2009

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

30 agosto 2009

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.

26 agosto 2009

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!

24 giugno 2009

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.

07 giugno 2009

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.

26 maggio 2009

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 è , 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.

18 maggio 2009

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.

10 maggio 2009

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.

07 maggio 2009

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.

03 maggio 2009

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.

28 aprile 2009

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.

20 aprile 2009

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.

01 aprile 2009

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!

26 marzo 2009

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.

20 marzo 2009

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.

11 marzo 2009

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?

24 febbraio 2009

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.

19 febbraio 2009

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.

25 gennaio 2009

Il listener che ascoltava troppo

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

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

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


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

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

Il problema non è rilevante per quanto riguarda gli utenti locali del server su cui risiedono il database e il listener, in quanto protetti in qualche modo da password, ma perché è possibile controllare remotamente un listener non "blindato" tramite la sua console lsnrctl installata su qualsiasi altra macchina. Esiste infatti la possibilità di specificare il current_listener; vediamolo in opera utilizzando il comando version (ma status va benissimo):
LSNRCTL> version
Connecting to
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=myhost)(PORT=1521)))
TNSLSNR for Linux: Version 10.2.0.3.0 - Production
TNS for Linux: Version 10.2.0.3.0 - Production
Unix Domain Socket IPC NT Protocol Adaptor for Linux: Version 10.2.0.3.0 - Production
Oracle Bequeath NT Protocol Adapter for Linux: Version 10.2.0.3.0 - Production
TCP/IP NT Protocol Adapter for Linux: Version 10.2.0.3.0 - Production,,
The command completed successfully
LSNRCTL> set current_listener ora9ihost
Current Listener is ora9ihost
LSNRCTL> version
Connecting to
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=ora9ihost))(ADDRESS=(PROTOCOL=TCP)(HOST=ora9ihost)(PORT=1521)))
TNSLSNR for Solaris: Version 9.2.0.7.0 - Production
TNS for Solaris: Version 9.2.0.7.0 - Production
Unix Domain Socket IPC NT Protocol Adaptor for Solaris: Version 9.2.0.7.0 - Production
Oracle Bequeath NT Protocol Adapter for Solaris: Version 9.2.0.7.0 - Production
TCP/IP NT Protocol Adapter for Solaris: Version 9.2.0.7.0 - Production,,
The command completed successfully

Il comando VERSION fornisce le informazioni per qualsiasi database (e già queste informazioni a disposizione di tutti potrebbero essere inopportune), ma a noi interessa che con il listener 9i non opportunamente configurato è possibile a questo punto scrivere "stop" e il listener viene spento su ora9ihost.
Per 10g invece questa "feature" viene disabilitata di default, quindi cercando di fermare il listener remotamente si ottiene:
LSNRCTL> stop
Connecting to
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=ora10g))(ADDRESS=(PROTOCOL=TCP)(HOST=ora10g)(PORT=1521)))
TNS-01189: The listener could not authenticate the user

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

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

06 gennaio 2009

Un'interconnect RAC efficiente

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

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

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

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

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

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

Table created.

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

20 rows created.

SQL> commit;

Commit complete.

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

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

20 rows selected.

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

Dopo aver eseguito le istruzioni precedenti su un nodo del cluster, passo al successivo facendo semplicemente
SQL> select * from aob;

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


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

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


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