Migrating Sybase v11.03 from one disk array to another on HPUX 10.20

[John Knapp]

I know you folks are not in the business of answering Sybase questions but it appears Sybase is neither ... ;-(

We have a Sybase v11.03 database using raw devices on a Symmetrix disk array and need to migrate it physically to another Symmetrix disk array.

I need to know if anyone has done this and be able to keep the original special device files (maybe renamed) and what utility was used to copy the source files to the target files.

[Sandip Ghosh]

You can consult with the respective EMC guy. EMC can copy the data from one system to other system. What they do is, they makes a mirror copy of your Array to the other Array and after that they taking out the old one. In that way your down time will be minimum.

Sandip

[Kevin Wright]

Keeping the original special files may be impossible, but for copying raw partitions, use dd to copy the data to your new partition.

[Byron Myers]

I've done this twice for DB systems, one using files systems (ORACLE) and one using raw spaces (INFORMIX) with EMC disk. What we did was attach the new EMC to the server while keeping the old EMC connected. We then mirrored the lvols (raw volumes) to the new EMC, then broke the mirrors to the old EMC. If your LUN sizes on the new EMC are the same size or smaller than you old one, there will be no problems in doing this. Obviously, you will need to manage your I/O cards or get new/temporary ones to do this. Also, you may have to mirror/break lvols in sets if your max LV, or max PV's in each VG are small. If money is a concern, this is a good way to go. Otherwise, spend gobs of money having EMC essentially do the same thing at the back-ends of the EMC units. Because you are doing this at the LV level, Sybase won't know the difference. The DB can even be online while you mirror/break mirrors.

[Martha Mueller]

I agree with Byron. We have used this same method of mirroring data from our internal disks to a SAN array ( emc clariion fc4700 ). The only thing that might give you a problem is the number of volumes that you can have in your particular volume group. To my knowledge, you can only mirror within the volume group, and the volume group has a limit to the number of physical volumes that you set when you create. You would have to add the new lun's as disks into the volume group before you could mirror to it, and that might be where you run into the limit.

[Sandip Ghosh]

You can do pvmove also.
Add the disk from new EMC array to the existing VG . Then do a pvmove from old disk to the new disk. But in theses case the device name for the raw volume will get change and accordingly you have to change it in the Sybase.

Sandip

[Gary Yu]

Hi,

If you are using EMC's SRDF, things will be easy:
1. connect the 2 disk using SCSI cable or fiber optical, and set the new disk as R2 host(remote mirror host)
2. using vgexport -m -p on the old disk(R1), and put the map file on R2, then using vgimport to import the VG imformation
3. synchronize R1/R2 using SRDF, EMC disk are pretty good at taking care of itself, that's the reason I like it.

Gary

[Jordan Bean]

Call EMC, find out if SRDF is an option.

Does the host have a spare HBA? Are the new hyper volumes the same size? Are the raw devices LVM logical volumes or entire physical volumes? Do you have MirrorDisk/UX installed? Is it possible to use an database export|import pipeline? How about dd?

[John Knapp]

Sorry for a lack of information but all of you have great ideas. Here's my limitations:

We don't have the funding to do SRDF
We don't have HP/UX Mirroring
Our source array has 4.2GB hypervolumes; our target array has 11.6GB
I don't think I can do the PVMOVE because 10.20 does not support a MIXED physical volume Volume Group (4.2GBs & 11.6GBs)

Kevin's recommendation to DD the special device files is probably the way I will need to go but I need to get my DBA to say he/she can modify the Sybase internals to point to the new names of the copied special device files. They are not sure if and how to do that ... I would have thought Sybase could have told them out right.



What I would like to do is not destroy my source files so I can use them as a quick back out scenario.

[John Knapp]

Also my Sybase database files are LVM partitions made through SAM ... not absolute hard slices from spindles.

If there was a way I could:

dd if=/dev/Sybase/sybsystemprocs of=/dev/NewArray/sybsystemprocs bs=?????

and then

mv /dev/Sybase/sybsystemprocs /dev/Sybase/sybsystemprocs.orig

and then

mv /dev/NewArray/sybsystemprocs /dev/Sybase/sybsystemprocs

?????? Any thoughts?

[John Knapp]

After a couple of day & poking & prodding ... Sybase came back to us and said .... Yes there is a way to do this migration pain-free.

There is a Sybase utility/facility called mirroring which does exactly that ... logically mirrors its database files.

My DBA has reading homework to do and the both of us will be testing next week or so.


Thanks for all the suggestions but this vendor method of migrating from one disk to another appears to be the best way.

Will let you know how it pans out.

[Kent Chow]

Just by way of clarifying your crack about Sybase not being in the business of answering Sybase questions, what is the status of your support under 11.03? I believe that product was end of lifed several years ago. Mirroring is the way to go, I've done it many times, it works well and is dead easy to implement.

[John Knapp]

Phil .... you're right. Sybase v11.03 is not supported any longer but we do have a path to jump to 11.09. I am glad you had some experience with the mirroring facility and if you can pass anything our way .... it would be greatly appreciated.

I haven't sat down with my DBA to go over the finer details of the task(s).

[Kent Chow]

The only snag that I ran into once is that syslogs wasn't on its own device so I had to move it using sp_logdevice (I don't make that mistake any more). I make sure all my data is on raw partitions so I just create other equally-sized raw partitions and use 'disk mirror' and 'disk unmirror' to create mirror copies and then break the mirror. You might run into some restrictions if mirroring filesystem to raw or vice versa, depending on your async i/o situation. Cheers.