Scripting+Dump & Reload

B

bmrh

New Member
The company that I work for has been using a certain ERP package for over 10 years that uses a progress DB. Due to the age of the database and our limited knowledge of Progress, our system has become quite sluggish even after moving to newer and faster servers.

After doing a bit of research it looks like a fair attempt at speeding up our system is to dump & reload our larger data tables-- most of which have a scatter factor of 6% or more and are between .5-1Gb.

I've found the command below for dumping tables

Code: 
proutil db-name -C dumpspecified
[owner-name.]table-name.field-name operator field-value
directory

and the follow command for loading

Code: 
proutil db-name -C load filename

My question is, how could I create a script file and run it from a console where 20, or so, tables are automatically dumped and then reloaded?

My progress experience pretty much doesn't extend past installing the DB engine and restoring back-ups. I'm sure you c an understand why I'd prefer to script the 40 or so commands in one file instead of executing those commands manually.

Thansk guys!
 
What OS are you running? Scripting a UNIX derivative is very different from scripting Windows.

Dumping and loading *might* help performance. But a great deal depends on your circumstances. You will get the maximum benefit if you reload into a new database that has been optimized for your data. For some ideas on that check out this article Surprising Benefits of Storage Areas.

You also almost certainly have a lot to gain from a review and analysis of your current configuration. You could post more about your situation, how the db is setup, startup parameters, version of Progress, workload and so forth and we could try to point out some things. Or you might want to bring in a consultant ;)

I also strongly suspect that you are on an old and unsupported release of Progress. Upgrading Progress is, of course, very important but as you upgrade you need to make changes to your configuration in order to leverage new features. Again, post the details and maybe we'll have some ideas.

As far as scripting goes -- if it's UNIX it's pretty easy. Just write some scripts ;) If it's Windows it isn't so easy. .BAT files are a serious PITA. For an overview of one approach to the D&L process checkout the D&L PPT here: http://www.greenfieldtech.com/downloads/downloads.shtml

BTW -- binary dump is fine but you probably shouldn't bother with the dumpspecified option unless you have an unusual situation.
 
Thanks for the response, however, we tested manually dumping and reloading a few of the data tables and it was of no affect.

Unfortunately we won't be needing a consultant either. The speed of the database is somewhat uncomfortably slow, but we won't be using it for much than a year, any way.

In the mean time, I'll keep looking into other solutions when I get the time. (This isn't a high priority problem for me).
 
The greatest performance benefit of my career was a Progress dump & load (and yes I have spent my share of time on performance problems). We had some overnight job type thing that went from 10 hours to under an hour with nothing more than a dump & load. Since then I have seen many times with similarly great results, though maybe not quite that spectacular.

Back to the original question - 20 tables? That's bus fare, I'd just type it!

Who besides me is sad to see someone else leaving Progress? Anytime I see Progress mentioned on the Internets (outside sites like this one), it always seems to be in the context of "we have this really old thing that we have to keep around just a little while longer until we can cut it loose".
 
"We'll only be using it another year or so" is a familiar refrain.

I've got some customers who have been repeating it for going on 15 years now. One of them has spent enough money on replacement systems (which weren't implemented) to subsidize the financial system bailout ;)

Even if it is true -- if your users are suffering from poor performance there are almost always things that can be done about that that are worth doing and which will improve end user productivity. Sometimes a dump & load is needed, sometimes it is something else. Of course if you pursue that you may just discover that those reasons for moving to something else aren't actually especially pressing...
 
Our move is by a corportae mandate. I work for a smaller company that was bought by a MUCH larger corporation a few years ago.

They've whated to migrate us to their system since we were initially purchased. I understand that "one year off" doesn't always mean that, but this is a change that will definitely happen. Eventually :shrug:
 
Not to totally hijack this thread, but I think the REAL tragedy is how much money gets blown on replacement systems, successful or not, developed in J2EE (or whatever) that impose gigantic complexities for no apparent benefit (in the vast majority of cases). For business apps, Progress is so awesome, and hardly anybody knows it.
 
bmrh said:
Our move is by a corportae mandate. I work for a smaller company that was bought by a MUCH larger corporation a few years ago.

They've whated to migrate us to their system since we were initially purchased. I understand that "one year off" doesn't always mean that, but this is a change that will definitely happen. Eventually :shrug:
Click to expand...

No doubt.

That's usually how it goes.

But even so -- if your users are suffering it is very likely that relief can be had. Even if it is only a short break before they go through the hell known as "the new system" ;)
 
You must log in or register to reply here.
Back
Top