Re: *****SPAM***** RE: Differences between Oracle and Progress, actually starting point for considering any migration from Oracle to anything else...

I remember talking to our progress DBA. I don't think it has the kind of metric collection that Oracle has. Progress is a real niche market. The gusy there claimed it was big in the manufacturing sector. If you are interesting in progress just as something new to learn there is a pretty popular Progress forum/website out there somewhere.

The progress developers swear by it. To be fair our progress developers produced. It seemed like they were able to develop code much faster than the java team since it was a 4 GL environment and they had to write alot less code.

However, since progress is such a small market the odds of you working on a team that is using it is pretty small. Progress has actually developed an Oracle engine where developers code in progress, but the middle tier generates sql. Probably to try to expand their market space. It was pretty difficult to figure out where bad sql came from since when you go back to the code its basically written as a loop structure.

I really don't know how many high end systems are run on Progress. Since the market was so small Progress developers seemed to move around the country going from project to project.

• Original message -------------- From: "Niall Litchfield" <niall.litchfield_at_gmail.com>

On 3/20/07, Powell, Mark D <mark.powell_at_eds.com> wrote:

While using a physical stopwatch is a valid end to end timing method (from customer enter to response), this method definitely lacks precision for timing individual database operations. I can see some humor in running across this recommendation.

I tend to agree, whilst it's an absurdly amateurish approach, it does at least have the benefit of doing the right thing, the section this comes from essentially boils down to

1. Determine the transactions that matter to your business.
2. Measure the response time
3. create baseline
4. monitor against baseline Now that is clearly ripe for maturing into a method R type approach. The measurement device is inappropriate and the granularity appears to be the entire transaction, but at least it is the right general idea.

Unfortunately the lack of granularity is probably responsible for the next bit that starts

"Always analyze problems starting with the slowest resource and moving to the fastest. Thus, the first place to start is disks, then memory, and finally CPU efficiency." Hmmm - because I've never seen a system starved of CPU with idle disks, no sir not me.

Mind you IIRC this thread started with a question about the relative merits of Oracle and Progress for some existing systems, it seems to me that in this context the right place to start is not relative performance, but wether the application will run at all. My guess is that many/most Oracle apps will not run without considerable effort on Progress and vice-versa - and the ones that do are probably platform agnostic and perform badly everywhere anyway.

I'd much rather take the point of view that we are in the business of supporting applications, not databases and that the right database choice is driven by the application which in turn is driven by business need. A bit like the reason that so many corporations run windows - not because of a love of microsoft, but because the applications that they need run on it.  

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info 
--
http://www.freelists.org/webpage/oracle-l