Re: LVM steps for copying oracle raw volumes, to another server.

1) You can use dump-and-load or dd. Dump-and-load is mostly DBA work, CPU and disk i/o resources, the disks on the new server do not have to be identical to the disks on the old server. Using dd is mostly unix admin work, i/o and LAN resources, the disks on the new server must be exactly the same (name and size) as those on the old server.

2) Yes with dd oracle MUST be down, absolutely no disk writing activity.

With either method, you need to have oracle down to capture all the oracle disk changes up to the last moment.

With the dump and load method, you may be able to leave oracle UP but you MUST utilize the latest archive logs (after the dump moment) from the old server to update the database on new server.

3) The block size is optional but if you use it it must be the same on both servers. You may want to do some tests to find out which block size gives you better i/o results.

Something like this would work (you need to allow remsh from the old to the new server):

Re: LVM steps for copying oracle raw volumes, to another server.

> 3) The block size is optional but if you use it it must be the same on both servers. You may want to do some tests to find out which block size gives you better i/o results.

Not really optional unless you don't care how many days it will take to copy several GB. The default is 512 bytes. If you don't set bs to a reasonable value, the copy time will be as much as 100x longer! I would recommend the option:

bs=1024k

which means each read and write will be a megabyte. If you have some spare time, try some other bs= values. The actual speed is VERY dependent on whether you are using slow SCSI disks, fibre disks (JBOD) or a disk array (HP, EMC, Axiom, etc). You can try different bs= sizes. Be sure to use count= so the amount of data transferred is the same: