home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.databases.oracle      Overblown overpriced overengineered SHIT      2,288 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 483 of 2,288   
   Jim Kennedy to Angel Faus   
   Re: Speeding Intermedia Query   
   03 Oct 03 01:59:34   
   
   From: kennedy-down_with_spammers@no_spam.comcast.net   
      
   "Angel Faus"  wrote in message   
   news:7a7a07a.0310020839.997c0b@posting.google.com...   
   > 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.   
   >   
   > But I do not honestly know their effectivity. What is the usual way of   
   > improving IO?   
   >   
   > 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   
      
   If you already know what the bottleneck is (and there is always a   
   bottleneck) then reduce it.  If the problem is that you need more IO then   
   you have to find a way to increase more IO.  That may mean multiple   
   controllers and multiple disk drives .  It depends upon where the bottleneck   
   is.   
      
   Jim   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca