I am planning a migration of a Baan database instance from some old 2/4gb drives to 4 36 gb drives.

Initially I was planning on dd'ing the data from the old devices to the new, repointing the symbolic links and bringing the informix instance online. Initially this is just for a test. The old instance will still remain intact and need to be returned to operational status afterwards.

Are there any files that Baan maintains, external to the database which will cause problems for this approach. We are planning on running several jobs through the system to verify the performance of the new drives.

The purpose of the pre-test is to determine if the performance of the new devices is sufficient, without the need to physically reloading the database and gaining additional performance improvements from recreating the instance and reducing extents etc.

Thanks

Mark

Hi, Mark

BaaN is maintaining a file "inf_storage" which is used during creation of the tables, where new tables to be created in which dbspace and what would be Extent size.

If you have installed new devices for database, then how r u planning to move data from old device to new one, I don't think just repointing the links will work.

We are having 200 GB of data on raw devices, and planning to switch over on ALPHA ES-40 server very soon, so, all data neds to be shifted to new device.

Procedure I am going to adopt, will take 0-level backup and then restore it on new device, before this all dbspace needs to be created on new device with same size of chunks as in old devices.

Any suggestion from your side will be appreciated.

Rgds

Restoring is one way of doing it. If you have used relative pathnames then this should be fine. If you have used full pathnames then you are not going to be able to replace the devices as easily. When using relative pathnames, all you have to do is create a new directory tree with the same device names as listed in your existing production env. Assuming you are using ontape, when you start the restore you must cd to the directory that is the 'parent'. So, if your devices are named something like ./mydb/rootdbs, you must cd to the directory that contains mydb directory. Issue the ontape restore command and go get a cup of java, its that simple.

Since the new instance will look the same as the original, baan will be ignorant that the data is now in a different location.


Alternatively you could use dd in place of a restore. Make a backup [preferably restore it somewhere to prove its good] and then use dd to copy the chunks. I have done this on numerous occassions without any problems whatsoever.

With fullpathnames you have more of a problem because this information is stored within the rootdbs - in the 1st 12 pages. I think its on page #3. I have used a binary editor to mess with this in the past, but do not recommend it. There are only 2 ways to deal with this, symbolic links and a physical rebuild. A physical rebuild is a good idea if you are trying to solve some other performance issues, otherwise why bother?

Hopefully you used symlinks when establishing the system initially. Point the devices listed in onstat -d to where you want them to be. If you get it wrong, your going to be embarrassed very fast unless you can restore the pointers to where they were meant to be and restore. Make sure you have a script that can put the links back as they should be...

In this instance, I recommend you test you scripts etc on a separate machine. It is the only way to be 100% confident that they are correct.

Mark

Just a thought, are you switching to a new box with a different architecture to the current one? If that is the case then your only choice is a rebuild from unloaded data.

The restore/dd will only work if all you are changing are the disks. Its not necessarily the way to go if anything else is being changed.

Mark

yes, we are changing to new architecture, so restore/dd can't be used, only way is either restore the whole database after 0-level backup onto the new device or can go for data export/import.

Badre

Restore cannot be used for the same reason that dd is unusable. The backup contains physical pages that are dependant upon the architecture.

I think that you will find that the only way forward is to rebuild. The easiest, and fastest way is to connect the 2 servers and copy the data server-to-server.

Mark

HI, Mark,

we r using raw devices for informix database, so data can't be copied like any other files from one server to another.

Now a days taking 0-level backup time is approx. 5-6 hrs in our case and then its restoration will take approx. 16-18 hrs. A year back when we were having only 60-65 Gb of data restoration takes 10 hrs.

anyway I will explore all the possibilities very soon before actually migrating to new server.

Badre

I know this may seem elementary but please keep in mind the distinction between the onbar "whole" backup and the level 0 backup. A whole backup is required if you are going to be moving the data to another server.

-- Jim