Informix: transit to new host

[Ralph Grothe]

Hello Informix wizards,

I have to swap the machines of an application that runs as an informix/weblogic server.

Unfortunately I haven't got the faintest Informix knowledge, and no DBA around to help (as usual).
(only put down the commands to start/ stop the instance through onstat)

I found out so far that the informix thing is using raw devices, which further complicates the task for me.

So far I installed an OS (11i) on the new machine, and created informix/weblogic groups and accounts with same uids and gids as well as same homes and login shells etc.

I will have to wait until downtime has come to transfer those users' homes and other stuff which is currently in use (e.g. informix installation dir, http server etc.)

Then I will also have to transfer the data from the raw devices.

Meanwhile I created the same LVM layout for the raw devices with the same naming scheme and symlinks (which seems vital for informix to run at all on the new machine).

My biggest concerns relate to the transfer of the raw data.
Since there is no filesystem there will be no obvious checks such as equal totals of inode numbers for me (to see if all got copied correctly).
I thought to accomplish the transfer via remsh and dd.

Is this feasible?
And what blocksize should I use?

Are there better solutions?

Unfortunately mirroring doesn't seem to be an option since the disks on both machines are only local to the respective box (no common disk subsystem, and no link other than LAN possible).

Suggestions are welcome.

Regards
Ralph

[Stefan Farrelly]

Ive used dd to copy raw lvols lots of times without any problems, but only from local disk to local disk, or tape to raw disk. Any blocksize from 64k-1024k is fine, performance wise.

Using remsh is going to be more of a worry because of block sizes over a network copy. You are going to have to experiment a little to see what will work (some block sizes will just fail with a network error). I would recommend starting at 64k.

As for dd'ing over remsh I would be far happier to ensure the integrity of the dd image before and after the copy as anything could happen to it over the network transfer.

I would certainly perfer disk to disk dd or tape to disk dd than remsh+dd. But if you must do it this way then if have space to dd the image to a file before you remsh/rcp it, sum it, rcp it, then sum it and check its exactly the same, then dd to a raw lvol from there. Something like that.

[Dietmar Konermann]

Just an idea... when you pipe through gzip locally and gzcat remotely then you get some additional checksumming (and depending on CPU power vs. network speed you may gain performance also). For a fast network give "gzip --fast" a try.

dd if= bs=256k | gzip -1 | remsh "gzcat | dd of= bs=256k"

Best regards...
Dietmar.

[Ralph Grothe]

Stefan,

you're probably right about assuming a bigger chance for data integrity when dd'ing disk to disk than via pipes through remsh.
I have ample disk space on the replacement server (of course that was one reason for excercising this).
The weak side is the current Informix server.
Of course I could use tapes as interim storage media, but the time spent on spooling scares me off.
Maybe I can find an unused big disk lingering around somewhere?
Then I could maybe even try some lvsplit/lvmerge with disk moval between both boxes?
The disk storage enclosure looks to me as if it carried hot-plugable disks (those with the blue lever at the front bottom).
I trust plugging would reset the SCSI bus?
Since all disks are Raid1 mirrored (through Mirror-UX) I think I could lvreduce the vg00 to free one slot, and refill the spare slot with my "flying" disk.
Would this work?
What would be the rough command sequence to do this if it worked?

[Marcin Gonet_1]

I would do the following:

- gzip rawdevices into compresses files via DNS:

cat /dev/vgXX/rlvol1 | gzip -c > /mnt/rlvol1.gz
...

- on the new server copy files to destination rawdevices:

gunzip -c rlvol1.gz > /dev/vgYY/rlvol1
...

To save time you can compress/uncompress files in parallel.

Regards,

Marcin

[Malcolm Weallans]

Ralph,
The safe way would be to archive the old server using either ontape or onbar and then restore to the new system. There are 2 files in the $INFORMIXDIR/etc directory called onconfig and sqlhosts. These would need to be copied to thenew environment before the restore.

What you are contemplating is not an easy task even for an experienced Informix DBA. I would advise you not to try using dd or similar commands.

If I were you I would find an experienced DBA to help you. Where are you located? I do have many contacts around the world who could help - at a price.

regards

Malcolm

[Marcin Gonet_1]

Ralph,

To make sure that the migration will be succesful I would suggest exporting the database and importing it on the new server using dbexport/dbimport. In my opinion this would be definitely the safest way.

Regards,

Marcin

[Rainer von Bongartz · Accepted solution]

Ralph,

There is no secure way to copy an INFORMIX Server using dd to a new machine.

This way you will also copy the so called Informix reserved pages which hold the information about database, servername chunks , hsotname and so on.

If you have your new INFORMIX server already running I suggest transfering the data via Informix export/import.

1) dbexport on the old machine
2) copy dbexport data to new box or use NFS to mount
3) dbimport on new machine.

Further Information is available under

http://publibfi.boulder.ibm.com/epubs/pdf/8324.pdf

But I also suggest you should look for an INFORMIX DBA to accomplish this task.

Regards
Rainer

[Stefan Farrelly]

If you have the hot swap disks with the blue lever at the bottom theyre Jamaicas, you can indeed swap them on the fly. All you need to do is an ioscan after inserting/removing so that HP-UX detects the change. You may get an error in dmesg when it happens but nothing to worry about, we do it all the time.

Good idea, lvreduce vg00 to free slots, refill with your flying disks, ioscan -f, note the /dev/dsk entries for the disk(s) you inserted, create a new vg (mkdir /dev/vgXX, mknod /dev/vgXX/group c 64 0x0?0000 where ? is a unique number not used by other vg's, then vgimport vgXX /dev/dsk/cxxxx ... which are the new disks you just inserted. This will create the lvols, you can then activate the vgXX and then dd the raw lvols (as long as lovls the same size).

This will work, dont it lots of times before.

[Seth Parker]

This is one of those things that seems like it should be easy, but it's not.

I went through a similar task back in July and it was nothing but problem after problem. The main issue is that Informix stores its information in a version specific manner. This means you can't just move the disks over and bring it up on a newer version of Informix.

But, having said that, if your raw disk is accessed through links in Informix (where you go to /dev/dbspace instead of /dev/vgraw/rdbspace), you might be able to do it.

If you were to install an identical version of Informix on the new machine (it has to be the *exact* same version), move the disks to the new machine in some manner, recreate the links to the raw disk, then bring up Informix, it *might* work. The only problem is that if it doesn't, your Informix database could get hosed.

The way I migrated my data was to use onbar, but that was a pain all its own. You have to integrate onbar with your backup package, install an identical version of Informix on the new machine, recreate your raw disk the same as it was on the old machine, and restore with onbar on the new machine (which means you have to install you backup package and integrate onbar again). It worked fine, but took a *lot* of work getting all the pieces to work together.

As for other options, I was told I couldn't use ontape to migrate data between machines and the docs (http://publibfi.boulder.ibm.com/epubs/pdf/4372.pdf) don't list ontape as an option for migration.

From my testing, Dbexport and dbimport were too slow to use for much data (or for a small maintenance window). I didn't try onunload and onload because onbar seemed like it was going to be easy (silly of me to think that).

Like several others have said, get a DBA with migration experience to do this for you if you can. It'll save you untold agony.

Good luck!