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 
June 23, 2009 at 01:17 |
[...] http://lscheng.wordpress.com/2009/06/22/restart-rman-duplicate-racasm-to-single-instanceasm/ [...]
July 9, 2009 at 16:27 |
Hola Li-Shang, nunca te escribo y hoy dos veces en 30 minutos
.
No he probado lo que dices (ahora no tengo clientes con ASM, y lo casero no sería buena prueba), pero una pregunta ¿Probaste usar los alias de los ficheros ASM? Igual estoy diciendo una tontería, porque no tengo todos los detalles de lo que hiciste, pero con mkalias de asmcmd “creo” que es lo mismo, al final están en V$ASM_ALIAS. Hay un ejemplo en utilities:
ASMCMD> mkalias ‘+DG_DATA/BST/system01.454.555341961′ ‘+DG_DATA/BST/system01.dbf’
Si no lo has probado, y lo quieres probar, me cuentas a ver si realmente funciona. Yo no tengo donde
. Y si ya lo has probado y no funciona, pues nada, te agradecería que me lo dijeras.
Un saludo
John Ospino Rivas
July 9, 2009 at 16:57 |
Hola John
No entiendo muy bien lo de mkalias.
Esto es lo que ejecutaba a princpio (hay menos datafiles en este caso para simplificar pero realmente habia 180 datafiles):
RUN {
ALLOCATE AUXILIARY CHANNEL T1 DEVICE TYPE DISK;
SET UNTIL SCN 536418;
DUPLICATE TARGET DATABASE TO BST
LOGFILE
GROUP 1 (‘+DG_DATA/bst/redo01.dbf’) SIZE 50M,
GROUP 2 (‘+DG_DATA/bst/redo02.dbf’) SIZE 50M,
GROUP 3 (‘+DG_DATA/bst/redo03.dbf’) SIZE 50M;
}
Si este duplicate falla por quedar sin espacio si ejecutas otra vez los comandos de arriba el RMAN volvera a restaurar de cero.
Sin embargo si usas el siguiente comando:
RUN {
ALLOCATE AUXILIARY CHANNEL T1 DEVICE TYPE DISK;
SET UNTIL SCN 536418;
SET NEWNAME FOR DATAFILE 1 TO ‘+DG_DATA/BST/system01.dbf’;
SET NEWNAME FOR DATAFILE 2 TO ‘+DG_DATA/BST/undotbs101.dbf’;
SET NEWNAME FOR DATAFILE 3 TO ‘+DG_DATA/BST/sysaux01.dbf’;
SET NEWNAME FOR DATAFILE 4 TO ‘+DG_DATA/BST/undotbs201.dbf’;
SET NEWNAME FOR DATAFILE 5 TO ‘+DG_DATA/BST/users01.dbf’;
SET NEWNAME FOR TEMPFILE 1 TO ‘+DG_DATA/BST/temp01.dbf’;
DUPLICATE TARGET DATABASE TO BST
LOGFILE
GROUP 1 (‘+DG_DATA/bst/redo01.dbf’) SIZE 50M,
GROUP 2 (‘+DG_DATA/bst/redo02.dbf’) SIZE 50M,
GROUP 3 (‘+DG_DATA/bst/redo03.dbf’) SIZE 50M;
}
RMAN detecta los duplicados y salta cuando ve que esta restaurado por ejemplo system01.dbf.
En que paso crees que deberia de poner el mkalias
En el segundo reintento?
Un saludo
–
LSC
July 10, 2009 at 09:11 |
Hola Li,
He leido que los “alias” dan algo de problemas. Pero bueno, pienso que falló y como de antemano sabes que puede pasar en ASM que no use el optimizador, pues después que falló, sería algo así como:
$> asmcmd
ascmd> cd “+DG_DATA/BST/”
asmcmd> mkalias system.262.688916473 system.dbf
…
asmcmd> mkalias users01.757.75757575 users01.dbf
bueno un poco tedioso, pero con un vi y v$datafile se hace más sencillo. Y despues volver a lanzar :
RUN {
ALLOCATE AUXILIARY CHANNEL T1 DEVICE TYPE DISK;
SET UNTIL SCN 536418;
DUPLICATE TARGET DATABASE TO BST
LOGFILE
GROUP 1 (’+DG_DATA/bst/redo01.dbf’) SIZE 50M,
GROUP 2 (’+DG_DATA/bst/redo02.dbf’) SIZE 50M,
GROUP 3 (’+DG_DATA/bst/redo03.dbf’) SIZE 50M;
}
No se si realmente RMAN se de cuenta de estos alias, por eso si tienes la oportunidad y lo puedes probar te lo agradecería, y además quería saber si lo habías hecho alguna vez
.
Nada, era solo una idea, y por probar cosas.
July 10, 2009 at 09:29 |
Eso no funciona tio, si no especificas un nombre que nos gusta (oseas user managed) en el segundo duplicate volverá a generar otro nombre que le da la gana como system.xxx.yyyyyyyyyyyyy. El alias que has creado se lo pasa por el forro a no ser (que no he probado) en el segundo duplicate le pones set newname a los datafiles (y de lo cuales has creado alias) que se ha restaurado en el primer intento para que vea que ya existe un fichero con ese nombre y pasa de restaurar.
Pero para hacer eso pongo set newname desde principio
July 10, 2009 at 11:48 |
OK, si se los pasa por el forro, pues nada. SET NEWNAME. Quería saber justo eso, si RMAN lo tiene en cuenta o no y si dices que no, pues no. Un saludo