1833732 Members
2952 Online
110063 Solutions
New Discussion

Re: data migration

 
SOLVED
Go to solution
Ali Imran Abbas
Regular Advisor

data migration

I am migrating an hp unix server to a more powerful server. It has three volume groups, vgroot, vgedi and vgraw which contains raw data for oracle database. i have taken the the ignite tape backup of the machine for the root volume group and has made exactly the same sizes volume groups as were in the older server. Now I wanna migrate the other data such as database and other data. Can any one give me directions how to do that? It is a production server.
4 REPLIES 4
Hein van den Heuvel
Honored Contributor

Re: data migration

Treat this an excercise in recovering from a catastrophic failure.
There is a plan in place for that right, using cold backups?
Ok, execute the existing recovery plan on a fresh target. That's all.

Books have been written on the subject.
Read them use them!

Obvious starting point:
"Oracle® Database Backup and Recovery Advanced User's Guide"

I like two distinct method myself:

Save the DB layout: "alter database backup control to trace"
Adapt to new server, and execute on new server to create 'empty' DB.
Now export on old | zip | transfer | unzip | import on new

I have also had good luck just doing the raw devices. Create a script driven by dba_datafiles to find the raw space an block used. With multiple parralel dd stream zip up the raw data. As a stream finished, push over the container and unzip and dd into the fresh raw device. Wait till all streams are done.

I would strongly suggest just try/test on live data first to see if you are in the ballpark and to get a gutfeel on how long this will take. Then, secure in the knowledge you can do it, and with a solid estimate of the transfer times, shut down the DB and do it for real.

Good luck!
Hein van den Heuvel
TTr
Honored Contributor

Re: data migration

This is a major migration and you will need some downtime. You already have done the vg00 and you probably can copy ahead of time all installed software. For the raw data I have used "dd" from one server to the other before very successfuly. But copying raw volumes you must be absolutely sure that there in no activity on the server that would possibly make any changes to the data volumes.

If you can not afford the downtime you have to look into a dump-and-load method which can be done ahead of time and then sync up at the time of the cutover. There are many variations of the dump and load method.

You did not mention if the new server is going to use the old hostname and IP. If so you need additional downtime for the server cutover.
Ali Imran Abbas
Regular Advisor

Re: data migration

yes its gonna use the same ip and hostname. i am new to unix admin, I need some more guidance in this regard. I have installed the new server using the ignite backup created from the old server. Can you please be more specific and tell me the step by step proceedure plus the commands used to do that?

Thank you very much in advance.
TTr
Honored Contributor
Solution

Re: data migration

This is too much information to type in but some highlights
1. Bring up the new server under a temporary name and IP address.
2. Allow the new server to rlogin/remsh/rcp to the old server without a password. You have to put the new server's hostname in the /.rhosts file of the old server.
3. Copy the software from the old server to the new one. This is only for the additional volumes that are not included in vg00. Was vgedi included in the ignite tape? For example to copy /oracle from the old server to the new one use the commands

(run these on the new server)
cd /oracle
remsh cd /oracle ";" tar cf - . | tar xf -

4. Copy the raw volumes one by one (this must be done with NO activity on the raw volumes).

remsh oldserver dd if=/dev/vgraw/ bs=512k | dd of=/dev/vgraw
(rlv-oldvol is the raw volume on the old server and rlv-newvol is the raw volume on the new server. The old and new volumes must be of identical size and geometry)

5. Shutdown oldserver
6. change hostname and IP of new server to match those of the old server.

Note A. After step 4, if possible run a test using the database under the new name and IP.

Note B. If it does not work after step 6, power off the new server and boot up the old server and the old environment is up.