Backup incremental diferencial VS acumulativo

Esta semana, a raíz de estar trabajando en una migración mediante mecanismo de TTS (Transport Tablespaces) de una versión 11.1.0.7 a 19c nos hemos topado con un error que no había ocurrido anteriormente en otras migraciones del mismo tipo.

El Error

released channel: ch00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/28/2024 13:05:21
ORA-19870: error al restaurar parte de la copia de seguridad /home/oracle/MIGRATE/BBDD/INCREMENTAL_LAST_bbdd_fs33h9ng_1_1
ORA-19638: el archivo /oracle/base_datos/datos01/datafile01.dbf no es lo bastante actual para aplicar esta copia de seguridad incremental
ORA-19642: el SCN de inicio de la copia de seguridad incremental es 13503408614611

Contexto del Procedimiento

Tenemos una base de datos de origen (11.1.0.7) preparada para ser migrada. Todos los tablespaces están en READ-ONLY y hemos realizado todas las exportaciones que necesitábamos (usuarios de aplicación, usuarios de lectura, roles, profiles, objetos, contextos, etc.). También hemos realizado ya la exportación de los tablespaces mediante el método TTS.

En la base de datos destino (19c) ya tenemos restaurado el backup full y todos sus incrementales aplicados, además de los archivelogs.

En este momento, las bases de datos, no están en el mismo punto. No tienen el mismo SCN. Esto es debido porque desde el último backup hasta que he puesto los tablespaces en READ-ONLY ha habido modificaciones en la base de datos.

Para igualar el SCN, necesitamos realizar un último backup incremental en origen, el cual restauraremos para aplicar los cambios en el destino y de esta forma tener los datafiles en el mismo SCN. Esto nos permitirá realizar correctamente la importación de los tablespaces mediante el metodo Tranport Tablespaces TTS.

Hacemos el backup de la siguiente forma: (Especial atención a la parte que está destacada)

rman
connect target /
run
{
 allocate channel ch00 device type disk;
 allocate channel ch01 device type disk;
 backup incremental level 1 format '/home/oracle/MIGRATE/BBDD/INCREMENTAL_LAST_${SOURCE_SID}_%U' tablespace $TABLESPACE_LIST;
 release channel ch00;
 release channel ch01;
}

En nuestro caso, le pasamos un listado de tablespaces, ya que los tablespaces de sistema SYSTEM, SYSAUX, UNDO y TEMP no los incluímos en este proceso.

Cuando ya tenemos las piezas de backup, las copiamos al servidor de destino que contiene la base de datos 19c y realizamos el restore. En este momento, se produce el error anterior.

Entiende por qué ocurre

Por algún motivo que desconocemos, la base de datos origen (11.1.0.7) ha sufrido alguna modificación. Se ha realizado un backup incremental diferencial del que no disponemos. Tampoco ha sido aplicado en destino (19c), por lo que esos cambios en los bloques no los tenemos.

Al haber realizado un nuevo backup diferencial, solo hemos guardado las diferencias entre bloques que había desde el último backup incremental diferencial.

Al intentar restaurar este último backup, RMAN nos dice que nos faltan datos. Nos faltan las diferencias entre bloques de ese backup perdido que no tenemos.

Diferencias entre INCREMENTAL DIFERENCIAL e INCREMENTAL ACUMULATIVO.

Se suele decir, que una imagen vale más que mil palabras. En este caso, se podría decir que se cumple a la perfección.

En esta imagen observamos un gráfico de una programación de Backup Incremental Diferencial.
El domingo se ha realizado un backup full o de nivel 0. El lunes se realiza un incremental diferencial, que solo recoge los cambios que ha habido desde el anterior hasta el momento del lunes en el que ejecutamos el backup.
El martes se realiza un nuevo incremental diferencial que solo recoge los cambios desde el anterior que hicimos el lunes. Si borramos el incremental del Lunes, el resto de incrementales no nos van a servir, porque hemos perdido los datos del lunes que no están en ninguna otra copia.

En esta segunda imagen, podemos ver un gráfico similar, pero con algunas diferencias.
Esta programación es de Backup Incremental Acumulativo. En este caso, se ha realizado un backup full o de nivel 0 el domingo. El lunes se realiza un backup incremental acumulativo que recoge los cambios desde el anterior hasta el momento en el que ejecutamos el backup.
Hasta aquí, todo es similar. La diferencia viene ahora.
El martes, se realiza un nuevo backup incremental acumulativo, pero este no solo recoge los cambios que ha habido desde el lunes hasta el martes, si no que también guarda todo lo anterior desde el último full o nivel 0, es decir, todo lo que había del domingo al lunes (que ya estaba guardado en el anterior incremental) y todo lo que hay del lunes al martes.
De esta forma, si borramos el backup realizado el lunes, no habría ningún problema, ya que el backup del martes, también incluye todos esos cambios en los segmentos que hubo del domingo al lunes.

Un poco más de información oficial de Oracle ➡️ 4.4 RMAN Incremental Backups

Solución

Tras analizar la situación, intentamos a toda costa no tener que empezar de nuevo todo el proceso y volver a comenzar desde el backup full desde el que comenzamos.

Por lo tanto, vemos la posibilidad de realizar en el origen un backup incremental acumulativo que tenga los datos de los últimos cambios, pero también los anteriores que nos faltaban.

Realizamos el backup de la siguiente forma:

rman
connect target /
run
{
 allocate channel ch00 device type disk;
 allocate channel ch01 device type disk;
 backup incremental level 1 cumulative format '/home/oracle/MIGRATE/BBDD/INCREMENTAL_LAST_${SOURCE_SID}_%U' tablespace $TABLESPACE_LIST;
 release channel ch00;
 release channel ch01;
}

Una vez finalizado, copiamos las piezas de backup al servidor de destino que contiene la base de datos 19c.

-rw-r-----   1 oracle oinstall    557M Aug 29 13:00 INCREMENTAL_LAST_bbdd_gs33mac4_1_1
-rw-r-----   1 oracle oinstall    1.0G Aug 29 13:05 INCREMENTAL_LAST_bbdd_gr33mac4_1_1
-rw-r-----   1 oracle oinstall    875M Aug 29 13:21 INCREMENTAL_LAST_bbdd_gt33mbka_1_1
-rw-r-----   1 oracle oinstall    2.4G Aug 29 13:34 INCREMENTAL_LAST_bbdd_gu33mbt8_1_1
-rw-r-----   1 oracle oinstall    1.8G Aug 29 13:41 INCREMENTAL_LAST_bbdd_gv33mcrf_1_1
-rw-r-----   1 oracle oinstall    945M Aug 29 13:58 INCREMENTAL_LAST_bbdd_h033mdip_1_1
-rw-r-----   1 oracle oinstall    1.3G Aug 29 14:03 INCREMENTAL_LAST_bbdd_h133me12_1_1

Al realizar el restore de este nuevo backup acumulativo, en lugar del error anterior, podremos observar algo como esto:

RMAN> 
connected to target database: BBDD (DBID=3213213213)

RMAN> 
using target database control file instead of recovery catalog
allocated channel: ch00
channel ch00: SID=4848 device type=DISK
Starting restore at 01/09/2024 00:00:00

channel ch00: starting datafile backup set restore
channel ch00: specifying datafile(s) to restore from backup set
channel ch00: restoring foreign file /oracle/base_datos/datos01/datafile01.dbf
channel ch00: reading from backup piece /home/oracle/MIGRATE/BBDD/INCREMENTAL_LAST_bbdd_gs33mac4_1_1
channel ch00: restored backup piece 1
channel ch00: restore complete, elapsed time: 00:00:17
Finished restore at 01/09/2024 00:00:18

Tras esto, ya podremos continuar con la migración de nuestra base de datos realizando la importación mediante Transport Tablespaces. 😉

Modo actualización segura en MySQL. Error Code: 1175. You are using safe update mode
ORA_ROWSCN ¿Cómo conocer la fecha y hora de última modificación de una fila dentro de una tabla?

Deja un comentario