Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: cursor_sharing = force? (issue with ref cursors)

Re: cursor_sharing = force? (issue with ref cursors)

From: Sybrand Bakker <postbus_at_sybrandb.demon.nl>
Date: Fri, 29 Mar 2002 19:38:13 +0100
Message-ID: <rnc9auo8srutcdkiham24gpgtk47et2tap@4ax.com>


On Fri, 29 Mar 2002 13:39:17 -0000, "Paul Brewer" <paul_at_paul.brewers.org.uk> wrote:

>The
>developers tell me that it is much simpler to program ADO that way, so I am
>trying to anticipate possible performance issues and see what might be done
>given this constraint.

I wouldn't believe that. I have seen too much jdbc code where using bind variables would only result in 2 or 3 lines extra code. In that particular case anything that couldn't be done by means of copy and paste was just asked too much.
My experience tells me most developers are pretty damn laze, and they really should be managed by someone who *really* knows, and that person should be provided with a whip.
That said, and I don't remember where I picked up that suggestion, there is using bind variables and bind variables. If those hard-coded literals are being used for lookup selects, especially if the where clause includes the primary key, that is just pretty damn awful, as it implies your application not using bind variables will become *completely* cpu-bound and unscalable. If on the other hand you need to retrieve data, and the distribution of the where clause column is skewed, the statement is being issued only every so often, the extra cpu may not outweight the use of a proper execution plans. Of course cursor_sharing = force would hurt that concept, as it can be applied indiscriminately only.

So, as usual: it depends.

Just my 2 eurocents

Regards

Sybrand Bakker, Senior Oracle DBA

To reply remove -verwijderdit from my e-mail address Received on Fri Mar 29 2002 - 12:38:13 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US