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

Bigfile Tablespace no es para Oracle 10g

El problema de un Bigfile es el backup & restore.

En el mundo real un backup de un fichero de 1.8TB (le esta pasando a un colega) a una cabina de discos SATA tarda 23 horas, hay dos problemas aqui:

1. Los discos no deben de estar muy bien configurados, un throughput de 20MB/seg en un backup sin compresión es pésimo.
2. Antes de Oracle 11g RMAN solo puede paralelizar a nivel de datafiles, cada canal gestiona un datafile y no un trozo como en 11g en el cual se le puede especificar la clausula “SECTION SIZE” para paralelizar la operación a un nivel mas granular.

Considerando que la base de datos (RAC de 4 nodos) ocupa 3TB y el backup de 1.2TB tarda unas 6 horas porque estos al ser datafiles más pequeños y numerosos se paralelizan sin problemas tanto a nivel de datafiles como nodos de RAC. Pero el tiempo de backup se dispara por la existencia de un Bigfile. En mi opinión hay que pensarselo dos veces antes de optar por los Bigfiles en la versión 10g a no ser que no se pueda manejar 64K datafiles de 128G cada uno (con db_block_size a 32).

Sería menos problemático con las tecnologias tipo Split Mirror ó Snapshots con VTL sin embargo tampoco sería perfecto. Sería muy interesante conocer más ejemplos reales de bases de datos de considerable tamaño y que utilicen Bigfiles.

Cuando no tienes que tocar algo que no lo conoces

Hace unos 7 años cuando todavia no usaba de manera muy extensiva RMAN hice un script de backup para Oracle sobre Linux. Desde hace unos 5 años solamente hago backups con RMAN y el script este ya lo tengo como una reliquia en mi repositorio de scripts varios.

Hace unos dias (un fin de semana) tuve que acudir urgentemente a un cliente el cual estuve en el año 2003 y no he vuelto a estar. En su dia deje este script para que puedan hacer sus backups en caliente. Cuando llegue ví que estaban todos los archive logs desde el último backup y los backups de los 3 últimos dias. Pensé que esto va a ser chupado, restore, recover y pacasa. Empecé realizando el restore, como el script generaba un restore.sh era simplemente ejecutarlo. Una horita para el restore y empece a ejecutar el proceso de recover para mi sorpresa es que al intentar aplicar el recover de primer archive log salió un error quejandose de que los datafiles del tablespace de UNDO son más recientes que el fichero de control. Improbable, impensable e imposible porque acabo de restaurar todo incluido el fichero de control! (alguien intento hacer recover antes de que llegara y se jodio los ficheros de control actuales)

Empecé a ver las fechas de modificación de los datafiles de UNDO y comparando con el resto y efectivamente los datafiles de UNDO eran 6 horas mas recientes que el backup. Revisando el directorio donde se guardaba todos los backups me di cuenta que no existia los datafiles de UNDO, no me lo podia creer, me entró la idea de que entregue un script defectuoso al cliente hace 6 años y me sentía responsable de su situación sin embargo tampoco me cuadraba porque el script lo tenía puesto en varios clientes donde se han hecho recover con exito. Eche un vistazo el fichero de alert (que no se ha tocado en los ultimos 6 años) y me di cuenta que “alter tablespace undotbs1 begin backup” se dejó de ejecutarse el 30 de abril de 2004 (y la plataforma empezó a funcionarse desde 2003). Eso indicaba que alguien había modificado el script sin tener mucha idea de lo que estaba tocando.

En el script se invoca una función (Obtain_data_files) para obtener los datafiles a copiar, es una query contra dba_data_files y dba_tablespaces y se debe de copiar todos aquellos tablespaces que no sean del tipo TEMPORARY. Pues bien algún estimado cambió la condición de “where b.contents != ‘TEMPORARY’” a “where b.contents = ‘PERMANENT’” y el UNDO precisamente no se considera PERMANENT sino UNDO. Asi que desde esa modificación no se ha vuelto a hacer backups de UNDO durante los últimos 5 años……….

Por suerte se pudo recuperar pero siempre me quedará la duda del por qué de este cambio, sera que no gustaba la palabra temporary?