Duplicate Oracle Database from Windows to Linux 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&gt; shutdown immediate;
SQL&gt; startup pfile='/u01/app/oracle/product/12.1.0/db_1/dbs/initECLS.ora' nomount;
SQL&gt; exit
$ rman auxiliary /
RMAN&gt; 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:

&lt;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'&gt;
 &lt;txt&gt;Errors in file /u01/app/oracle/diag/rdbms/ecls/ECLS/trace/ECLS_pr07_5138.trc:
ORA-00308: cannot open archived log &amp;apos;D:\ORADATA\FUUVZP\ONLINELOG\O1_MF_1_CQ39NGLV_.LOG&amp;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], [], [], [], [], [], [], [], [], [], []
 &lt;/txt&gt;
&lt;/msg&gt;
&lt;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'&gt;
 &lt;txt&gt;Slave exiting with ORA-10562 exception
 &lt;/txt&gt;
&lt;/msg&gt;
&lt;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'&gt;
 &lt;txt&gt;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: &amp;apos;/u01/app/oracle/product/12.1.0/db_1/dbs/D:ORADATAFUUVZPD152204CC3CA44789537C2BE3F39041EDATAFILEO1_MF_NCDS_TS_CQ476L1O_.DBF&amp;apos;
ORA-10561: block type &amp;apos;TRANSACTION MANAGED DATA BLOCK&amp;apos;, data object# 106975
ORA-00600: internal error code, arguments: [ktbrcl:NOOP incompat_opt], [67], [], [], [], [], [], [], [], [], [], []
 &lt;/txt&gt;
&lt;/msg&gt;


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?
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.