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.