Re: Speeding Intermedia Query

Hi,

First of all, thanks for answering.

> So you can't change the application which infers that the application is
> some sort of vender application.

I can change the application, but my application _needs_ to perform a dozen intermedia queries to create a single web page. This is an intrinsic bussines requirement, not a side-effect of poor implementation.

> Tom Kyte's book Expert 1 on 1 Oracle. I would look up stored outlines and
> see if there is something there. Additionally, I would call up the vendor
> and complain. Poorly written application code is over 90% of the time the
> reason the application performance and scalability are in the toilet. If
> you can prove it then so much the better. (do they use bind variables, do
> they parse once and execute many times, etc.)

Yep. But I did say that, as far as I know, the application code is well implemented. We do use bind variables, whenever we can we parse once and execute many times, etc.

> You need to find your bottle neck (statspack is a good tool to help with
> this) and then attach the problem that way. There is no way we can
> reasonably tell you how to speed things up without a lot of detailed
> information.

I have used statspack, and tkprof, and everything, and the conclusion is that the bottleneck is, simply put, that oracle _has_ to do a lot of work to do what I am asking it to do.

From you answers I gather that I did not correctly formulate the question.

Let me try again: supposing there are no big mistakes in the application, and supposing that we believe that there is a IO bottleneck, what is the most efficient hardware answer to this?

I can imagine some of them:

• Adding more disks and stripping the data between them.
• Moving to a 64 bits server with insane amounts of RAM.
• Spending huge amounts of dolars to get a RAC.

Any advice from the wiser ones would be appreciated. I promise to keep working in the application side of the question.

A final note: we are talking about reducing response time, not getting more throughput.

-angel Received on Thu Oct 02 2003 - 18:39:01 CEST