Category Archives: ASM

ACFS y ASM Preferred Read

Desde la 12c Oracle esta potenciando de manera considerabe el ACFS. Desde la 12.1 es posible ya alojar los ficheros de la base de datos sobre este Filesystem que corre por encima de ASM. Si no me equivoco ODA (Oracle Database Apliance) por defecto crea la base de datos sobre ACFS y Exadata tabmbien lo soporta.

Desde principios del año he estado ayudando a un cliente a migrar unos RAC que tiene de 11.2.0.4 a 12.1.0.2. Le comenté al cliente acerca de ACFS que sería buena opción para ellos por el mero hecho de que prefieren ver los ficheros con los comandos de sistema operativo, es buena opcion porque el origen era Linux y ACFS en Linux funciona realmente bien. En AIX no lo tengo muy claro porque he tenido varis episodios de problemas de rendimiento de ACFS sobre AIX y despues de parches y parches siguen sin funcionar como uno desee.

Pues bien, todos los RAC de este cliente utiliza mirroring de ASM por su definicion de arquitectura, todos los datos se escriben a dos cabinas de discos para tener una redundancia fisica. Estaban utilizando extensivamente los Preferred Reads de ASM en 11.2 y teniamos dudas de que si esta funcionalidad funciona con ACFS, teniamos dudas porque es un Filesystem Posix y no teniamos muy claro si las lecturas se podia redireccionar como queremos.

Hice unas pruebas en una maqueta y comprobé que si puede usar Preferred Read el ACFS.

 

Diskgroup ACFSDATA02 con dos Failgroups, X1_ACFSDATA02 y X2_ACFSDATA02. Las pruebas se han lanzado desde el nodo 2 y este es el resultado:

 

Antes de generar lecturas:

select inst_id, GROUP_NUMBER,DISK_NUMBER,FAILGROUP,NAME,READS,WRITES from gv$asm_disk where GROUP_NUMBER = 6 order by inst_id, FAILGROUP, name

   INST_ID GROUP_NUMBER DISK_NUMBER FAILGROUP     NAME                    READS     WRITES
---------- ------------ ----------- ------------- ------------------ ---------- ----------
         1            6           0 X1_ACFSDATA02 X1_ACFSDATA02_0001         17          1
         1            6           1 X2_ACFSDATA02 X2_ACFSDATA02_0001          6          1
         2            6           0 X1_ACFSDATA02 X1_ACFSDATA02_0001         46       5640
         2            6           1 X2_ACFSDATA02 X2_ACFSDATA02_0001       2422       5640

Despues de generar las lecturas:

select inst_id, GROUP_NUMBER,DISK_NUMBER,FAILGROUP,NAME,READS,WRITES from gv$asm_disk where GROUP_NUMBER = 6 order by inst_id, FAILGROUP, name

   INST_ID GROUP_NUMBER DISK_NUMBER FAILGROUP     NAME                    READS     WRITES
---------- ------------ ----------- ------------- ------------------ ---------- ----------
         1            6           0 X1_ACFSDATA02 X1_ACFSDATA02_0001         17          1
         1            6           1 X2_ACFSDATA02 X2_ACFSDATA02_0001          6          1
         2            6           0 X1_ACFSDATA02 X1_ACFSDATA02_0001         46       5640
         2            6           1 X2_ACFSDATA02 X2_ACFSDATA02_0001       3252       5941

Podemos observar que las lecturas se ha reliazado integramente sobre el Failgroup X2_ACFSDATA02_0001, pasando de 2422 lecturas a 3252.

 

 

 

Advertisements

ACFS en RHEL/OEL 6.x unrecognized file system type 0x61636673

En RHEL/OEL 6.5 (posiblemente tambien en 6.4) al hacer un tail de un fichero ubicado en ACFS podemos observar este warning:

unrecognized file system type 0x61636673

Parece que es por una funcionalidad nueva de tail que viene con coreutil 8.2 y 8.4 de Linux, hace una comprobacion del tipo de filesystem y ACFS al no estar presente en fs.h el tail no lo reconoce.

Es un warning que se puede ignorar tranquilamente

WARNING: Waited 15 secs for write IO to PST y _asm_hbeatiowait

Hace un par de meses estuve realizando unas pruebas de Cluster de 11gR2 con ASM configurado en un cliente, una de las pruebas era perdida de caminos a la cabina de discos.

El software de Multipath utilizado es MPIO de IBM AIX 6.1 y la version de Grid Infrastructure es 11.2.0.3.6 + el parche 10109915, la prueba falló porque ASM detectaba perdida de I/O a los 15 segundos considera que los discos eran inaccesibles.

Los errores son (en traza de gmon y alert):

WARNING: Waited 15 secs for write IO to PST disk 0 in group x

Despues de este error es probable que desmonte el Disk Group (aunque tenga normal redundancy el Disk Group), en una de las pruebas que hice la instancia de la base de datos cayó.

Según la experiencia esto no pasaba antes, despues de darle vueltas y abrir un SR con soporte el problema era que en el parche 10109915 se introdujo el parametro _asm_hbeatiowait que tiene un valor por defecto de 15 segundos mientras tanto MPIO de AIX espera 30 segundos antes de dar como muerto un camino de multipath. El workdaround is aumentar de 15 a 35_asm_hbeatiowait de esta manera ASM espera a la capa de Multipath antes de caerse.

Como se puede observar las pruebas que se realiza para validar un Cluster puede que no sean validas por una simple introduccion de un parche one-off, creo que introduccion de tal funcionalidad merece una nota oficial y asi le hice saber al analista de soporte y acaban de publicar esta nota:

ASM Disks Offline When Few Paths In The Storage Is Lost (Doc ID 1581684.1)

Por qué he dejado de usar ASMLib

Desde hace ya casi un año que he dejado de instalar ASMLib para las instalaciones de ASM en Linux. Basicamente son tres razaones:

1. Oracle deja de publicar los binarios de ASMLib para Red Hat Enterprise 6
2. ASMLib depende de la version de kernel
3. ASMBLib no soporta resize de los discos

Hay muchas implantaciones de Red Hat Enterprise y no creo que cambié de tendencia a medio plazo y Red Hat no parece que quiera publicar ASMLib como hace Suse.

Actualizar la versión de kernel obliga a actualizar ASMLib, no es que sea un trauma pero para los clientes si lo es.

Por mucho que he buscado no he encontrado la forma de poder hacer un resize de un disco bajo control de ASMLib. El propio ASM da la facilidad de poder ejecutar un resize de los discos y Linux es capaz de reconocer un disco ampliado de la cabina sin embargo la capa entre Linux y ASM, ASMLib no tiene la opcion de resize. Hay una opción no documentada que es usar kfed y modificar el metadata de los discos pero no creo que sea el camino a seguir.

Por ultimo, tampoco he notado mucha diferencia en rendimiento entre un sistema que usa ASMLib y otro no…

Restart RMAN Duplicate RAC/ASM to Single Instance/ASM

Recientemente he tenido la oportunidad de realizar un servicio de unos dias de refresco de entorno con RMAN.

La base de datos origen esta en RAC 10gR2 de dos nodos sobre ASM y ocupa 2TB. El objetivo es refrescar entorno de QA periodicamente, un par de veces al mes con datos de produccion, QA es un Single Instance con ASM.

Si no recuerdo mal Oracle 9i se introdujo la funcionalidad Restore Optimization, esta funcionalidad permite rearrancar un restore fallido sin tener que restaurar todos los datafiles (esquiva los que ya estan restaurados), muy util cuando tienes que restaurar un tamaño considerable y por cualquier error falla. El caso es que esta funcionalidad no funciona con ASM o mejor dicho Oracle Managed Files (ASM funciona con OMF) porque los nombre de los datafiles son autogenerados, cada vez que se ejecuta un restore siempre genera un nombre nuevo y esto impide que se detecte datafiles que ya estan restaurados y provoca duplicados de datafiles y sobre todo perdida de tiempo. Esto es por el bug 5683952 (pone fixed in 10.2.0.2 pero me parece que no es verdad).

El workaround es forzar los nombre de los datafiles que sean user managed files especificando set newname en el duplicate, esto generara un nombre estatico que a su vez se convierten en alias de ASM que apunta a los datafiles, por ejemplo

SET NEWNAME FOR DATAFILE 1 TO ‘+DG_DATA/BST/system01.dbf’;

+DG_DATA/BST/system01.dbf apunta a +DG_DATA/BST/datafile/system.262.688916473

Pero a nivel de diccionario de datos apunta a +DG_DATA/BST/system01.dbf y esto habilita Restore Optimization.

Por cierto hace poco escribi sobre backup de RMAN a discos de SATA que tiene un throughput de 20MB, en este caso el backup iba a cinta…. a una media de 100MB por segundo, flipo con la velocidad de los discos de SATA (ó los que cofniguran la cabina). Me inclino mas a segundo porque tengo discos SATA en mi PC y un RAID 0 de dos discos de 320GB da mucho mejor rendimiento…. No entiendo mucho de cintas pero creo que no hace falta ser un experto para saber que algo no esta bien 🙂

11gR2 calentando motores y ACFS

La llegada inminente de Oracle 11gR2 (en fase de Beta) va despejando las dudas acerca de ASM como Cluster Filesystem.
El nombre final sera ACFS y estara disponibile inicialmente para Linux.

Sera un journal con un volume manager y soportara snapshots a nivel de filesystem. Son funcionalidades que carece OCFS2 (aunque mucha gente monta OCFS2 sobre LVM que sepan que no esta soportado y tiene peligro de corrupciones)

Soportará todo tipo de ficheros.

USM, nuevo nombre de ASM?

Revisando unas notas de SAP para Oracle en una de ellas aparece la sigla UNIVERSAL STORAGE MANAGEMENT previsto para Oracle 11g Release 2. Parece que es la siguiente generacion de ASM, de momento hay poca informacion aunque he oido rumores que ya se hizo una demo en el Open World 2008.

Especulando con la fecha de salida de 11.2, viendo los releases anteriores, el intervalo de fechas entre ellas y las fechas de soporte de la penultima version, creo que como tarde seria el segundo trimestre del 2009 supongo que antes ya habra salido alguna informacion acerca del “USM”, todo indica que sera un Cluster Filesystem, carpetazo a los tipicos problemas de UTL_FILE sobre RAC.