Restoring an Oracle database from a Unix environment to Windows environment

Hi,,
I am new to all of this so sorry if it seems like a dumb question. Also I looked through the forum to see if anyone had asked a similar question...couldn't find a similar one so here goes..

The organisation I work for has a 10g Oracle database situated on a unix box, we are building a reporting solution for it. However our (development and reporting live environment) is Windows based (We have a windows based version of O10g installed there).

Will we have problems moving a backup of the live system from Unix environment to Windows environment and will we be able to apply the re-do logs in the normal fashion? (We plan on keeping an up to date version on our windows server so management can run their reports without hurting the transactional system)

Is it impossible to do? Or just plain complicated and difficult? Or should it be a breeze?

Thanks in advance for any replies

Data Guard can support specific mixed Oracle Platform combinations, check out Metalink Note:413484.1.

Maybe a logical standby would be more acceptable. ;)

LKBrwn_DBA, Thanks for the reply. All I can find about mixed platform support in data guard is from 11g onwards. Does you/anyone know if data guard in 10g supports mixed platform? I have looked but it is like searching through the proverbial haystack.

no it doesnt

Quote:

---

Originally Posted by Oracle_Nooby

LKBrwn_DBA, Thanks for the reply. All I can find about mixed platform support in data guard is from 11g onwards. Does you/anyone know if data guard in 10g supports mixed platform? I have looked but it is like searching through the proverbial haystack.

---

I think you may want to check again Metalink Note:413484.1 ... as pointed out by LKBrwn_DBA

Metalink note is pretty clear about what is available in each Oracle version.

I can think of three options:

1. Data Pump (or emp/imp)
2. Transportable Tablespace(s)
3. Streams

if it's 10gR2, I did the opposite, copy the standby DB's data files from Windows to Linux, the create control file, startup upgrade, then invalidate and recompile all packages.

If the version is different, it needs to run $ORACLE_HOME/rdbms/admin/catalog.sql & catproc.sql

Quote:

---

Originally Posted by sql888

if it's 10gR2, I did the opposite, copy the standby DB's data files from Windows to Linux, the create control file, startup upgrade, then invalidate and recompile all packages.

If the version is different, it needs to run $ORACLE_HOME/rdbms/admin/catalog.sql & catproc.sql

---

:confused: :confused: :confused: :confused: :confused:

Hi,
Streams will be the best option if you are looking for almost real time data.

Regards,
Satheesh Babu S
http://satheeshbabus.blogspot.com

Quote:

---

Originally Posted by sql888

if it's 10gR2, I did the opposite, copy the standby DB's data files from Windows to Linux, the create control file, startup upgrade, then invalidate and recompile all packages.

If the version is different, it needs to run $ORACLE_HOME/rdbms/admin/catalog.sql & catproc.sql

---

So not only are you just moving datafiles around different platforms at will, but you are just running catalog.sql & catproc.sql to account for different versions ??

ya. Linux 10.2.0.4 32-bit. Windows 10.2.0.3 64-bit.

I might be the same to move to Linux 10.2.0.3 first, then run startup upgrade to upgrade it to 10.2.0.4. But I already have Linux 10.2.0.4 binary installed.


Windows 64 bit => 32 bit needs to invalidate/recompile.

Quote:

---

Originally Posted by sql888

ya. Linux 10.2.0.4 32-bit. Windows 10.2.0.3 64-bit.

I might be the same to move to Linux 10.2.0.3 first, then run startup upgrade to upgrade it to 10.2.0.4. But I already have Linux 10.2.0.4 binary installed.


Windows 64 bit => 32 bit needs to invalidate/recompile.

---

Just curious what ever lead you to believe that the process of simply copying datafiles across platforms is supported ?

Full database platform migration is only supported in 10gR2+ with the help of RMAN.

RMAN is doing the same trick at the DF level. when RMAN do the copy file, it's like hot backup.

actually, in metalink, there is an internal note about how to use RMAN backupset if the control file is corrupted and unrecoverable. So essentially, controlfile is not needed, all needed is the extracted datafiles from the backupset.

In my experiment, one more complication is the RAC ASM -> non-RAC/non-ASM. The data files are all magic numbers generated by Oracle Managed files. When I do the DB refresh, I will stop the Standby DB apply (non-RAC/non-ASM). and copy the DFs over. This provides consistency during the copy.

Quote:

---

Originally Posted by sql888

RMAN is doing the same trick at the DF level. when RMAN do the copy file, it's like hot backup.

---

Which same trick...the actual conversion ? If any conversion is required, the CONVERT DATABASE would have to be utilized (even with the same endian format).

Restoring a datafile(s) from a backupset is totally different than copying a datafile across different platforms.

In addition, the OP was talking about converting from UNIX to Windows which is a totally different scenario all together.

Hi,

Havent done this, but we explored the possiblity of doing this for a cross platform move from Sun to IBM. You can achieve this for one-time or repeated full refresh by using RMAN to move from one platform to another platform in 10g (depending on the "endian" format of the db). Your case is not a one-time refresh. You have a different requirement. Your requirement is to keep the data in a non-production environment in sync with production. You might be able to use STREAMS. I am not sure about it cos of cross-platform issues. OR you can use plain-old replication.

Regards,

Shaji.