Oracle ha investito molto, moltissimo nel grid computing; c'è da dire, ad onor del vero, che usa il termine in modo improprio. C'è chi vorrebbe vedere in questo termine un sinonimo di calcolo distribuito, ma il grid computing è qualcosa di diverso: presuppone un'elaborazione distribuita pura, in cui invece di avere una rete dedicata, si sfruttano i tempi di idle di sistemi eterogenei per effettuare un pezzo di un'elaborazione, ovviamente parallelizzabile. Il grid computing secondo Oracle si traduce invece soprattutto nella capacità di allocare le risorse software su tanti piccoli server fisici, che vengono visti logicamente come un unico database.

Dal punto di vista pratico, l'offerta Oracle raccolta sotto questo cappello si traduce in Oracle Fusion Middleware per la scalabilità delle applicazioni, in Oracle RAC (Real Application Clusters) per l'alta affidabilità ed in Automatic Storage Management (ASM) per l'automazione della struttura di storage sottostante, il tutto sotto la console di gestione Enterprise Manager Grid Control. Era del resto poco plausibile che un'azienda che vede il data center costruito intorno al proprio database avesse un'offerta di grid computing puro: abbiamo piuttosto l'attenzione verso i cosiddetti requisiti non-funzionali ovvero, con termini a volte abusati, prestazioni, affidabilità e scalabilità.

Le novità della versione 11g sono concentrate soprattutto in Oracle RAC ed in ASM, e vanno nella direzione di una maggiore automazione, e più in generale della semplificazione nell'uso, della grid Oracle, e nel supporto di maggiori volumi di dati e numero di transazioni. ASM, in particolare, introduce in Oracle 11g un file system clusterizzato integrato, con elevate capacità di I/O asincrono, e la gestione di volumi logici indipendenti da quelli fisici sottostanti. La tecnologia Fast Mirror Resync permette un più veloce recupero dalle failure dei dischi, tenendo traccia delle modifiche da apportare quando il disco tornerà disponibile.

ASM aiuta anche la gestione dei VLDB (Very Large Database), permettendo di gestire, in assenza di mirroring, fino a 40 EB (ExaByte; per intenderci, un ExaByte è un miliardo di GB) di storage, e 4 PB (PetaByte, un milione di GB) per disco ASM: un limite decisamente superiore a quello di 128 TB per singolo file di Oracle. Le unità di allocazione (AU) dei file possono essere specificate in cluster da 1 a 64 MB (con tutte le potenze di 2, in MB, intermedie), mentre tre nuove opzioni del comando ASMCMD permettono di migliorare il recupero di un nodo dopo un crash, di riparare blocchi corrotti su un disco, di effettuare la copia asincrona di file e di semplificare l'elencazione dei dischi ASM in un gruppo.

• Pubblicazioni correlate:
• 01-02-2008 Alla scoperta di Oracle 11g: la sicurezza
• 13-02-2008 Alla scoperta di Oracle 11g: sviluppo di applicazioni
• 20-02-2008 Alla scoperta di Oracle 11g: gestione dei contenuti e servizi di localizzazione
• 27-02-2008 Alla scoperta di Oracle 11g: integrazione e replica di informazioni
• 05-03-2008 Alla scoperta di Oracle 11g: gestione del ciclo di vita delle informazioni
• 12-03-2008 Alla scoperta di Oracle 11g: alta affidabilità
• 19-03-2008 Alla scoperta di Oracle 11g: Business Intelligence e data warehousing
• 26-03-2008 Alla scoperta di Oracle 11g: servizi di rete
• 02-04-2008 Alla scoperta di Oracle 11g: prestazioni e scalabilità
• 30-04-2008 Alla scoperta di Oracle 11g: Real Application Testing
• 07-05-2008 Alla scoperta di Oracle 11g: le Materialized View
• 14-05-2008 Alla scoperta di Oracle 11g: il Cube Partitioning Advisor
• 21-05-2008 Alla scoperta di Oracle 11g: Oracle Data Integrator
• 28-05-2008 Alla scoperta di Oracle 11g: Online Patching