RE: Update of Clobs *Performance*

Mladen - Excellent! And just to add one further thing, since performance on
a complex system is somewhat subjective and subject to many variables, there
is a tendency, having spent the big bucks for a new box, to defend the
correctness of that decision. Unless, in the situation that Cary points out,
the performance spirals downward to the point that nobody can claim that it
is better.

Dennis Williams
DBA
Lifetouch, Inc.

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Gogala, Mladen
Sent: Wednesday, November 03, 2004 4:05 PM
To: 'mwf@xxxxxxxx'; amolinaro@xxxxxxxx; oracle-l@xxxxxxxxxxxxx
Subject: RE: Update of Clobs *Performance*

Just out of curiosity, does anybody know what event is his 
procedure waiting for? We all saw the source code, the fact that
there is only a single execution, but I haven't noticed any 
information about the event the procedure is waiting for.
With the insufficient information, my advice always to 
get a bigger for 4 reasons (sorry Cary, don't shoot me)
1) Bosses just love buying bigger boxes and allocating 
   bigger budgets. For some reason, many managers consider
   new toy much better solution then having the problematic
   software either optimized or replaced. It never fails to
   start the fabled IBM's "spiral of death".
2) HW manufacturers pay out really decent coommisions to the 
   crooked consultants.
3) It's so much simpler then profiling and optimizing the 
   application.
4) I could use a decent commision to try out that new Honda Civic Hybrid.
   and add few more nodes to my home LAN.

My conclusion is that a consultant like me can never go wron by advising
a new box. If you give me the response times, the expected response time
the information about the events that the application is waiting for, the 
size information,whether the table is analyzed, and whether there are usable

indexes , then I'll really have to work. I really do prefer advising the
"new
box"  whenever possible.


--
Mladen Gogala
A & E TV Network
Ext. 1216


> -----Original Message-----
> From: Mark W. Farnham [mailto:mwf@xxxxxxxx] 
> Sent: Wednesday, November 03, 2004 4:18 PM
> To: amolinaro@xxxxxxxx; oracle-l@xxxxxxxxxxxxx
> Subject: RE: Update of Clobs *Performance*
> 
> 
> 
> 
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx 
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Anthony Molinaro
> Sent: Wednesday, November 03, 2004 3:35 PM
> To: Mark W. Farnham; oracle-l@xxxxxxxxxxxxx
> Subject: RE: Update of Clobs *Performance*
> 
> 
> Mark,
> 
> >there is a good chance it will blow up later as the tables grow.
> Kidding right?
> 
> << not kidding at all. I've seen plenty of toy monolith 
> designs blow up << when unleashed on big or growing data. 
> "But we haven't changed the programs at all!"
> 
> You bring up a good point, but I disagree. My reasons are:
> 
> 1. one commit will outperform the counter.
> << That is something you can measure, but you can't possibly 
> know the answer without testing. << There is a cost to 
> accumulation of UNDO, and generally you reach a plateau where 
> the cost << of extra commits is balanced against the cost 
> overhead of accumulated UNDO and then if << you continue 
> adding to the size of the update between commits performance 
> will degrade. << Sometimes it is even worthwhile to measure 
> to make sure you pick a commit frequency from << the plateau.
>
--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l

Other related posts: