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_at_rsiz.com] 

> Sent: Wednesday, November 03, 2004 4:18 PM

> To: amolinaro_at_wgen.net; oracle-l_at_freelists.org

> Subject: RE: Update of Clobs *Performance*

> 

> 

> 

> 

> -----Original Message-----

> From: oracle-l-bounce_at_freelists.org 

> [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Anthony Molinaro

> Sent: Wednesday, November 03, 2004 3:35 PM

> To: Mark W. Farnham; oracle-l_at_freelists.org

> 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