Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Update of Clobs *Performance*

RE: Update of Clobs *Performance*

From: Gogala, Mladen <>
Date: Wed, 3 Nov 2004 17:04:44 -0500
Message-ID: <>

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

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 []
> Sent: Wednesday, November 03, 2004 4:18 PM
> To:;
> Subject: RE: Update of Clobs *Performance*
> -----Original Message-----
> From:
> []On Behalf Of Anthony Molinaro
> Sent: Wednesday, November 03, 2004 3:35 PM
> To: Mark W. Farnham;
> 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.
> --
Received on Wed Nov 03 2004 - 16:00:27 CST

Original text of this message