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.

Oracle dejara de soportar Raw a partir de 12g

Hace unos dias Oracle anuncio que dejara de dar soporte a los dispositivos raw en todas las plataformas a partir de Oracle 12g, aun falta pero hay que ir preparando porque aun veo gente que monta raw sobre RAC 10gR2, totalmente innecesario.

Que pasara con OCR y Voting Disk? Hasta ahora, incluido 11gR1, o usas raw o usas un Cluster Filesystem (no es muy habitual CFS por el coste excepto OCFS2), la mayoria optan por raw. Pues si se ha anunciado para 12g preparemos para ver algo nuevo en la 11gR2, saldra alguna funcionalidad para remediar este tema.

No se yo…. creo que va a evolucionar bastante ASM en la Release 2 de 11g…..

Es necesario que las rutas de los discos de ASM sean el mismo en todos los nodos?

Creo que existe bastantes confusiones de ASM respecto a este tema. Muchos son los que creen que si un disco de ASM esta visible en /dev/emcpowerp4 en un nodo pues el resto de los nodos deben verlo en la misma ruta. (Y para manetener la persistencia de los nombre de los discos de Powerpath no es trivial)

Principalmente creo que es porque de momento ASM se utiliza exclusivamente en RAC y como es sabido las rutas de los discos de OCR y Voting Disks si deben ser las mismas en todos los nodos que forma el Cluste, y puede que sea por esto la gente asume la misma teoria deberia de aplicar en los discos de ASM (sea Raw o Block, en Linux). Es algo bastante habitual que veo en los clientes. Incluso algunos me han comentado que no les funciona si no esta en las mismas rutas, algo que dudo porque los metadatos de ASM no dependen de las rutas simplemente estan almacenados en la cabecera de los discos, siempre y cuando ASM tenga permisos de escanear el disco no deberia de haber problemas.

 

He hecho unas pruebecillas con raw sobre Linux x64, en un nodo he creado un disco /dev/raw/raw3 y en el otro nodo lo ve como /dev/raw/raw4, los dos apuntando a una misma LUN de una SAN y funciona. ASM los monta sin problemas.