The other day I was doing a database cloning in 11.2.0.4 from an active duplicate, and got the following error: ORA-19909: datafile 1 belongs to an orphan incarnation and ORA-01110: data file 1.
This post explains how I solved these errors. It’s worth mentioning that what I did here also applies to 12c, 18c and 19c databases.
I first verified that I had the password file from the target database, and that I also had the corresponding TNS entries for it. I created a listener for this task only. Note: the client I was working with required that I create the listener; otherwise I could have worked with the SCAN listener.
Next I verified that I could connect to the target and auxiliary databases correctly. I created the script below to use for this refresh:
##################################################################
## Connectivity Test
##################################################################
oracle $ ls $ORACLE_HOME/dbs/orapwSTG*
/u01/app/oracle/product/11.2.0.4/dbhome_3/dbs/orapwSTG1
oracle $ rman TARGET sys/********@PROD AUXILIARY sys/********@STG_STATIC
connected to target database: PROD (DBID=3874882083)
connected to auxiliary database: STG (not mounted)
##################################################################
## STG_STATIC TNS Entry
##################################################################
STG_STATIC =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = auxiliarydbadm01)(PORT = 1523))
)
(CONNECT_DATA =
(SERVICE_NAME = STG1)
(UR=A)
)
)
##################################################################
## PROD TNS Entry
##################################################################
PROD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = prod_scan)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = PROD1)
)
)
##################################################################
## Listener used
##################################################################
LISTENER_REFRESH =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = auxiliarydbadm01)(PORT = 1523))
)
)
SID_LIST_LISTENER_REFRESH =
(SID_LIST =
(SID_DESC =
(ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_3)
(SID_NAME = QA1)
)
(SID_DESC =
(ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_3)
(SID_NAME = STG1)
)
(SID_DESC =
(ORACLE_HOME = /u01/app/oracle/product/11.2.0.4/dbhome_3)
(SID_NAME = RFSH1)
)
)
ADR_BASE_LISTENER = /u01/app/oracle
##################################################################
## recover_from_prod.sh
##################################################################
oracle $ cat recover_from_prod.sh
#!/bin/bash
export NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'
export ORACLE_SID=STG1
export ORAENV_ASK=NO
. /usr/local/bin/oraenv
rman TARGET sys/********@PROD AUXILIARY sys/********@STG_STATIC <<endofrman
run {
allocate channel prmy1 type disk;
allocate channel prmy2 type disk;
allocate channel prmy3 type disk;
allocate channel prmy4 type disk;
allocate channel prmy5 type disk;
allocate channel prmy6 type disk;
allocate auxiliary channel aux1 type disk;
allocate auxiliary channel aux2 type disk;
allocate auxiliary channel aux3 type disk;
allocate auxiliary channel aux4 type disk;
allocate auxiliary channel aux5 type disk;
allocate auxiliary channel aux6 type disk;
DUPLICATE TARGET DATABASE TO 'STG' FROM ACTIVE DATABASE NOFILENAMECHECK;
}
endofrman
I knew this duplicate was going to take a while as this was a 35 TB database.
SQL> SELECT
( SELECT SUM(bytes)/power(1024,4) data_size FROM dba_data_files
) +
( SELECT NVL(SUM(bytes),0)/power(1024,4) temp_size FROM dba_temp_files
) +
( SELECT SUM(bytes)/power(1024,4) redo_size FROM sys.v_$log
) +
(SELECT SUM(BLOCK_SIZE*FILE_SIZE_BLKS)/power(1024,3) controlfile_size
FROM v$controlfile
) "Database Size in TB"
FROM dual;
Database Size in TB
-------------------
35.1021405
Despite the length of time it took, the restore for the duplicate database went well. However, when the recovery process began, I got the following errors:
oracle $ tail -100 recover_from_prod.log ... Starting recover at 09-NOV-2020 08:27:59 starting media recovery media recovery failed Oracle instance started ... RMAN-11003: failure during parse/execution of SQL statement: alter database recover if needed start until change 281698833114 using backup controlfile ORA-00283: recovery session canceled due to errors ORA-19909: datafile 1 belongs to an orphan incarnation ORA-01110: data file 1: '+DATAC2/stg/datafile/system.636.1056008579'
These errors primarily happened because there were other files in the ASM diskgroup with the same DBID as the auxiliary database I was cloning.
if you’re using ASM disk groups, RMAN works a particular way for an active duplicate. It catalogs everything under the disk group the db_recovery_file_dest parameter is set to if the log_archive_dest_1. parameter is not set.
This was true in my case. In the same cluster there was a standby running called proddr for the target database I was cloning.
##################################################################
## db_recovery_file_dest and log_archive_dest_1 parameter values
##################################################################
oracle $ echo "
> show parameter log_archive_dest_1;
> " | sqlplus -s -L / as sysdba
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1 string
...
oracle $ echo "
> show parameter db_recovery_file_dest;
> " | sqlplus -s -L / as sysdba
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +RECOC2
db_recovery_file_dest_size big integer 20000G
##################################################################
## From the recover_from_prod.log
##################################################################
...
"+RECOC1/prod/archivelog/2020_11_09/thread_2_seq_535909.41715.1056009955" auxiliary format
"+RECOC2" ;
catalog clone start with "+RECOC2";
switch clone datafile all;
}
...
List of Cataloged Files
=======================
File Name: +RECOC2/proddr/CONTROLFILE/current.7901.1022257521
File Name: +RECOC2/stg/archivelog/2020_11_09/thread_2_seq_535877.5618.1056010749
...
File Name: +RECOC2/proddr/archivelog/2020_11_07/thread_2_seq_535588.2240.1055891307
File Name: +RECOC2/proddr/archivelog/2020_11_07/thread_1_seq_567337.8034.1055892763
..
datafile 1 switched to datafile copy
input datafile copy RECID=67 STAMP=1056011218 file name=+DATAC2/stg/datafile/system.636.1056008579
...
datafile 133 switched to datafile copy
input datafile copy RECID=198 STAMP=1056011261 file name=+DATAC2/stg/datafile/aud_tbs.451.1056009851
datafile 134 switched to datafile copy
input datafile copy RECID=199 STAMP=1056011262 file name=+DATAC2/stg/datafile/revenue_ods2.622.1055987265
contents of Memory Script:
{
set until scn 281698833114;
recover
clone database
delete archivelog
;
}
Once I’d investigated the error, I proceeded to fix it. The first thing I did was try to open STG database in mount mode to see the contents of the control file. From the log above I could see the datafile copy had switched and updated the control file, and this would help me speed up recovery of this process.
SQL> startup mount; ORACLE instance started. Total System Global Area 2.5655E+10 bytes Fixed Size 2265224 bytes Variable Size 1.0402E+10 bytes Database Buffers 1.5099E+10 bytes Redo Buffers 151113728 bytes * ERROR at line 1: ORA-01103: database name 'PROD' in control file is not 'STG'
From the error above, I could see the control file had the incorrect database name. I would have to recreate the control file for this.
I wanted to avoid going to ASM or the recover log to gather all the datafiles and their location. Instead, I created a small parameter file that included only the control file, the block size, the same compatible parameter and the name of the target database as database PROD as shown in the error ORA-01103 above.
Once I had the database PROD up, I backed up that database control file to trace.
oracle $ cat initprod.ora DB_NAME=PROD DB_UNIQUE_NAME=PROD DB_BLOCK_SIZE=8192 *.control_files='/home/oracle/working/antunez/STG/control02.ctl' *.compatible='11.2.0.4.0' SQL> startup mount pfile='/home/oracle/working/antunez/initprod.ora'; ORACLE instance started. Total System Global Area 513642496 bytes Fixed Size 2254624 bytes Variable Size 402655456 bytes Database Buffers 100663296 bytes Redo Buffers 8069120 bytes Database mounted. SQL> alter database backup controlfile to trace as '/home/oracle/working/antunez/stg.sql'; Database altered. SQL> shutdown abort ORACLE instance shut down.
Once I had the control file trace with the proper datafile location, I modified it to leave only the section of RESETLOGS and change the line of CREATE CONTROL FILE to use the SET command.
With that done, I ran the creation of the control file in STG database.
oracle $ cat /home/oracle/working/antunez/stg.sql
CREATE CONTROLFILE REUSE SET DATABASE "STG" RESETLOGS FORCE LOGGING ARCHIVELOG
MAXLOGFILES 192
MAXLOGMEMBERS 3
MAXDATAFILES 1024
MAXINSTANCES 32
MAXLOGHISTORY 149504
LOGFILE
GROUP 11 (
'+DATAC2/stg/onlinelog/group_11.3162.914669717',
...
'+DATAC2/stg/datafile/sysaux.454.1056009483',
'+DATAC2/stg/datafile/users.448.1056009331',
'+DATAC2/stg/datafile/users.455.1056009819'
CHARACTER SET AL32UTF8
;
oracle $ . oraenv <<< STG1
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 2.5655E+10 bytes
Fixed Size 2265224 bytes
Variable Size 1.0402E+10 bytes
Database Buffers 1.5099E+10 bytes
Redo Buffers 151113728 bytes
SQL> @/home/oracle/working/antunez/stg.sql
Control file created.
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
MOUNTED
What I needed next were the archived redo logs that were going to be used for the recovery, as some of the archivelogs were not copied.
RMAN thought they were already in place for the recovery due to them being in the auxiliary host for the proddr standby database. So I followed the steps below to find the range of archived redo logs I was going to need.
If you remember the script I used, I set the NLS environment variable to this export NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS', so the log would contain the details of the times down to seconds from the RMAN output. This turned out to be useful.
I extracted the until scn and the Starting Duplicate Db outputs from the log. I then obtained the range of archived redo log sequences I was going to need from the target database called PROD.
oracle $ cat recover_from_prod.log | egrep "Starting Duplicate Db at | scn"
Starting Duplicate Db at 08-NOV-2020 17:07:35
set until scn 281698833114;
oracle $ sqlplus sys/****@PROD as sysdba
...
SQL> select name from v$database;
NAME
---------
PROD
SQL> col scn format 999999999999999999999
SQL> select timestamp_to_scn(to_timestamp('08-11-2020 17:07:34','dd-mm-yyyy hh24:mi:ss')) scn from dual;
SCN
----------------------
281674037748
SQL> select distinct thread#, sequence#, status, first_time, next_time, first_change#, next_change# from v$archived_log
where 281674037748 between first_change# and next_change# order by 1,2;
THREAD# SEQUENCE# S FIRST_TIME NEXT_TIME FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- - ------------------- ------------------- ------------- ------------
1 567552 A 2020-11-08 17:04:19 2020-11-08 17:07:37 2.8167E+11 2.8167E+11
2 535731 A 2020-11-08 17:05:00 2020-11-08 17:07:36 2.8167E+11 2.8167E+11
SQL> select distinct thread#, sequence#, status, first_time, next_time, first_change#, next_change# from v$archived_log
where 281698833114 between first_change# and next_change# order by 1,2;
THREAD# SEQUENCE# S FIRST_TIME NEXT_TIME FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- - ------------------- ------------------- ------------- ------------
1 567681 A 2020-11-09 08:05:54 2020-11-09 08:06:09 2.8170E+11 2.8170E+11
1 567682 A 2020-11-09 08:06:09 2020-11-09 08:10:27 2.8170E+11 2.8170E+11
2 535910 A 2020-11-09 08:05:54 2020-11-09 08:06:09 2.8170E+11 2.8170E+11
With the data above, I ran the following to backup copy command. This allowed me to obtain the archived redo logs necessary for this recovery.
Please note I did it to a different location than the current db_recovery_file_dest and I had to connect to both PROD and STG databases for this command.
oracle $ rman TARGET sys/********@PROD AUXILIARY sys/********@STG_STATIC
RMAN> run {
backup as copy archivelog from sequence 567552 until sequence 567682 thread 1 auxiliary format '/u02/pythian/STG/%t_%s_%r.arc';
backup as copy archivelog from sequence 535731 until sequence 535910 thread 2 auxiliary format '/u02/pythian/STG/%t_%s_%r.arc';
}
Once the copy of the archived redo logs were restored, I registered them to the control file of the STG database.
oracle $ . oraenv <<< STG oracle $ rman target / connected to target database: STG (DBID=3874882083, not open) RMAN> catalog start with '/u02/pythian/STG/; cataloging files... cataloging done List of Cataloged Files ======================= ... File Name: /u02/pythian/STG/1056028905_128319_904050853.arc File Name: /u02/pythian/STG/1056030309_128439_904050853.arc
The last thing I needed to do was recover the STG database to the SCN found in the recover log. I made sure not to connect to the target database called PROD, but rather only to the database called STG.
oracle $ . oraenv <<< STG1
oracle $ rman target /
connected to target database: STG (DBID=3874882083, not open)
RMAN> run {
set until scn 281698833114;
recover database;
}
executing command: SET until clause
Starting recover at 09-NOV-20
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=3142 device type=DISK
starting media recovery
archived log for thread 1 with sequence 567626 is already on disk as file /u02/pythian/STG/1056029933_128385_904050853.arc
archived log for thread 1 with sequence 567627 is already on disk as file /u02/pythian/STG/1056029940_128386_904050853.arc
archived log for thread 1 with sequence 567628 is already on disk as file /u02/pythian/STG/1056029941_128387_904050853.arc
archived log for thread 1 with sequence 567629 is already on disk as file /u02/pythian/STG/1056029942_128388_904050853.arc
archived log for thread 1 with sequence 567630 is already on disk as file /u02/pythian/STG/1056029943_128389_904050853.arc
archived log for thread 1 with sequence 567631 is already on disk as file /u02/pythian/STG/1056029945_128390_904050853.arc
archived log for thread 1 with sequence 567632 is already on disk as file /u02/pythian/STG/1056029952_128391_904050853.arc
...
archived log file name=/u02/pythian/STG/1056028890_128318_904050853.arc thread=2 sequence=535909
archived log file name=/u02/pythian/STG/1056030309_128439_904050853.arc thread=1 sequence=567680
archived log file name=/u02/pythian/STG/1056030310_128440_904050853.arc thread=1 sequence=567681
archived log file name=/u02/pythian/STG/1056028905_128319_904050853.arc thread=2 sequence=535910
media recovery complete, elapsed time: 00:06:35
Finished recover at 09-NOV-20
After this I simply needed to open the database as resetlogs. I also wanted the cloned database to have a new DBID and to come up as a RAC database. I verified the database and instance status using verify_data_dictionary_11g.sql.
RMAN> alter database open resetlogs;
using target database control file instead of recovery catalog
database opened
RMAN> delete archivelog all;
...
Deleted 353 objects
RMAN> shutdown immediate
database shutdown
RMAN> STARTUP MOUNT
database mounted
RMAN> exit
oracle $ nid target=sys/*******
DBNEWID: Release 11.2.0.4.0 - Production on Mon Nov 9 14:34:22 2020
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Connected to database STG (DBID=3874882083)
Connected to server version 11.2.0
Control Files in database:
+DATAC2/stg/controlfile/control01.ctl
+RECOC2/stg/controlfile/control02.ctl
Change database ID of database STG? (Y/[N]) => Y
Proceeding with operation
Changing database ID from 3874882083 to 1490626863
Control File +DATAC2/stg/controlfile/control01.ctl - modified
Control File +RECOC2/stg/controlfile/control02.ctl - modified
Datafile +DATAC2/stg/datafile/system.636.105600857 - dbid changed
...
Datafile +DATAC2/stg/datafile/revenue_ods2.622.105598726 - dbid changed
Control File +DATAC2/stg/controlfile/control01.ctl - dbid changed
Control File +RECOC2/stg/controlfile/control02.ctl - dbid changed
Instance shut down
Database ID for database STG changed to 1490626863.
All previous backups and archived redo logs for this database are unusable.
Database is not aware of previous backups and archived logs in Recovery Area.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database ID.
DBNEWID - Completed succesfully.
oracle $ sqlplus / as sysdba
...
SQL> startup mount
ORACLE instance started.
Total System Global Area 1.6034E+11 bytes
Fixed Size 2261848 bytes
Variable Size 2.5233E+10 bytes
Database Buffers 1.3475E+11 bytes
Redo Buffers 352444416 bytes
Database mounted.
SQL> ALTER DATABASE OPEN RESETLOGS;
Database altered.
SQL> ALTER SYSTEM SET cluster_database=TRUE SCOPE=spfile;
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
oracle $ srvctl start database -d STG
oracle $ srvctl status database -d STG
Instance STG1 is running on node auxiliarydbadm01
Instance STG2 is running on node auxiliarydbadm02
oracle $ sqlplus / as sysdba
SQL> @verify_data_dictionary_11g.sql
DATABASE NAME
=============
DBNAME
---------------
STG
================================================================================================
== Oracle Instance Information
================================================================================================
-- IP Address 1**.***.***.30
Cpu_Count 24 | Host_Name auxiliarydbadm01
Instance_Name STG1 | Database_Status ACTIVE
Status OPEN | Startup_Time 09-11-2020 14:43
Version 11.2.0.4.0 | Instance_Role PRIMARY_INSTANCE
Database log mode ARCHIVELOG
Background Dump Dest /u01_diag/app/oracle/diag/diag/rdbms/stg/STG1/trace
Spfile +DATAC2/stg/parameterfile/spfilestg.ora
Redo size (Gb) 1.953125
Redo size (Gb) .09765625
-- Database Space (Gb) 35367.70 | SGA (Gb) 149.3303 --
-- Nb. Datafiles 133 | Nb. Tempfiles 15 --
DBA_REGISTRY CONTENTS
================================================================
COMP_ID COMP_NAME VERSION Status
-------------------- ---------------------------------------- --------------- --------------------------------------------------
OWB OWB 11.2.0.4.0 VALID
APEX Oracle Application Express 3.2.1.00.12 VALID
EM Oracle Enterprise Manager 11.2.0.4.0 VALID
AMD OLAP Catalog 11.2.0.4.0 VALID
SDO Spatial 11.2.0.4.0 VALID
ORDIM Oracle Multimedia 11.2.0.4.0 VALID
XDB Oracle XML Database 11.2.0.4.0 VALID
CONTEXT Oracle Text 11.2.0.4.0 VALID
EXF Oracle Expression Filter 11.2.0.4.0 VALID
RUL Oracle Rules Manager 11.2.0.4.0 VALID
OWM Oracle Workspace Manager 11.2.0.4.0 VALID
CATALOG Oracle Database Catalog Views 11.2.0.4.0 VALID
CATPROC Oracle Database Packages and Types 11.2.0.4.0 VALID
JAVAVM JServer JAVA Virtual Machine 11.2.0.4.0 VALID
XML Oracle XDK 11.2.0.4.0 VALID
CATJAVA Oracle Database Java Packages 11.2.0.4.0 VALID
APS OLAP Analytic Workspace 11.2.0.4.0 VALID
XOQ Oracle OLAP API 11.2.0.4.0 VALID
RAC Oracle Real Application Clusters 11.2.0.4.0 VALID
19 rows selected.
LIST APPLIED PATCHES
=======================
ACTION_TIME ID ACTION VERSION BUNDLE COMMENTS
------------------------------ ---------- ------------------------------ --------------- ------------------------ --------------
24-AUG-13 12.03.45.119862 PM 0 APPLY 11.2.0.4 PSU Patchset 11.2.0.2.0
17-FEB-16 01.17.34.459872 PM 0 jvmpsu.sql 11.2.0.4 RAN jvmpsu.sql
17-FEB-16 01.18.26.518633 PM 20 APPLY 11.2.0.4 EXA BP20
24-JUN-17 05.01.00.394556 AM 0 jvmpsu.sql 11.2.0.4 RAN jvmpsu.sql
24-JUN-17 05.01.00.414355 AM 0 APPLY 11.2.0.4 OJVM PSU post-instal
24-JUN-17 05.01.00.416012 AM 25434033 APPLY Patch 25434033 appli
24-JUN-17 05.01.23.110902 AM 170418 APPLY 11.2.0.4 EXA BP170418
24-JAN-19 07.48.56.741239 PM 180717 APPLY 11.2.0.4 EXA BP180717
24-JAN-19 09.00.45.442572 PM 0 jvmpsu.sql 11.2.0.4 RAN jvmpsu.sql
24-JAN-19 09.00.45.707068 PM 0 APPLY 11.2.0.4 OJVM PSU post-instal
24-JAN-19 09.00.45.709711 PM 27923163 APPLY Patch 27923163 appli
11 rows selected.
LIST APPLIED SQL PATCHES
=======================
COMMENTS ACTION ACTION_DATE VERSION
------------------------------------------------------------ ------------------------------ -------------------- ---------------
RAN jvmpsu.sql jvmpsu.sql 17/02/16 13:17:34 11.2.0.4.5OJVMB
P
BP20 APPLY 17/02/16 13:18:26 11.2.0.4
BP180717 APPLY 24/01/19 19:48:56 11.2.0.4
RAN jvmpsu.sql jvmpsu.sql 24/01/19 21:00:45 11.2.0.4.180717
OJVMPSU
OJVM PSU post-install APPLY 24/01/19 21:00:45 11.2.0.4.180717
OJVMPSU
Patch 27923163 applied APPLY 24/01/19 21:00:45
OJVM PSU post-install APPLY 24/06/17 05:01:00 11.2.0.4.170418
OJVMPSU
RAN jvmpsu.sql jvmpsu.sql 24/06/17 05:01:00 11.2.0.4.170418
OJVMPSU
Patch 25434033 applied APPLY 24/06/17 05:01:00
BP170418 APPLY 24/06/17 05:01:23 11.2.0.4
Patchset 11.2.0.2.0 APPLY 24/08/13 12:03:45 11.2.0.4
11 rows selected.
COUNT OF INVALID OBJECTS
========================
COUNT(*)
----------
0
1 row selected.
INVALID OBJECTS GROUPED BY OBJECT TYPE AND OWNER
================================================
no rows selected
LIST OF SYS INVALID OBJECTS
=======================
no rows selected
If you ever face the errors ORA-19909 and ORA-01110, I hope this blog post helps . It took me a while to solve this, and knowing the above would have come in handy.
Note: This was originally posted on rene-ace.com.
2 Comments. Leave new
Very useful, thank You.
Regards.
G
No problem at all
René