Uso de RMAN para Respaldos

Recuerdo a mi primer Jefe cuando empec a desempear mi trabajo como DBA, lo que ms me recalc fue mi responsabilidad no slo de poder realizar backups, sino de poder restaurar la informacin de mis backups. Esta responsabilidad es la que me gusta transmitir a todos los DBAs con los cules he interactuado. De nada sirve tener un backup si no vas a poder recuperar la informacin. A menudo me preguntan sobre las formas de respaldos de bases de datos oracle, y siempre respondo que lo mejor es el uso de RMAN. Qu tan complejo puede ser RMAN?, la realidad es que ya configurado es muy sencillo, o en su forma ms simple, sacar un respaldo es cuestin de un comando en 2 palabras: C:\Documents and Settings\Hugo\Escritorio>rman target / Recovery Manager : Release 10.2.0.3.0 - Production on Mi Jul 23 13:21:30 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved.

conectado a la base de datos destino: ORCL (DBID=524232147) RMAN> backup database; Y el restore?

C:\Documents and Settings\Hugo\Escritorio>rman target / Recovery Manager : Release 10.2.0.3.0 - Production on Mi Jul 23 13:22:35 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved.

conectado a la base de datos destino: ORCL (DBID=524232147) RMAN> shutdown abort; RMAN> startup mount; RMAN> restore database; RMAN> recover database; RMAN> alter database open;

Claro es sencillo porque la base de datos est en modo archive, a pesar que no estoy usando un catlogo de RMAN (que sera lo ms recomendable), el restore es muy sencillo. La realidad es que no siempre tenemos este esquema "utpico" a nivel base de datos. En alguna

ocasin me toc clonar la base de datos de un cliente con RMAN, tenan la base de datos en modo Archive, hicieron un hotbackup y al final del da, la informacin que se restaur sobre la instancia de desarrollo estaba corrupta. Lo que sucedi fue lo siguiente: El cliente estaba realizando algunas cargas de informacin sobre sus tablas. El "DBA" para realizar las cargas ms rpidas, decidi usar el mtodo de "Direct Load" (que me pareci muy buena opcin), sobre la tabla alterada con nologging (que me pareci una psima opcin). A la hora de realizar el respaldo, e incluso los archives, no se tena rastro de los insert sobre la tabla; se tenan rastros de los incrementos de extents y del movimiento del HWM. Para ejemplificar lo sucedido podemos hacer lo siguiente con dos sesiones: Primera sesin en SQL*Plus: SQL> alter table prueba nologging; Tabla modificada. SQL> begin 2 for a in 1..100 3 loop 4 insert /*+APPEND*/ into prueba (select substr(object_name,1,3),CREATED,substr(owner,1,3)from dba_objects); 5 commit; 6 dbms_lock.sleep(2); 7 end loop; 8 end; 9 /

y en una sesin de RMAN C:\Documents and Settings\Hugo\Escritorio>rman target / Recovery Manager : Release 10.2.0.3.0 - Production on Mi Jul 23 15:58:03 2008 Copyright (c) 1982, 2005, Oracle. All rights reserved.

conectado a la base de datos destino: HECG (DBID=524232147) RMAN> backup database plus archivelog; Con el comando plus archivelog, nos aseguramos de que todos los archives necesarios para restaurar este backup se incluyan, e incluso realiza un switch log al finalizar y respalda los archives nuevamente. La sesin de SQL*Plus termina, el backup termina y empezamos con el restore:

Ahora, pensando en que tuviramos una falla en ese momento y queremos recuperar, podemos empezar un restore a cierta fecha (que es cuando el respaldo termin): RMAN> shutdown abort; RMAN> startup mount instancia Oracle iniciada Total del rea Global del Sistema Fixed Size Variable Size Database Buffers Redo Buffers base de datos montada RMAN> run { 2> set until time "to_date('23-07-2008 16:01:12','dd-mm-yyyy hh24:mi:ss')"; 3> restore database; 4> recover database; 5> } ejecutando el comando: SET until clause Iniciando restore en 21-JUL-08 canal asignado: ORA_DISK_1 canal ORA_DISK_1: sid=156 devtype=DISK canal ORA_DISK_1: iniciando restauraci+n del juego de copias de seguridad de archivos de datos canal ORA_DISK_1: especificando archivo(s) de datos para restaurar del juego de copias de seguridad restaurando el archivo de datos 00001 en C:\ORACLE\PRODUCT\ORADATA\ORCL\SYSTEM01.DBF restaurando el archivo de datos 00002 en C:\ORACLE\PRODUCT\ORADATA\ORCL\UNDOTBS01.DBF restaurando el archivo de datos 00003 en C:\ORACLE\PRODUCT\ORADATA\ORCL\SYSAUX01.DBF restaurando el archivo de datos 00004 en C:\ORACLE\PRODUCT\ORADATA\ORCL\USERS01.DBF restaurando el archivo de datos 00005 en C:\ORACLE\PRODUCT\ORADATA\ORCL\EXAMPLE01.DBF restaurando el archivo de datos 00006 en C:\CRYPTO\ORCL\DATAFILE\O1_MF_ORCL_42K6N37T_.DBF restaurando el archivo de datos 00007 en C:\PRUEBA01.DBF canal ORA_DISK_1: leyendo desde la parte de copia de seguridad C:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2008_07_21\O1_MF_NNN DF_TAG20080721T093726_4897S8PY_.BKP RMAN> alter database open resetlogs; 289406976 bytes bytes bytes bytes bytes

1290184 272629816 8388608 7098368

Se debe de utilizar un resetlogs ya se us una recuperacin incompleta. Ahora entramos a SQL*Plus y ejecutamos un sql contra la tabla prueba SQL> select count(1) from prueba; select count(1) from prueba * ERROR en lnea 1: ORA-01578: bloque de datos ORACLE corrupto (archivo nmero 4, bloque nmero 10251) ORA-01110: archivo de datos 4: 'C:\ORACLE\PRODUCT\ORADATA\ORCL\USERS01.DBF' ORA-26040: Se ha cargado el bloque de datos utilizando la opcin NOLOGGING La tabla queda en un estado inconsistente porque el diccionario de datos (que s genera redo) registr el crecimiento de bloques en la tabla, pero el objeto como tal no. Hay algunas formas de recuperar algo de informacin si es que los ndices estaban en modo logging, pero creanme... estamos en el peor caso de recuperacin. Dado todo lo anterior, creo que slo se me ocurre una posibilidad para evitar esto durante un backup. Y es uno de los comandos que se suelen usar en dataguard RMAN> run { 2> sql "alter database force logging"; 3> backup database include current controlfile plus archivelog; 4> sql "alter database no force logging"; 5> } Iniciando backup en 23-JUL-08 log actual archivado usando el canal ORA_DISK_1 canal ORA_DISK_1: iniciando juego de copias de seguridad de archive log canal ORA_DISK_1: especificando archive log(s) en el juego de copias de seguridad thread de archive log de entrada=1 secuencia=1 recid=122 marca=660762972 thread de archive log de entrada=1 secuencia=2 recid=123 marca=660763141 thread de archive log de entrada=1 secuencia=3 recid=124 marca=660763187 canal ORA_DISK_1: iniciando parte 1 en 22-JUL-08 ... canal ORA_DISK_1: especificando archivo(s) de datos en el juego de copias de seguridad incluyendo el archivo de control actual en el juego de copias de seguridad manejador de parte=C:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2008_07_23\O1_ MF_NCNNF_TAG20080723T172009_48DQF74D_.BKP etiqueta=TAG20080723T172009 comentario=NONE canal ORA_DISK_1: juego de copias de seguridad terminado, tiempo transcurrido: 00:00:06

backup thread thread backup

terminado en 23-JUL-08 de archive log de entrada=1 secuencia=4 recid=125 marca=660763348 de archive log de entrada=1 secuencia=5 recid=126 marca=660763352 terminado en 23-JUL-08

En este caso estoy incluyendo el controlfile para hacer una especie de recuperacin de desastre (que fue lo que hice realmente como clonado). Al mismo tiempo lanc el insert sobre la tabla prueba a travs del ciclo y con la tabla en nologging. Ya que es una recuperacin de desastre, simularemos la prdida del controlfile, y para poder recuperarlo, necesitamos el DBID de nuestra base de datos (se puede obtener conectndonos a rman o desde v$database). Hay que tener en cuenta el nombre del archivo que guarda el controlfile para poder extraerlo, as como las secuencias de archives que se tienen registradas en el bacjup para restaurar y recuperar. RMAN> shutdown abort; instancia Oracle cerrada RMAN> startup nomount; conectado a la base de datos destino (no iniciada) instancia Oracle iniciada Total del rea Global del Sistema Fixed Size Variable Size Database Buffers Redo Buffers RMAN> SET DBID 524232147; ejecutando el comando: SET DBID RMAN> RUN 2> { 3> RESTORE CONTROLFILE FROM 'C:\ORACLE\PRODUCT\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2008_07_23\O1_MF_NC NNF_TAG20080723T172009_48DQF74D_.BKP 4> } Iniciando restore en 22-JUL-08 canal asignado: ORA_DISK_1 canal ORA_DISK_1: sid=156 devtype=DISK canal ORA_DISK_1: restaurando archivo de control canal ORA_DISK_1: restauracin terminada, tiempo transcurrido: 00:00:04 archivo de salida=C:\ORACLE\PRODUCT\ORADATA\ORCL\CONTROL01.CTL archivo de salida=C:\ORACLE\PRODUCT\ORADATA\ORCL\CONTROL02.CTL archivo de salida=C:\ORACLE\PRODUCT\ORADATA\ORCL\CONTROL03.CTL restore terminado en 22-JUL-08 1290184 226492472 54525952 7098368 289406976 bytes bytes bytes bytes bytes

RMAN> alter database mount; base de datos montada canal liberado: ORA_DISK_1 RMAN> RESTORE DATABASE UNTIL SEQUENCE 5; RMAN> RECOVER DATABASE UNTIL SEQUENCE 5; RMAN> ALTER DATABASE OPEN RESETLOGS;

Y ahora podemos conectarnos a SQL*Plus SQL> select count(1) from prueba; COUNT(1) ---------9813490 Este ejemplo es muy raro que se encuentre en un ambiente productivo, y ms que poder lanzar los comandos sql de "alter database force logging", como DBAs debemos de analizar que nuestros objetos tengan activado el logging. Habr quien diga que los ndices pueden ir en nologging, pero les preguntara... Cunto tiempo tardaran en recrear los ndices que no tuvieran activado el logging? En algn otro Post pondr los scripts que se pueden usar para extraer datos de ndices correspondientes a una tabla perdida.
Publicado por Hugo E. Contreras Gamio en 13:17 Etiquetas: corrupcion, rman

10 comentarios:

cinecomentado dijo... y buena nota, ahora una consulta, tengo una base en PROD y hice un backup con RMAN que me genero los .rman, ahora lo que quiero hacer el hacer el restore de esta en el servidor de DESA, como lo hara con RMAN??? desde ya gracias!!!
25 de julio de 2008 11:26

Hugo E. Contreras Gamio dijo... Lo ms sencillo es el comando duplicate, pondr un post pronto sobre este comando. Tambien puedes simular una recuperacin de desastre, que sera exactamente igual a mi ejemplo (asumi4endo que respaldas a disco), pero copias TODOS tus archivos de un respaldo a las mismas rutas en tu servidor de desarrollo(si no pudes usar las

mismas rutas, deberas de "catalogar" los archivos). Y ya en tu server de desarrollo empiezas con la base no montada, el comando "set dbid" y restore controlfile, etc... o si bien tienes un controlfile que puedes copiar de prod, o que copiaste a la hora de tu respaldo, lo puedes poner en tu ambiente de desarrollo y montas la base de datos y le das "restore database" y "recover database", eso intentar llevar tu base a la sincrona del controlfile. Recuerda al final cambiar el nombre de tu instancia para que lleve el nombre de desarrollo, ya sea con NID o con una recreacin de controlfile.
26 de julio de 2008 21:04

cinecomentado dijo... OK, muchas gracias por la respuesta, Saludos!!

28 de julio de 2008 10:29

Ngl dijo... Antes que nada Felicidadez por Tener este Blog, y otra Felicitacion, por la muy buena explicacion encuanto a este tema. Sabes soy nuevo en el mundo de oracle, y me tiraron al ruedo de Dba, y mi punto principal son los respaldos;Como comentas, es el pilar de todo, de que sirve un respaldo si no se puede utilizar.Confiezo no se nada del RMAN, todos mis respaldos los hago con Export, pero voy a ver como utilziar segun tu explicacion el dicho comando...GRACIAS.
21 de agosto de 2008 12:24

Hugo E. Contreras Gamio dijo... Gracias por el comentario NGL, hay que tener mucho cuidado con los exports, ya que nos son respaldos fsicos, son lgicos y pudieran causarte muchos problemas, te pongo un ejemplo: Una base de datos de 600 GB, el export toma 10 horas, el import toma aproximadamente 40 horas (esto con mucha ayuda de crear ndices en paralelo). Digamos que el respaldo fsico toma 4 horas y el restore 6 horas.
25 de agosto de 2008 20:22

Erika Mdespacher dijo... Hola Hugo. Me gusta mucho tu blog, gracias por compartir con nosotros tus experiencias. Nos podras explicar en algun otro post como obtener la informacin de los ndices si perdimos la tabla? Saludos!

25 de febrero de 2009 11:56

Annimo dijo... Saludos cordiales, aunque no es el tema del foro, favor ayudenme: Estoy empezando mi trabajo de DBA y como para darme la bienvenida veo que los datafile USERS.DBF y SYSTEM.dbf estn daados a causa de que estn en sectores daados del disco duro. Tengo un .DMP sin errores. Pueden darme una mano a ver si la base puedo subirla en otro servidor hasta arreglar el disco daado? Si pueden ayudarme les dejo mi correo cacfhe@hotmail.com
1 de junio de 2009 12:13

Rocio Baez dijo... Ante todo reciba cordiales saludos sr. Contreras, lo felicito por su post, esta bien explicado.
4 de noviembre de 2010 11:30

Annimo dijo... hola, Trabajo con una BDD de oracle y me interesa usar el RMAN como backup. que requisitos necesito? Me han hablado de una mquina independiente, es necesario? Un saludo
12 de enero de 2011 11:53

Lecter23 dijo... Gran manual. Aporto una gua rpida que hice. Espero que les sirva de ayuda. Manual de RMAN Est en castellano, con ejemplos bsicos. Saludos