Con este espacio pretendo crear un rincón de información relacionda con las bases de datos Oracle, sus funcionalidades, características, noticias.... etc. Interaré hacer pequeños artículos con ejemplos demostrativos para que resulte más fácil leerlos. No dudéis en mandar vuestros comentarios, críticas, aclaraciones... etc.

Información del Autor

Llevo más de diez años trabajando como DBA Oracle en diferentes compañías y desde el 2004 lo hago de forma freelance a través de una sociedad creada por mí, Infor Consult Soluciones (http://www.inforconsult.es). Si tienes cualquier duda, comentario o propuesta que hacerme, no lo dudes.

viernes, 11 de noviembre de 2011

Introducción a ASM

ASM son las siglas de Automatic Storage Management, que es un producto de Oracle que hace de gestor de volúmenes lógicos y/o sistema de ficheros para albergar los ficheros de las bases de datos de la misma compañía. De esta forma, cuando se crea una base de datos Oracle se puede escoger que el almacenamiento para sus archivos sea ASM en vez de un sistema de archivos normal. ¿Pero qué es en realidad ASM? ASM es una instancia Oracle, con su SGA y sus procesos background, que interactúan con las instancias de la base de datos "cliente" para proporcionarle la información necesaria para que pueda leer y escribir en los archivos de datos (datafiles, control files, redo logs, archived logs, flashback logs, spfiles, RMAN backups, Incremental tracking bitmaps y datapumps dumpfiles). Es importante notar que ASM no sirve los bloques de datos a las instancias "cliente", sino que son ellas mismas las que acceden a los discos para leer o escribir. ASM lo único que hace es proporcionarle metainformación sobre dónde leer o escribir los datos.

La instancia ASM, como instancia que es, en vez de montar una base de datos monta disk groups, que son agrupaciones de ASM disks que se usan de forma transparente como si fuera uno sólo. Para verlo con más facilidad, es como si los disk groups fueran tablespaces y los ASM disks, datafiles. Los ASM disks pueden ser LUNs, discos físicos, particiones de discos físicos o incluso volúmenes lógicos aunque Oracle no recomienda esto último porque existiría solapamiento de funciones entre el volume manager instalado y el propio ASM.

ASM puede dar servicio tanto a una base de datos única como a un RAC (Real Application Cluster), que de hecho es donde es más habitual instalarlo. En un RAC, ASM corre en cada nodo y se comunica con el resto de ASMs del RAC a través de la interconexión, pero no nos perdamos en la configuración de RAC y ASM.

Retomando el término disk group, como hemos dicho, un fichero de las bases de datos "cliente" se asigna a un único disk group (un fichero sólo se asocia a un disk group, pero un disk group tiene multitud de ficheros). Las extensiones de los ficheros se distribuyen homogéneamente entre los ASM disks que conforman el disk group equilibrando así la carga de trabajo de los discos y mejorando el rendimiento general del sistema. Normalmente, las instancias usan sólo 2 disk groups para alojar todos sus archivos, una para datos y otra para fast recovery area.

Otra de las funcionalidades de ASM es que permite añadir o eliminar en caliente ASM disks redistribuyendo el contenido del disk group entre los ASM disks que haya. Si se quiere eliminar un ASM disk, antes ASM tiene que redistribuir los datos del disco a eliminar entre los restantes. Si se añade un ASM disk, ASM redistribuye el contenido del disk group entre todos los ASM disks, dado que ahora hay uno más. Lo más interesante es que esta operación la hace ASM en caliente permitiendo a las instancias acceder a sus ficheros mientras se está produciendo el rebalanceo.

Además de poder hacer redistribución (striping), ASM puede hacer redundancia (mirroring) de los datos. Para ello, al crear un disk group se indica el failure group asociado y ASM distribuye cada copia a un fail group distinto. La ídea del fail group es coger los ASM disks del disk group y hacer grupos distintos, los llamados fail groups, de forma que cada grupo esté protegido de los fallos que pueda tener el otro. Ahora bien, en función del tipo de contingencia para la que nos queramos proteger tendremos una agrupaciones u otras. Por ejemplo, un disk group con dos ASM disks podemos definirlo con dos fail groups, cada uno con un sólo disco. Así, la avería de un disco no me dejaría sin datos (tengo otro réplica del afectado). Pero si hay una avería de la controladora de los discos, que es común para ambos, nos quedaríamos sin acceso a los datos. Entonces habría que escoger discos distintos en distintas controladoras. ¿Y si se avería el hardware en donde residen ambas controladoras?. De acuerdo, pues usamos dispositivos de almacenamiento absolutamente distintos. ¿Y si se prende fuego el CPD?.... y así podemos seguir hasta el infinito.

En relación a la redundancia, también se puede hacer réplica de los datos duplicándolos o triplicándolos. Cuando se define el disk group se indica si la replicación será EXTERNAL (sin replicación ASM), NORMAL (se duplican los datos) o HIGH (se triplican los datos). En una configuración NORMAL serán necesarios dos fail groups y en HIGH, tres fail groups.

Por último y para acabar esta breve introducción, sólo decir ASM se puede integrar completamente con OMF (Oracle Managed Files) escribiéndo únicamente el nombre del disk group allí donde se tendría que poner el nombre completo del archivo.

Continuaré escribiendo cosas de ASM, esto es sólo ha sido una breve introducción para coger nociones de qué es y para qué sirve.


Juan Lorenzo Arellano.
Infor Consult Soluciones.
www.inforconsult.es