Duplicate Oracle Database from Windows to Linux

Question

I have a regular Oracle 12c database already created, named ECLS. I've been given a pile of .BKP files, not from this database, and have been told to replace everything in ECLS with the contents of these files.

Here's how I've attempted to do that so far:

$ sqlplus / as sysdba
SQL> shutdown immediate;
SQL> startup pfile='/u01/app/oracle/product/12.1.0/db_1/dbs/initECLS.ora' nomount;
SQL> exit
$ rman auxiliary /
RMAN> duplicate database to ECLS backup location '/u01/dumpfilesgohere' NOFILENAMECHECK;

Inside the pfile, I have this line set:

*.enable_pluggable_database=true

It runs for 2.5 hours, then it fails with this error message:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 02/02/2017 14:05:04
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/u01/app/oracle/fast_recovery_area/ECLS/archivelog/2017_02_02/o1_mf_1_73358_d970psod_.arc'
ORA-10562: Error occurred while applying redo to data block (file# 66, block# 799698)
ORA-10564: tablespace NCDS_TS
ORA-01110: data file 66: '/u01/app/oracle/product/12.1.0/db_1/dbs/D:ORADATAFUUVZPD152204CC3CA44789537C2BE3F39041EDATAFILEO1_MF_NCDS_TS_CQ476L1O_.DBF'
ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 106975
ORA-00600: internal error code, arguments: [ktbrcl:NOOP incompat_opt], [212], [], [], [], [], [], [], [], [], [], [] 

In the logs at /u01/app/oracle/diag/rdbms/ecls/ECLS/alert/log.xml I see these messages:

<msg time='2017-02-02T14:05:03.614-05:00' org_id='oracle' comp_id='rdbms' type='UNKNOWN' level='16' host_addr='127.0.0.1' pid='5138'>
 <txt>Errors in file /u01/app/oracle/diag/rdbms/ecls/ECLS/trace/ECLS_pr07_5138.trc:
ORA-00308: cannot open archived log &apos;D:\ORADATA\FUUVZP\ONLINELOG\O1_MF_1_CQ39NGLV_.LOG&apos;
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00600: internal error code, arguments: [ktbrcl:NOOP incompat_opt], [67], [], [], [], [], [], [], [], [], [], []
 </txt>
</msg>
<msg time='2017-02-02T14:05:03.614-05:00' org_id='oracle' comp_id='rdbms' type='UNKNOWN' level='16' host_addr='127.0.0.1' pid='5138'>
 <txt>Slave exiting with ORA-10562 exception
 </txt>
</msg>
<msg time='2017-02-02T14:05:03.614-05:00' org_id='oracle' comp_id='rdbms' type='UNKNOWN' level='16' host_addr='127.0.0.1' pid='5138'>
 <txt>Errors in file /u01/app/oracle/diag/rdbms/ecls/ECLS/trace/ECLS_pr07_5138.trc:
ORA-10562: Error occurred while applying redo to data block (file# 66, block# 1200147)
ORA-10564: tablespace NCDS_TS
ORA-01110: data file 66: &apos;/u01/app/oracle/product/12.1.0/db_1/dbs/D:ORADATAFUUVZPD152204CC3CA44789537C2BE3F39041EDATAFILEO1_MF_NCDS_TS_CQ476L1O_.DBF&apos;
ORA-10561: block type &apos;TRANSACTION MANAGED DATA BLOCK&apos;, data object# 106975
ORA-00600: internal error code, arguments: [ktbrcl:NOOP incompat_opt], [67], [], [], [], [], [], [], [], [], [], []
 </txt>
</msg>

The fact that I'm seeing Linux errors about files not being found and Windows file paths suggests to me that this is somehow related to the fact that the .BKP files were generated on a Windows machine while the place they're being used is a Linux machine.

How can I account for this? Is there some setting in the pfile that I need to change during startup? Or is there another argument that needs to be passed to RMAN in the duplicate command?

Answer 1

An Oracle employee told me that redo logs are not platform independent. They told me I'd either have to shut down the Windows database and take a cold backup of it without any redo logs, or I'd have to restore the files I already have to another Oracle database running on Windows.

We ended up setting up a new Windows machine to restore the database to.

Answer 2

Set up your restore to move the files to their new homes, since Linux and Windows can't have the same file paths.

Use something like this (from Oracle docs):

RMAN> RUN
{
  #  If you need to restore the files to new locations,
  #  use SET NEWNAME commands:
  SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
  SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
  SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
  ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
  RESTORE CONTROLFILE FROM AUTOBACKUP;
  ALTER DATABASE MOUNT;
  SET UNTIL SEQUENCE 124 THREAD 1;
  RESTORE DATABASE;
  SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
  RECOVER DATABASE;
}

Note that you will need to know which Oracle datafile number corresponds to which actual file in the backup.

You can use this command to get a list of backup file numbers and their original file names:

RMAN> list backup of datafile 1;

This will give output like that found at the bottom of this document.

  List of Datafiles in backup set 2
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 175337     21-OCT-03 /oracle/dbs/tbs_01.f

Answer 3

Generally we follow the following steps during the database duplication using RMAN-

1. We go to platform A, in your case Linux.
2. Restore a backup of database from another platform B, in your case it's Windows.
3. Restore data files/archived logs created on B.
4. Recover the restored backup on platform A.

The Cross-platform redo application is only supported for physical standby but not for general media recovery which is involved while duplicating database using RMAN.

So, if you had cold RMAN backup, we don't need to recover the database during duplication, then you could proceed ahead.

Reference:

Restore From Windows To Linux using RMAN Fails (Doc ID 2003327.1)(MOS ID required)

Answer 4

I am not familiar with this error bot the problem is rman wants to apply the archive log

D:\ORADATA\FUUVZP\ONLINELOG\O1_MF_1_CQ39NGLV_.LOG

but did not find this archivelog. This follows from the error message

ORA-00308: cannot open archived log  D:\ORADATA\FUUVZP\ONLINELOG\O1_MF_1_CQ39NGLV_.LOG

and from the Linux error that follows.

So it seems that the duplication needs an archive log that is not contained in the backup file.

You have to clarify why this happens.

You should ask the following question to the provider of the backup:

• Was the source database mounted or open when the backup was taken?
• Was the source database running in archive mode when taking the backup?
• Is this backup a consistent backup or an inconsistent backup
• Is it an inconsistent backup (made from an open or crashed database) and does it contain the necessary archive logs?

I assume that this is a backup that was taken from a running database and contains only copies of the database files and no archive log backup was taken.

You can run your DUPLICATE command with the NOREDO option but if he backup is inconsistent you will not be able to open the database.

Solution:Run the duplicate command with the NOREDO option. If this doe not work either get backup with the necessary archive logs or get a consistent backup and duplicate with NOREDO option.

Database Backup and Recovery Reference 12.2:

**Backup-Based Duplication'' [...] For backup-based duplication of databases in ARCHIVELOG mode, RMAN recovers by default up to the last archived redo log generated at the time the command was executed, or until a time specified with a SET UNTIL clause.

For backup-based duplication of databases without a connection to the target database, RMAN cannot determine whether the source database was in NOARCHIVELOG mode. Therefore, you must use the NOREDO option when the source database was in NOARCHIVELOG mode when the backups were taken. You can also use the NOREDO option when you do not want to apply archived redo log files to a consistent backup.

Edit:

It seems that Windows archive logs aren't compatible with Linux (the OP's answer). So use the way that avoids archive logs as described above:

• Make a backup of the database in mounted state (not open)
• use the NOREDO clause for duplication

Answer 5

The endian is different between Windows and Linux. You can use transportable table spaces to move your database. At some point you need to change the endian of your transportable table space export. Here is the documentation.

Transporting Data Across Platforms