Prima parte
Automatic Storage Management (ASM) è un filesystem e volume manager integrati prodotto da Oracle per l'utilizzo con il suo database.
ASM è realizzato mediante uno speciale tipo di istanza di database che si differenzia dalle istanze ordinarie perché viene avviata col parametro
INSTANCE_TYPE=ASM
ASM non è pensata per l'accesso da client remoti, bensì sostituisce gli "strati" di sistema operativo che stanno tra l'apertura di un file e i dischi, per tutte le istanze di database che girano sullo stesso server. L'accesso ai file presenti in un volume ASM avviene attraverso un qualsiasi processo server di Oracle.
Volendo continuare un parallelismo tra ASM e le istanze ordinarie, l'istanza ASM è sempre in stato mount, possiede una large_pool le cui dimensioni sono determinate dal numero di dischi e file che deve gestire, non possiede datafile ma solamente il pfile o spfile che contiene i suoi parametri di avvio. L'ORACLE_SID di un'istanza ASM è sempre nella forma +
ASM tende a realizzare l'architettura SAME (stripe and mirror everything), secondo la quale, in estrema sintesi, le migliori performance si ottengono mettendo tutti i file di un database all'interno di un singolo volume RAID10 (leggere il link per informazioni più complete).
ASM memorizza i file in extent di 1 MB per i file di classe datafile o 256 KB per i file di classe redo-log, dove 1 MB viene scelto come dimensione per il coarse-striping e 256 KB per il fine-striping. Ricordiamo che il coarse-striping viene utilizzato per file i cui blocchi vengono scritti anche occasionalmente (come i datafile), in modo da minimizzare la latenza dei dischi che compongono l'array, mentre il fine-striping viene utilizzato per i file che vengono scritti in modo continuo, come i redo-log, in modo da massimizzare il throughput dato dall'utilizzo parallelo dei dischi che compongono l'array.
Con ASM è possibile definire uno o più volumi chiamati disk group, composti da uno o più dischi, con diversi livelli di tolleranza ai guasti. Questi livelli sono tre:
- External redundancy: gli extent non sono mirrorati ma solo bilanciati tra i dischi del disk group
- Normal redundancy: ogni extent possiede una copia di se stesso su un altro disco del suo disk group
- High redundancy: ogni extent possiede due copie di se stesso su due altri dischi del suo disk group
In caso di guasto a un disco, il motore di ASM ridistribuisce le copie superstiti degli extent persi sugli altri dischi del disk group, riottenendo, alla fine del ribilanciamento, il livello di redundancy definito in origine per il disk group.
Per i dischi è possibile definire i failure groups, ovvero raggruppare i dischi aventi in comune un device che può causare l'indisponibilità contemporanea di tutti i dischi del gruppo; si pensi ad esempio a un insieme di dischi collegati a un controller e un altro insieme collegato a un altro controller. Creando un disk group con ridondanza "interna" formato dai due gruppi di dischi, ASM distribuisce gli extent mirror sull'altro failure group per ciascun extent, in modo che non solo i dati siano protetti dall'indisponibilità di un disco, ma anche da quella di tutti i dischi di un failure group.
Ecco i principali vantaggi di ASM:
- Sono abilitati automaticamente direct-I/O e I/O asincrono
- La distribuzione dei dati sui dischi che compongono i disk group viene bilanciata automaticamente
- Il carico di I/O viene bilanciato automaticamente sui dischi di ogni disk group a seconda del tipo di file
Un processo server Oracle distingue un file "ordinario" da un file ASM dal nome del file, che se per il file ordinario è un full path, per un file ASM inizia sempre con "+
Seconda parte
ASM salva la configurazione dei dischi e dei disk group direttamente nell'header di ogni disco; in tal modo basta fornire il parametro ASM_DISKSTRING per dire all'istanza dove cercare i dischi (path dei device per Unix), e il parametro ASM_DISKGROUPS per dire quali disk group devono essere montati all'avvio.
La configurazione di ogni disk group può essere cambiata dinamicamente, finché lo spazio libero lo consente. Ad ogni operazione di aggiunta di uno o più dischi, ASM ribilancia gli extent includendo i nuovi dischi mentre, togliendo uno o più dischi, ASM sposta gli extent dai dischi che sono stati esclusi dal disk group verso gli altri dischi ancora attivi.
Queste operazioni richiedono un certo tempo, ma sono generalmente molto rapide perché molto semplici; la loro velocità o priorità viene controllata dal parametro ASM_POWER_LIMIT, che va da 0 a 11 con default 1.
Sui dischi, come nella tradizione dei filesystem con log, viene salvato anche il disk group log, che permette il recovery al successivo avvio nel caso di crash dell'istanza ASM. Il log è comune a tutte le istanze ASM che montano i dischi, come nel caso di RAC, quindi il recovery viene fatto da un'altra istanza ASM che monta gli stessi disk group.
È fondamentale ricordare sempre che ogni file contenuto in un volume ASM è un file OMF (Oracle-Managed File). Ciò significa che il suo posizionamento nell'albero delle directory è in ultima analisi deciso da Oracle stesso, a seconda dello standard OMF, che ne determina sia la posizione che il nome.
Ad esempio, un datafile sarà sempre posizionato in +DGROUP/datafile/datafilename, dove datafilename è nella forma (fully qualified filename):
+group/dbname/file_type/file_type_tag.file.incarnation
dove file_type_tag varia a seconda del tipo di file e file è il numero del file. Ad esempio per i datafile è il nome del tablespace, per gli archivelog è thread_#_seq_# (v. tabella apposita).
La sequenza:
+group.file.incarnation
è univoca e può essere usata in alternativa.
Quando si usano comandi che richiedono di specificare il nome di un file, con ASM è sufficiente specificare il disk group di destinazione, e Oracle decide posizionamento e nome in automatico (esempio):
SQL> alter tablespace MYTBS add datafile '+DGROUP2' size 1G;
Nonostante OMF, è comunque possibile definire un alias, a tutti gli effetti valido come nome del file, che permette di posizionare almeno virtualmente i file ovunque nel diskgroup, comprese directory personalizzate.
Se viene specificato un nome non OMF all'atto di creazione di un file, verrà creato il file in standard OMF e in più l'alias come specificato nel comando.
I volumi ASM sono accessibili anche da linea di comando tramite ASMCMD, che emula una shell simile a quella Unix. La sua funzionalità più importante è la possibilità di copiare file da ASM a filesystem dell'host e viceversa. Tale funzionalità viene realizzata tramite chiamate al package DBMS_FILE_TRANSFER [da verificare, non trovo riferimenti]. Questa procedura ha delle limitazioni: la dimensione del file deve essere un multiplo di tot 512 KB e di dimensione massima di 2 TB.
Nella versione 11gR2 ASMCMD è un tool completo per la gestione delle istanze ASM, file, disk group, template, e il nuovo volume manager.
(continua prossimamente)
Commenti
ed è il concetto di open che proprio non ci sta a fare niente con l'ASM ed infatti guardando meglio nella documentazione
OPEN - This is not a valid option for an ASM instance.
non so perchè ma mi pareva di ricordare che lo prendesse ugualmente ma che avesse lo stesso comportamento della mount.....
ricorderò male evidentemente, oppure mi sono imbattuto in un altro di quei casi dove a seconda delle versioni e/o livelli di patch viene consentita o meno una sintassi
Ammistratore Rudy: è possibile fare in modo che i commenti relativi ad un articolo restino confinati all'articolo stesso e non vadano anche in Home Page?
Alessandro:
Tu dici: Citazione:
Io replico: fatto sta che però lo status in v$instance.status resta inalterato a STARTED!
Comunque, sì in effetti lo status BLOCKED mi blocca tutte le connessioni via listener (avevo un ricordo errato), anche quelle locali. Credevo che perlomeno le connessioni "AS SYSDBA" venissero risparmiate dal blocco, giusto per consentire di portare l'istanza da STARTED a MOUNT/OPEN. Invece non è così... e non capisco perché.
Apro un thread sulla questione del listener.ora, per avere un parere su come le cose funzionino
L'istanza ASM come sappiamo non monterà mai un database, monta gruppi di dischi, quindi essa verrà sempre mostrata in stato BLOCKED, perchè l'amministrazione di una istanza ASM è intesa da effettuarsi nel server di pertinenza e non da remoto come dicevi tu.
Per poter ovviare a ciò esiste quel flag UR=A che consente di potersi connettere ad un'istanza BLOCKED via listener
dalla 11G il problema pare non si ponga piu perchè l'ASM risulterà UNBLOCKED
come già ti dicevo, l'istanza ASM è started già in nomount ma non monta alcunchè;
perchè i disk groups possano essere visti ed usati dal DB l'istanza ASM deve essere montata...
Rimango comunque dell'opinione che queste distinzioni siano un po' forzate perché stiamo parlando di un filesystem e non di un database, e che si può fare un parallelismo o un'analogia, che non vuol dire identità.
Per tagliare la testa al toro, siccome io non ho in gestione alcuna database con ASM, potreste dirmi che cosa contiene il campo v$instance.status e come cambia eventualmente il valore a seconda che si attivi l'istanza ASM con startup MOUNT o startup OPEN?
se si verifica il listener si vedrà che l'istanza di ASM è sempre in blocked proprio perchè è in mount e monta diskgroups
Ho trovato comunque la nomenclatura un po' confusa e cercavo di dare un maggior rigore alla medesima; d'altra parte chi meglio può giudicare la bontà di uno scritto che quello che ignora l'argomento?
Nel frattempo visto che conosco poco l'argomento
se esegui invece startup mount l'istanza ASM parte montando i diskgroups specificati nel parametro dell'init file ASM_DISKGROUPS
lo startup open ha le stesse funzionalità di startup mount
nella 11G è stata introdotta la possibilità di startup mount restricted che consente di montare in maniera esclusiva i diskgroups specificati in ASM_DISKGROUPS
in linea di massima, non volermene eh :-), credo invece sia proprio giusto anche tecnicamente dire che l'istanza ASM è in mount, perchè è proprio ciò che fa, cioè la sua funzione è esattamente montare diskgroups
le 3 fasi sono state mantenute da Oracle per analogia col concetto già esistente di istanza e per il fatto che una, ASM, parte come giustamente dici con INSTANCE_TYPE=ASM mentre l'altra con INSTANCE_TYPE=RDBMS (il default)
Allora, mi correggo:
Un'istanza si dice che monta un database, è poi il database in stato di mount.
Analogamente un'istanza ASM monta i disk groups di ASM.
Direi che Oracle ha scelto di permettere, se INSTANCE_TYPE=ASM, lo start dell'istanza indifferentemen te con le varie opzioni del comando STARTUP (NOMOUNT, MOUNT e OPEN), o semplicemente con STARTUP (che sottintende il default OPEN). Di fatto è sempre solo un startup d'istanza, cioè non c'è l'apertura di un control file (MOUNT) nè tanto meno l'apertura di un database (OPEN), e infatti l'output del comando è "ASM instance started".
Credo che non sia correttissimo dire: un'istanza ASM è anche tecnicamente in stato di mount, solo perché la si attiva specificando MOUNT.
RSS feed dei commenti di questo post.