Migrating from 9.1D to 10.1B

refurbished

refurbished

New Member
We are about to make a move from Progress 9.1D currently running in a unix environment, to Progress 10.1B running in a linux environment. I searched these forums for a while trying to find some straight forward instructions on how to "dump" a Progress database and import it into a newer version, but was not successful with finding the info I need. Basically all I need to know is how to migrate the 9.1D database to 10.1B. Here are some other questions I've had:

1. How would I go about getting a broad view of the database to get a feel for total database size, table sizes, number of records, etc?

2. Is there a command that will dump a Progress database to a flat file for migrating to a newer version, or is it possible to simply drop the binary database files into place on the new server?

3. Would it be beneficial to re-index the database during the move? Or, are there any other performance enhancing suggestions that could be implemented?

4. Is there anything we should do during the migration to prepare for replication using Fathom further down the road?

Thanks for taking the time to answer any of these questions!
Adam
 
I'm sure Mr. Bascom will be along at some point to give you more detailed advice, but here are a couple of answers for you.

1. You don't need to dump and load to make the change. There is a conversion utility which will change it in place.

2. However, chances are that you will want to dump and load because you will want to take advantage of Type II areas in the database. That is a whole topic in itself.

3. If you dump and load, you will of necessity have rebuilt the indexes. You can elect to either build them during the load or separately afterward.

4. You can find the dump and load utilities on the dictionary menu, which is on the Tools menu from the editor ... among other possible locations.
 
The easiest way to migrate your database is binary dumping and loading your database. If you plan to dump and load in v9, you can't use type II storage. The better way is to first migrate your old database to v10, and then perform the dump and load.

Follow these steps:

On your old database:
1. Migrate the database to 10.1B
2. Change the codepage (proutil db -convchar) to the codepage of your new database
3. Binary dump your database (proutil db -C dump tablename)
4. Create a datadefinition (df) file
5. Dump your users and sequences (using data administration)

On your new system
1. Create your new 10.1B database (use type II storage)
2. Create your tables using the df file
3. Change the codepage of the new database
4. Load your database using proutil db -load... Indexes can be build while loading.
5. Load your users and sequences using data administration

Ready
 
To answer some more questions:

To get a clear view of the size, number of records etcetera you can do a dbanalys:

proutil path-to-database/databasename -C dbanalys > somefilename

This gives you complete information about indexes en tables in the database.

Since your Linux environment is most likely on an intel machine you have to do a dump/load of your database. (binary is the simplest most efficient way and depending on your database it may or may not help to rebuild indexes during the load phase).

Since you have to do a dump load, this is the perfect opportunity to take advantage of type II storage area's. You have to read up on this to make a good plan to migrate your database.

You can look at some interesting articles here:
http://www.greenfieldtech.com/index.shtml

And lots of information on dump/load, rpb, TYPE II storage area's etc. can be found at www.peg.com

You can always ask for more specific questions here ofcourse.

HTH,

Regards,
Casper.

HTH,

Casper.
 
There is no One Right Answer that works for everyone every time...

However, generally speaking, it is usually best to:

1) Plan you target configuration.
a) Get table size and row size data from "proutil dbname -C dbanalys"
b) Get table activity data from a tool such as ProTop
c) Group tables into areas based on attributes such as average row size and activity levels.
2) Execute a dry run to verify sizing and timing.
3) Test the converted system.
4) Repeat until satisfied.
5) When satisfied that testing is complete and the timing of the conversion is acceptable schedule the production conversion.

For the dry runs and the actual conversion:

(These steps can be executed ahead of time)

0) Freeze schema changes.
1) Dump the schema into a .df file.
2) Massage the .df file (I usually remove AREA information).
2) Build your (void) target database. Set the bi block size to 8 or 16 and the bi cluster size to a large value (65535 is usually good) and do a bigrow. Enable large files. Set the ai block size to whatever you choose for the bi block size.
3) Load the .df file.
4) If you removed the AREA info use a tablemove script to put tables and indexes where you want them.
5) Dump any static data (_user usually qualifies as static data)
6) Load the static data.

(These steps delimit the necessary downtime window)

5) Kick all users out of the source database and shutdown any batch jobs and so forth. Ensure that users stay out and that batches don't run.
6) Start the dump of the source database.
7) Start the load of the target database.
8) Verify success.
9) Set the bi cluster size to something more reasonable.
10) Enable after-imaging.
11) Make a backup.
12) Make the system available for users!

The devil, of course, is in the details. To answer a few questions:

1) Don't bother with an index rebuild prior to dumping.
2) It is well worth the effort to figure out how to run multiple simultaneous threads dumping and loading in parallel.
3) It is usually best to dump using -RO. (You might want to test it if you have a very fast server with lots of RAM -- as hard as it may be to believe I have seen systems that were slightly faster with a db server.)
4) Binary dump (and load) is fairly fast and portable and, in many cases, it is a good choice. But:
a) The scripting can be daunting.
b) Depending on version you may have to deal with 2GB file size limits
c) Depending on version you may be restricted to a single thread (or 2 threads) per table.
d) You will usually find that doing the index rebuild all at once after the load is faster than doing it inline (but testing may show that inline is faster -- especially if you have really good hardware)
e) Dumping to disk and then loading from disk and rebuilding indexes using disk scratch space results in a lot of IO.

4e is a good reason to look at: Highly Parallel Dump & Load
 
Wow! Thank you for the detailed responses. Unfortunately, I'm very green with the Progress database software so this will take some time for me to read up on the commands and processes for accomplishing most of this stuff, and the verbage with Progress is different that I'm used to, so that will take some time to read up on too. I'm sure I will be posting more specific questions here as I attempt to move forward.

Edit: I want to mention that the old and new databases will not be running on the same machine. Some of the input given was worded in such a way that it sounded like 9.1D and 10.1B needed to be on the same machine. I actually have to keep the old 9.1D intact until we're sure the move is successful and the software that accesses this database is "stable" with the change. Don't know if that makes a difference in anything. So basically, I want to dump out the old 9.1D database, move it to the new machine running 10.1B and do all the manipulation and loading in that environment.

Thanks!
Adam
 
There are a couple of wrinkles when distinct machines of different types are being used.

This rules out being able to upgrade the source database using "proutil dbname -C conv910" and the ilk prior to the dump and load. (That's a useful first step when you can take it because it sometimes gives you better tools for dumping.)

Having two machines also complicates things. Somehow the dumped files need to get from one server to the other. Usually you would use FTP or something similar to accomplish that. I like to use NFS mounted drives myself because it avoids extra scripting and allows you to use the fastest disks (usually the disks on the new box are faster).

BTW - one of the advantages of the technique outlined in the "highly parallel" presentation is that it can be used between two machines and two different operating systems.
 
You must log in or register to reply here.
Back
Top