Data Migration

Dom_71

Dom_71

New Member
Hello

I am looking for some advice regarding the migration of data between two RHEL 5.2 servers running Progress V10.

We are simply looking to aggregate a copyof databases from Server A to Server B. They will have the same file structure on the target server and I wondered what the best method would be to achieve this. My original thoughts would be to lock out the users a perform an online back-up, as you can tell I have little to no experience with progress

Kind Regards

Dominic
 
It depends on how big the databases are and how much down time you can affort.
I think the easiest way is to stop the databases, make a backup (probkup), and then restore at the new server.
You could also stop the databases and just os-copy them to the other server, if the physical location in the filesystem doesn't change then that is enough to start the database at the new server (after you enabled AI ofcourse). Otherwise you have to do a prostrct repair to make the database aware of its new location.
If you do an online backup with users still logged on then you must, after you restored the database at the new server, stop the old database and apply the last AI(s) to the database at the new server. Enable AI again and start the database.

HTH,
Casper.
 
What is the purpose of these copies?

Is this a one-time event or something that you need to do routinely?

Do the databases need to be exact copies as of a specific point in time or do they just need to be approximations?

Do you need tocontinually update the databases (as in a "warm spare" or "hot spare")?
 
Thanks for the prompt and descriptive replies.

This is a one off event, but will be repeated in Dev, QA and Live. Once migrated, the source database server will be decommissioned. We have the opportunity to have a system outage for this, so we can perform the backup whilst all users are logged off. I assume by shutting down the DB prior to backing up will ensure there are no outstanding transactions?


Kind regards

Dom
 
Then, as Casper says, shutdown the source db, probkup & prorest are your friends.

I would, of course, test it ahead of time to make sure that I have all the steps down right, know how long it is going to take etc. For test purposes I would likely use an online probkup -- that way you don't need to take an outage (and you don't really care how well synch'd the data is).

An advantage to that is that you see what sort of structure you'll get, how much space it takes and so forth. The 2nd, 3rd & subsequent times that you restore you can restore on top of the target db -- that can save time if the db is large enough for that to matter.

Practice is especially important if you are new to these things -- you don't want to be posting "Urgent: how do I restore a backup?!?" at 3am Saturday night ;)

Also, since you're new to these things... make sure that you have after-imaging enabled on your production db. And remember that you need to re-enable it after restoring from a backup.
 
You must log in or register to reply here.
Back
Top