Migrating Solaris Oracle to HP-UX Oracle

[Phillip Thayer]

I have been asked if I know how long it would take to move a 400GB ORacle DB from Sun Solaris to a new HP-UX system running on Integrity and EVA's. Any ideas on how long something like this will take? I really don't know where to start on this one.

Phil

[Robert-Jan Goossens · Accepted solution]

Hi Phil,

same product on HP as on Sun?
400 GB, what kind of connection do you have, gigabit?

If it is the same product, export the database to a filesystem, ftp/rcp the file from sun to hp.

How fast, depends on your network, below is a test i did for a large file.
49535.57 Kbytes/s 1000mb
10780.27 Kbytes/s 100mb full duplex

HTH,
Robert-Jan

[Phillip Thayer]

So just copying the file is going to be about 3 hours. How long for an export and then import. Possibly another 3 hours each?

[spex]

Phil,

We could use some more details, such as:

* Will you be copying over a network or utilizing some other means, such as tape?
* How fast is the network link between the boxes?
* How fast are all drives involved?
* Will the Oracle datafiles suffice, or must you use transportable tablespaces, or exp/imp?
* Do you care about the time it will take to configure the database on the new server once it has been copied?

You can perform some basic benchmarking on both systems to get some of these values.

PCS

[Phillip Thayer]

O.K. I think I have more information on this now. The disks on the Solaris are a direct connected array. What I am thinking is that we can connect the EVA to the Solaris system and do a volume copy of the Oracle volume to the EVA. Then once that is completed we shutdown the EVA, disconnect from the Solaris (yeah) and connect it to the Integrity server with Oracle Enterprise Server installed (Same version as what was running on Solaris), startup the EVA configure the drives into the system and connect it to Oracle.

Does this sound like a good plan of action?

Phil

[Robert-Jan Goossens]

Phil,

The default filesystem type on Solaris is UFS, HPUX uses VXFS.

what are you using on your solaris server?

Robert-Jan

[Phillip Thayer]

I don't have the answer to that yet. I was told that they were using Veritas so I thought it would be VxFS. Can Solaris use Veritas?

Phil

[Deoncia Grayson_1]

Solaris is very compatible with Veritas, most companies who has a solaris shop, uses veritas to manage their volume groups/filesyetesms etc

[Robert-Jan Goossens]

Yes solaris can use veritas (vxvm), but to use veritas and vxfs you need to have veritas filesystems installed as an extra option.

solaris 9 example below with VXVM
root# df -k | grep PXXT | grep d01
/dev/vx/dsk/prd01/poradata-prbt-d01 7323693 5511781 1445728 80% /app/poracle/oradata/PXXT/d01
root# fstyp /dev/vx/dsk/prd01/poradata-pxxt-d01
ufs

Regards,
Robert-Jan

[TwoProc]

On your import/export step...

Are you going to do a "whole" database export, or a schema at a time?

As a suggestion, to gain time, I've done the schema at a time version, so as to gain concurrency.

First do sys, system, then go back and export all of the base schemas.

Then to go to each schema for the application(s), then export the users schemas.

Then, you write a script to load the base sys,system in the first step. Second step is for all of the base products. Third step is to begin running (like 10 or 12 processes wide) application schema loads. And lastly load the user schemas 10 or 12 wide concurrently as well.

Then start working on your invalid objects and problems.

Naturally, you'll want the new database patched to EXACTLY the same level as on the Solaris server before you begin the loads.

Of course, you'll do this in test plenty enough times to where the whole process is HIGHLY repeatable, and you've got your timings down.

Don't forget to create (from your timings estimates) a fallback plan. That is, at what time during the weekend, if you're not done, you start putting the system back to the Solaris Server. Remember, the definition of a non-failure for the weekend is that, after it's all over you're still "up" - ON EITHER PLATFORM. A definition of success would be that you've made it to the new system before the drop-dead time designated for cutover.