Comments on: HOWTO: Oracle Cross-Platform Migration with Minimal Downtime

By: Lukas

Lukas — Thu, 18 Mar 2010 00:27:25 +0000

I’m facing similar exercise Windows32bit -> Linux 64bit. I’m thinking about using datapump over a db link to do full import on the target system, therefore getting the migration done in single step (hopefully:).
Are there any caveats one might have against/for that approach?
I’ll post the my experience once I have a chance to try it out.

By: Don Seiler

Don Seiler — Tue, 16 Feb 2010 17:00:26 +0000

Som, assuming RMAN can easily get the controlfiles and backup files from tape, I suppose it might be possible. I don’t have any personal experience backup up to, or restoring from tape. I would think that it would be much slower than using disk though.

Mitchell and Gary, I haven’t considered a Windows-to-Linux migration, but it might be possible. I also have no experience with Oracle on windows, so I can’t really offer any solid view.

By: Mitchell Loren

Mitchell Loren — Mon, 15 Feb 2010 20:20:52 +0000

Can this be used to go Windows -> Linux.

I am assuming its not possible, unless my thinking is off

By: Som

Som — Thu, 28 Jan 2010 03:43:08 +0000

Hi Don, instead of using FRA, can I using tape?

By: Don Seiler

Don Seiler — Wed, 23 Dec 2009 20:07:39 +0000

Pavel,

In our case, we were also migrating from ZFS on Solaris to ASM on Linux, so we didn’t look into what you are discussing. Would be interesting to explore though.

By: Pavel Tsvetkov

Pavel Tsvetkov — Tue, 22 Dec 2009 09:12:38 +0000

it seems to me that it could be possible to use the same database files on different platforms (Solaris x86 & Linux ) if using the same file system type. For sample vxfs (Veritas File System). The only thing to do is to export/import diskgroup with datafiles. I only doubt it would be supportable by Oracle.

By: Don Seiler

Don Seiler — Tue, 15 Dec 2009 17:09:03 +0000

Jeepal,

For cross-platform migration, I created a new instance on the destination and used transportable tablespaces to move the data.

Here is the 10gR2 doc that I used:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tspaces.htm#ADMIN01101

I don’t recall the time needed to convert.

By: Jeepal

Jeepal — Tue, 01 Dec 2009 04:05:28 +0000

Michael / Don.

When there is a endian difference, could you please provide a high level methodology to use.

We are planning to do an OS cold backup, subsequent restore of the entire database on Target, run convert datafile and synchronizing the data from there on. BTw, we are going from Big to Little Endian.

Do you have a estimate on how much time it would take to convert a 10 Gig datafile?

Also once datafile is converted can we apply the archivelog’s I am thinking no, but wanted to know your opinion.

By: Don Seiler

Don Seiler — Tue, 24 Nov 2009 21:03:27 +0000

Michael, I do specify that both source and destination were of the same CPU type. But you are right it should be specifically stated that this is completely dependent on both ends being the same endian.

When I did a Solaris SPARC to Solaris x86-64 migration, I used transportable tablespaces with RMAN convert on the destination side. Downtime was much, much, MUCH longer.

By: Michael

Michael — Tue, 24 Nov 2009 20:39:35 +0000

I think you need to point out that your task plan would have been infinitely more complex and downtime longer were there an endian difference between migration platforms. I had to do this for a Sun Sparc Solaris to Linux migration, and we had to do the “convert” rman syntax with the database down, which basically copies the datafiles and takes quite a while with a larger database.