Moving Oracle Database to EMC Box from local server disks.

[Gulam Mohiuddin]

I would like to know steps/procedure to move existing Oracle databases from HP-UX box to EMC Symmetrix Storage box, once it is attached and configured to our existing HP UNIX Server.

We want to move all Oracle databases to the EMC storage from the local disks of our existing server.

Thanks,

Gulam

[Sanjay_6 · Accepted solution]

Hi,

You can add the EMC disks to the same Vg as your existing database Vg and then do a pvmove to move the data from the current disk to the EMC disks. Once done, you can do vgreduce to remove the current internal disks from the database VG. Thus your database will sit on the EMC with the same VG.

Another choice would be to add the EMC disk to a new VG. Take a backup of the old database filesystems, restore them to EMC and then unmount the old filesystems, mount the EMC filesystems in their place.

Hope this helps.

Regds

[harry d brown jr]

We need to know if you are currently using RAW disk (or logical volumes) for oracle.

If it is a filesystem, back it up, create new VG and LV's on the EMC, restore data (or copy disk to disk). Make sure DB is DOWN.

live free or die
harry

[Gulam Mohiuddin]

We are using Logical Volumes or LMV.

We don't want to take backup and restore on EMC disk.

I think PVMOVE is better option, please provide us more details on this option.

Thanks,

Gulam.

[Sanjay_6]

Hi Gulam,

Take a look at the threads below,

http://us-support.external.hp.com/cki/bin/doc.pl/sid=8afe35fb0d3b809776/screen=ckiDisplayDocument?docId=200000024603959

http://us-support.external.hp.com/cki/bin/doc.pl/sid=8afe35fb0d3b809776/screen=ckiDisplayDocument?docId=200000054963038

http://us-support.external.hp.com/cki/bin/doc.pl/sid=8afe35fb0d3b809776/screen=ckiDisplayDocument?docId=200000052394074

The third doc refers to some other links, do have a look at them too.

hope this helps.

Regds

[James R. Ferguson]

Hi Gulam:

I'd create a set of "dummy mount points". Then do this for each filesystem:

# cd /old_mount_point
# find . | cpio -pudlmv /new_mount_point

When done, edit /etc/fstab replacing the "old_mount_point" with the "new_mount_point" and remove the "old" ones.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Gulam:

With regard to using a 'pvmove' mechanism, consider that this will *not* allow you to change the existing LVM disk geometry ('max_pv', 'pe_size', 'max_pv', 'max_lv') since you would not be doing a 'vgcreate'. This may or may not impede you at a later date since the attributes, once set, *cannot* be changed. Personally, I would avail myself of the opportunity, now, to create fresh volume groups, and set my LVM parameters for future growth. This *may* avoid needless maintenance later.

Regards!

...JRF...

[Gulam Mohiuddin]

Thanks for all great responses.

As we have 90+ databases and some are pretty big in size 30GB+. So we are looking for quick and safe solution.

Although we will be getting some help from EMC support engineers, but we want to prepare ourselves with all options.

Thanks,

Gulam.

[Gulam Mohiuddin]

If we rename mount points, Oracle will not recognise the path for existing datafile (Example: /u01/oracle/gis/gisuser.dbf). In this case we have to manually rename the datafile location in the database cotrolfile.

Thanks,

Gulam.

[James R. Ferguson]

Hi Gulam:

You do NOT have to "tell" Oracle anything about the "new" mountpoints. Notice that they exist only during the time of the file copy. When done, you edit /etc/fstab and change the new mountpoint names to the old mountpoint names. Obviously, your database is *inactive* for the whole duration of the copy and the mountpoint swap.

...JRF...

[Sanjay_6]

Hi Gulam,

JRF is not asking you to rename the mount points. He is advising you to mount the new filesystems at a new mount point and then copy the data over to that filesystem, unmount the original data mount points and mount the new filesystems in their place. This does not lead to new mount point names.

Hope this helps.

Regds

[Gulam Mohiuddin]

Thanks for the explanation.

But can I get more detail example, if you guys don't mind.

Thanks,

Gulam.

[Krishna Prasad]

The examples you have been given will work.
I did this about a year and half ago.

The big step is that you unmount the file system with the .new mount point and re-mount the same logical volume with the original mount point. When finished the logical volume name my change but the mount point will be the same.

I.E. Before you begin
/dev/vg##/lvol1 /oracle/SID/data1

New emc drive attached and added to a volume group. File System created and mounted as

/dev/vg##/lvol100 /oracle/SID/data1.new

Shutdown database and cp data from /oracle/SID/data1 to /oracle/SID/data1.new

unmount /oracle/SID/data1 and /oracle/SID/data1.new

Now mount the new drive's logical volume to the old mount point.

/dev/vg##/lvol100 /oracle/SID/data1

Hope this clears it up ...but all the examples look correct.

[Roger Baptiste]

Gulam,

The key thing is not clear here:
<>

Is your database using
RAW volumes or FILESYSTEMS?
Please note that both raw volumes and filesystems are based on LVM (which is a HP way of configuring disks).
Check this with the dba, or
you can figure it yourself by
doing bdf and see whether there are any mountpoints belonging to the database.
(i am not referring to oracle binaries here ).


<>

I can understand your position, having restored a 3 terabyte database couple of times last month ;-)

<>

Pvmove is an option, but not
necessarily a better option!

If your database is using
only FILESYSTEMS, then this
should be a easy process.
Like others mentioned in this thread, all you need to do
is :
1)make a list of filesystems which your database is using
2) note their sizes.
3) create new filesystems on emc disks with the same sizes
4)mount the new filesystems under a differnt mountpoint. for eg:
if your db mountpoints is
/mydb/redo01
-> the new FS can have the mountpoint as /newmydb/redo1
5) shutdown the database
6) copy the Dbase FS to the new FS, using cpio or cp or any similar command.
7) Once the copy is done, umount the Database filesystems and new filesystems
8) Now, make the newfilesystems mountpoint pointing to old mountpoints
9)Bring the DB up.
You don't need to do anychange in the DB layout.

But, if this is a rawvolume
database or if it is a rawvolume+FS database, then
you would need to use a different strategy to move the rawvolumes.

HTH
raj

[Gulam Mohiuddin]

We are using only LVM FILESYSTEMS and we are not using any RAW volumes/devices.

Thanks,

Gulam.

[Aaron_4]

I am copying data from a hp autoraid to a EMC Sym. My steps were going to be:
1. Create new filesystems from EMC
2. Copy data from autoraid to new filesystems
3. Unmount old and new filesystems then mount new filesystems to old mount points.

My question is with the copy command. I was just going to use: cp -r -p . Is the cpio command better than the cp command? Is there other copy commands that would be better? I have some oracle databases as well so obviosly I will shutdown them down. Thanks for the help

[Duncan Edmonstone]

Aaron,

You should really have posted this as a new wuestion rather than as a response to this old thread.

Yes cpio is generally faster than cp, and in fact is generally the fastest method of moving the data without getting a bit esoteric. You may of course be able to use LVM commands to migrate all the data off the autoraid and onto the EMC, but this depends on:

1. You having the MirrorDisk/UX software
2. The size of the LUNs on the Autoraid vs. the size of the LUNs on the EMC, and how the volume groups on the autoraid were created (the values for Maximum number of physical volumes in a volume group, and the maximum number of physical extents per physical volume)

If you want to keep things simple, and can afford the downtime stick to cpio.

HTH

Duncan