Error en DUPLICATE. Faltan archivelogs
Vamos a hablar del DUPLICATE. Qué gran herramienta y cuantas horas de trabajo nos ha adelantado este método. ¿Para qué lo soléis usar? Generalmente, los usos más frecuentes que yo he visto es para clonar entornos de producción en entornos de desarrollo, o actualizar estos cada cierto tiempo.
Incluso entornos que tienen automatizado mediante scripts el borrado y duplicado de la base de datos diariamente o semanalmente, para tener los datos productivos actualizados en los entornos de validación/desarrollo/preproducción.
Mi caso no iba a ser diferente, tengo que hacer un DUPLICATE de un entorno productivo a uno de preproducción. Una base de datos bastante grande y con una duración estimada de unas 20-24 horas.
Lo ejecuto, todo funciona correctamente, comienza a realizar los pasos previos y llego hasta el momento en el que restaura correctamente el primer datafile. En ese momento, confío que todo va a ir bien y me desentiendo, hasta el día siguiente que revisaremos el log de la ejecución a ver que tal ha ido.
¿Tus DUPLICATES funcionan bien a la primera? A mi me cuesta. Si no es por una cosa, es por otra, pero siempre hay que pulir algunos errores. Unos por olvido o descuido nuestro como DBA y otros, que se escapan de nuestro área de influencia y no dependen directamente de nosotros, como ha pasado en este caso.
¿Quieres saber qué pasó y como lo solucioné? Sigue leyendo, te puede ahorrar una nueva ejecución y unas cuantas horas de espera.
El Error
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/09/2026 07:58:46
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 375 and starting SCN of 13660706910058El error es muy claro. El proceso de DUPLICATE restaurando los datos, necesita un archivelog con secuencia 375 que no encuentra y no puede continuar.
Después de 22 horas de DUPLICATE y y haber restaurado todos los datafiles, el proceso ha fallado.
Este error, es más habitual de lo que nos pensamos. Y lo que también es habitual es que la mayoría de DBAs piensen que ya está todo perdido. Hay que hacer el procedimiento de nuevo, porque una vez ha fallado, es imposible terminar el proceso correctamente y que la base de datos sea funcional.
¿Qué ha ocurrido?
Te voy a explicar lo que ha pasado aquí. Es muy sencillo.
Me voy a la base de datos origen, miro el último backup ejecutado, y coincide que se ha realizado en la misma franja horaria donde estaba corriendo el DUPLICATE. Vamos a revisar el log de este backup.
==== started on mié abr 8 19:32:30 CEST 2026 ====
Recovery Manager: Release 19.0.0.0.0 - Production on Wed Apr 8 19:32:30 2026
Version 19.12.0.0.0
Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORA19C (DBID=2973291605)
connected to recovery catalog database
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15>
sql statement: alter system archive log current
allocated channel: ch00
channel ch00: SID=932 device type=SBT_TAPE
sent command to channel: ch00
Starting backup at 08-APR-26
current log archived
channel ch00: starting archived log backup set
channel ch00: specifying archived log(s) in backup set
input archived log thread=1 sequence=375 RECID=375 STAMP=1230031276
channel ch00: starting piece 1 at 08-APR-26
channel ch00: finished piece 1 at 08-APR-26
piece handle=ARCH_ora19c_mf2578a20_3785_1 tag=TAG20260409T034525 comment=API Version 2.0,MMS Version 5.0.0.0
channel ch00: backup set complete, elapsed time: 00:02:35
channel ch00: deleting archived log(s)Y tachán. Mientras nuestro DUPLICATE estaba restaurando datafiles, se ejecutaron varios backups en la base de datos origen, los cuales guardaron los archivelogs, y esos backups están configurados de tal manera, que cuando los archivelogs ya tienen una copia guardada, se eliminan.
Esto ocurrió con este, y con otros 70-80 archivelogs más. Cuando unas horas más tarde, todos los datafiles se habían restaurado, y llegó el turno de los archivelogs para avanzar hasta el SCN marcado, los archivelogs ya no estaban físicamente en el servidor.
La Solución
En nuestro caso, tenemos un problema añadido. Estamos clonando de Producción a Pre-Producción. El master de backup de PRO solo tiene visibilidad y conectividad con las BDs de PRO y en PRE hay un master de backup distinto, el cual solo tiene conectividad con las BDs de PRE.
Esto quiere decir, que desde nuestra base de datos que está a medio duplicar, no podemos restaurar los archivelogs que nos faltan.
Te cuento los pasos que yo he dado, por si te pueden ayudar en alguna ocasión así:
- Restaurar archivelogs en base de datos origen.
- Mover, copiar, enviar los archivelogs a la base de datos destino.
- Levantar la instancia de nuevo (sin spfile)
- Ejecutar de nuevo el proceso de DUPLICATE, exactamente igual que lo hicimos antes.
1. Restaurar archivelogs en base de datos origen
Esta parte es sencilla. Nos conectamos a RMAN en la base de datos origen, tanto a la base de datos como al catalogo correspondiente. No olvidemos poner una ruta distinta, para poder diferenciarlos y no liarnos con los actuales. Ejecutamos el siguiente código:
rman
connect target /
connect catalog OWNER/PASSWORD@BASE_DE_DATOS
run {
allocate channel ch00 device type 'SBT_TAPE';
allocate channel ch01 device type 'SBT_TAPE';
set archivelog destination to '/oracle/ora19c/arch/aux';
restore archivelog
from sequence 375
until sequence 430
thread 1;
}Finalizado el restore de los archivelogs, ya los tendremos todos en la ruta auxiliar:
[ora19c@linuxorigen]$ ls -lrth
total 75G
-rw-r----- 1 ora19c oinstall 1,9G abr 9 17:37 arch_375_1_4258996571.arc
-rw-r----- 1 ora19c oinstall 1,9G abr 9 17:37 arch_376_1_4258996571.arc
-rw-r----- 1 ora19c oinstall 1,9G abr 9 17:38 arch_377_1_4258996571.arc
-rw-r----- 1 ora19c oinstall 1,8G abr 9 17:39 arch_378_1_4258996571.arc
-rw-r----- 1 ora19c oinstall 1,9G abr 9 17:40 arch_379_1_4258996571.arc
[...]
-rw-r----- 1 ora19c oinstall 1,8G abr 9 17:41 arch_429_1_4258996571.arc
-rw-r----- 1 ora19c oinstall 1,9G abr 9 17:42 arch_430_1_4258996571.arc2. Mover, copiar, enviar los archivelogs a la base de datos destino
Si estamos haciendo un DUPLICATE de base de datos, es porque debe haber conectividad. Pero en el hipotético caso de una red compleja en el que hay conectividad entre bases de datos, pero no entre servidores, podéis descargar por ftp en origen y subir en destino.
En mi caso, las bases de datos están en servidores diferentes y hay conectividad entre ellos. Por lo tanto, los voy a mover por red, con el comando scp
scp arch_* ora19c@linuxdestino:/ruta/elegida/3. Levantar la instancia de nuevo (sin spfile)
Cuando el DUPLICATE ha fallado, la instancia se queda parada. Podemos volver a levantarla con un startup mount y continuar con el procedimiento. ¡¡ERROR!!
Y te lo digo con conocimiento de causa.
Levantas la base de datos, sales de SQL*Plus, vuelves a ejecutar el DUPLICATE y… 💣 PUM 💣
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/09/2026 18:24:16
RMAN-05501: aborting duplication of target database
RMAN-05537: DUPLICATE without TARGET connection when auxiliary instance is started with spfile cannot use SPFILE clauseEn mi código de DUPLICATE pongo la clausula SPFILE para indicar los parámetros que quiero configurar. Algo que casi el 100% de humanos hacemos, porque al menos es necesario configurar los parámetros df_file_name_convert y log_file_name_convert para respetar el nombre de las instancias que tenemos en los diferentes entornos.
Entonces claro, qué ocurre, que no puede crear un SPFILE nuevo con los parámetros que le indicamos, si la instancia ya está levantada con un SPFILE.
Paramos la instancia y la levantamos manualmente con un pfile temporal con los parámetros básicos necesarios.
[ora19c@linuxdestino]$ cat init.temp
DB_NAME=ora19cpre
DB_UNIQUE_NAME=ora19cpre
DB_BLOCK_SIZE=8192
DIAGNOSTIC_DEST=/oracle/ora19cpre/admin
AUDIT_FILE_DEST=/oracle/ora19cpre/admin/adumpEl resultado será algo así:
sqlplus "/ as sysdba"
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Apr 09 08:26:04 2026
Copyright (c) 1982, 2021, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup force nomount pfile=init.temp
SQL> Arrancando Instancia Temporal …
SQL> ORACLE instance started.
Total System Global Area 2852126544 bytes
Fixed Size 8900432 bytes
Variable Size 1442840576 bytes
Database Buffers 1342177280 bytes
Redo Buffers 58208256 bytes
SQL> exit
Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production3. Ejecutar de nuevo el proceso de DUPLICATE
Ya tenemos los archivelogs restaurados, y enviados al servidor destino. (Ponlos en la misma ruta)
También hemos levantado ya la instancia en modo nomount y tenemos todo preparado.
Ejecutamos de nuevo el duplicate:
rman
connect target SYS/PWD@BD_ORIGEN
connect auxiliary SYS/PWD@BD_DESTINO
run
{
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate auxiliary channel stby1 type disk;
allocate auxiliary channel stby2 type disk;
allocate auxiliary channel stby3 type disk;
allocate auxiliary channel stby4 type disk;
${SET_NEWNAMES}
duplicate database to ${BD_DESTINO} from active database
SECTION SIZE 2G
USING COMPRESSED BACKUPSET
spfile
set db_unique_name='${BD_DESTINO}'
set control_files='/oracle/ora19cpre/control01/control01.ctl','/oracle/ora19cpre/control02/control02.ctl','/oracle/ora19cpre/control03/control03.ctl'
set db_file_name_convert='/oracle/ora19c','/oracle/ora19cpre'
set log_file_name_convert='/oracle/ora19c','/oracle/ora19cpre'
set db_create_file_dest='/oracle/ora19cpre/temp'
set db_create_online_log_dest_1='/oracle/ora19cpre/temp'
set db_create_online_log_dest_2='/oracle/ora19cpre/temp'
set log_archive_max_processes='5'
set log_archive_dest_1='LOCATION=/oracle/ora19cpre/arch'
set log_archive_format='arch_%s_%t_%r.arc'
set local_listener='LISTENER_ORA19CPRE'
set diagnostic_dest='/oracle/ora19cpre/admin'
set audit_file_dest='/oracle/ora19cpre/admin/adump'
;
}Comenzará desde el principio a parar la instancia, montarla, etc.
La diferencia está, en que cuando tiene que comenzar a restaurar los datafiles aparecerá esto:
Using previous duplicated file /oracle/ora19cpre/datos01/datafile01.dbf for datafile 001 with checkpoint SCN of 12551806338137
Using previous duplicated file /oracle/ora19cpre/datos01/datafile02.dbf for datafile 002 with checkpoint SCN of 13660707228195
Using previous duplicated file /oracle/ora19cpre/datos01/datafile03.dbf for datafile 003 with checkpoint SCN of 13660707228330Por lo tanto, verifica que están todos, y no tiene que volver a restaurarlos.
Sigue el proceso adelante y llega a la parte donde nos falló.
Antes:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 04/09/2026 07:58:46
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 375 and starting SCN of 13660706910058Ahora:
channel stby1: starting archived log restore to default destination
channel stby1: using compressed network backup set from service opsemig
channel stby1: restoring archived log
archived log thread=1 sequence=375
channel stby2: starting archived log restore to default destination
channel stby2: using compressed network backup set from service opsemig
channel stby2: restoring archived log
archived log thread=1 sequence=376
channel stby3: starting archived log restore to default destination
channel stby3: using compressed network backup set from service opsemig
channel stby3: restoring archived log
archived log thread=1 sequence=377Hay diferencia ¿no?
En lugar de borrar todo, relanzar, esperar otras 22 horas, y rezar para que el backup no pase de nuevo a llevarse más archivelogs, en poco más de una hora, hemos restaurado lo que faltaba y finalizado el duplicate.
{
Alter clone database open resetlogs;
}
executing Memory Script
database opened
Finished Duplicate Db at 09/04/2026 09:11:16
RMAN>
Recovery Manager complete.¿Alguna vez has pasado por esta situación? ¿Has podido resolverla? ¿Has cogido otro camino o tienes otro método?
Si te surge cualquier duda, siempre me puedes contactar y lo debatimos. 😉
Hasta más ver. 👋🏼