digilux.es

Hola a todos, hoy quiero escribir de una de las nuevas funcionalidades de RMAN para la 10g (un poco antiguo porque estamos con la 11g, y hay que empezar a escribir sobre la 11g) que aparece en el capítulo 13 del “Backup and Recovery Advanced Use’s Guide” exactamente en la página 13-24, es usar el “BACKUP INCREMENTAL … FROM SCN”.
¿Cuándo lo utilizo? Pues en mi caso tengo unas cuantas STAND-BY físicas, algunas con un DELAY de 12 horas, y en alguna ocasión a fallado la alarma del DELAY, y como guardo y borro los archive logs del disco tres veces al día, en ocasiones cuando falla la alarma, puedo llegar a encontrarme un DELAY de tres días los lunes, y tendría que recuperar los archive logs de cinta y aplicarlos a la STAND-BY física. Esto te llevaría un tiempo considerable, sobre todo si tienes que pedir a alguien las cintas, dependiendo de la política que tengan, en resumen mucho tiempo.
Ahora en RMAN de la versión 10g, existe esta funcionalidad, que te busca los bloques que han cambiado desde el SCN que le proporcionas y te crea un backup set, del que no deja registro que influya en tus backups de tus políticas para las posibles recuperaciones de la base de datos primaria.

1. Primero tenemos que cancelar la recuperación automática de la STAND-BY en caso que todavía esté activa, y lo hacemos con:

SQL> alter database recover managed standby database cancel;

Database altered.

2. Luego hay que buscar el SCN donde quedó tu STAND-BY, para esto tienes muchas sitios donde buscar, tienes las vistas V$DATABASE, en esta vista puede observar varios *_CHANGE# que reportan varios SCNs (Por cierto esta vista viene de la x$kccdi, y tiene mucha información de la base de datos y de la instancia y sirve por ejemplo para errores como ORA-01503, MAXLOGMEMEBER — dimlm, pero esa es otra historia). Dentro de todos estos SCNs, el que nos interesa es el CHECKPOINT_CHANGE# que según el manual de referencia de la base de datos es el último SCN de un checkpoint. Aquí la consulta con todos los *_CHANGE#:

SQL> select resetlogs_change#, prior_resetlogs_change#, checkpoint_change#,
archive_change#, controlfile_change#, archivelog_change#
from v$database;

RESETLOGS_CHANGE# PRIOR_RESETLOGS_CHANGE# CHECKPOINT_CHANGE# ARCHIVE_CHANGE# CONTROLFILE_CHANGE# ARCHIVELOG_CHANGE#
—————– ———————– —————— ————— ——————- ——————
1 0 45105529788 45105572422 45105572863 45191982127

Tambien podemos buscar en el registro de logs, en la vista V$LOG_HISTORY ó V$LOGHIST, que básicamente tiene la misma información, solo que la primera tiene más, pero las dos vienen de x$kcclh. Aquí, puedes obtener el MAX(NEXT_CHANGE#).V$LOG_HISTORY ó MAX(SWITCH_CHANGE#).V$LOGHIST, que son el mismo campo to_number(lhnxs). x$kcclh. Así que podríamos directamente hacer:

select max(to_number(lhnxs)) mscn
from x$kcclh

MSCN
————-
45105572507

Hay más formas de encontrar el SCN, por ejemplo con la V$ARCHIVED_LOG, solo que tienes que buscar el MAX(NEXT_CHANGE#) de los aplicados.

3. Después de obtener este número, hay que hacer el backup con RMAN, y generar los backup sets, y esto es muy sencillo. En mi caso como trabajo siempre en conexión remota, me creo un shell script y lo ejecuto en desatendido (comando nohup), así no sufro nunca cuando ejecuto algo que puede tardar mucho. Esto desde mi punto de vista es una buena práctica. Siempre pensar en shell scripts para ejecutar hasta lo más mínimo, por ejemplo para parar la base de datos, aun cuando la aplicación esté abajo, o no tenga nadie conectado, incluso cuando revisas que no existen conexiones y se acaba de hacer un checkpoint, incluso en esa situación, que la duración es mínima en cerrar la bbdd, prefiero todo por shell scripts desatendidos. Bueno voy con el mini RMAN script.

rman target / >> EOF

RUN
{
BACKUP DEVICE TYPE DISK INCREMENTAL FROM SCN 45105572507 DATABASE FORMAT ‘{RUTA}/bck_stnd_dss%U’;
BACKUP CURRENT CONTROLFILE FOR STANDBY FORMAT ‘{RUTA}/bck_stnd_ctl ‘;
}

EXIT
EOF

Esto lo he creado en la maquina donde está la base de datos primaria, en un directorio que sé que caben estos backup sets.

4. A continuación copiamos o hacemos que la base de datos STAND-BY vea estos backup sets, en mi caso tengo que copiarlos a otra maquina. Existen casos en que la base de datos STAND-BY está en la misma máquina. Yo copio los ficheros usando scp, pero puedo utilizar cualquier herramienta, ftp por ejemplo.

scp bck_stn* {HOST}:{RUTA DESTINO}

5. El siguiente paso es catalogar los backup sets que hemos copiado en la maquina donde reside la STAND-BY en la base de datos STAND-BY, así que nos conectamos con RMAN y los catalogamos para ello de nuevo con shell script:

rman target / << EOF
catalog start with ‘{RUTA DESTINO}’;
yes
exit
EOF

6. Ahora lo que hay que hacer es la recuperación usando la opción NOREDO, que implica que no va buscar archive logs para aplicar, y después restaurar el STANDBY CONTROLFILE desde el backup del controlfile de la base de datos primaria, antes creado, y de nuevo shell script de todo estos pasos:

rman target / << EOF
RECOVER DATABASE NOREDO;
SHUTDOWN
STARTUP NOMOUNT
RESTORE STANDBY CONTROLFILE FROM ‘{RUTA/FICHERO STAND-BY}’;
SHUTDOWN
STARTUP MOUNT
EXIT
EOF

7. Lo siguiente es revisar como quedaron los SCNs, con la consulta anterior a V$DATABASE ó con V$LOG_HISTORY.

8. Como último paso hay que volver a dejar automática la recuperación de la STAND-BY, en caso que tenga recuperación automática, hay algunos casos en que no se deja automático, sino que se lanza un script nocturno, por posibles sobrecargas del host.

Van a quedar impresionados de lo rápido que son estas recuperaciones. Con unos cuantos pasos en vez de recuperar un gran volumen de archive logs Puede que generes backup sets pequeños, y muy rápidos de aplicar. Todo depende de la cantidad de bloques que cambien con respecto al SCN de la STANDBY. Si tenemos una BBDD de muchas consultas y de pocos cambios, ó se cambian en pocos segmentos, pues salen bastante pequeños los backup sets. Depende de el tipo de trabajo que tiene tu base de datos, lo que si es cierto es que es mucho más cómodo esto que recuperar de cinta tus archive logs. Como último decirte que si no hacen un backup del controlfile para la STANDBY, y lo restauran no funcionará, y esto no aparece en el manual y es bastante importante. No se si es que intuyen que este paso lo haremos, pero si hay que hacerlo.
Espero que lo usen, y que les sirva de ayuda este paso-a-paso de una recuperación de una STANDBY con una nueva funcionalidad de RMAN.
Como adicional decirles que he utilizado una tabla X$, aquí me gustaría decir que hay que tener especial cuidado, ya que consultar alguna de estas tablas puede hacer decaer el rendimiento de tu base de datos, y bastante, así que lo mejor sería no “jugar” mucho con ellas, como por ejemplo la que muestra los latches ó las que contiene las Freelist de la SGA.
Por ultimo pedir disculpas por los posibles fallos haciendo copiar&pegar, y es que cuando es usan “maoyer que” y “menor que” puede que no sea lo que escribo.