That its not as easy as just using embedded sql.
That kind of duhveloper should quit immediately and
get a job in sales or damagement, since they aren't
interested in doing anything properly.
That kind likes to see the glitter on the screen and
cares little about what goes on behind the
Oh, you have no idea. I could show you code that would make your hair
stand on end. The manager of that department believes in working in a
complete vacuum, and there is so much custom and undocumented code here,
the management above him is terrified of ticking him off. It used to
frustrate
[mailto:[EMAIL PROTECTED]]
Sent: Friday, April 26, 2002 9:18 AM
To: [EMAIL PROTECTED]; Seefelt, Beth
Subject: Re: Curious question about flushing the Pool
That its not as easy as just using embedded sql.
That kind of duhveloper should quit immediately and
get a job in sales or damagement, since
Tim,
I've had opportunity to tune the database in an attempt to fix
a poorly ( very ) designed application. This app may well
benefit from CURSOR_SHARING=FORCE, but that would
negate the use of histograms on one table that makes good
use of them.
That parameter may also have an effect on
I'll second that suggestion!
To extend the analogy, how about a recycle pool for them?
(So they don't fragment or otherwise clutter up the keep pool.)
How about adaptive auto-pin in the keep pool based on execution
frequency?
(Never mind... Probably not really necessary. I'd settle for the LRU
Comments? Corrections? Rants?
I'll go for rant...
I've had long and painful experience with a few pathological applications.
One in particular contained hundreds of sets of common SQL statements -
varying only in the literal values. Many were executed hundreds of
thousands or even millions
True - but then you're up for a definition of what
constitutes filthy?
A query like
select to_char(x,'...'), substr(y,1,3),instr(..)
(ie insert any appropriate Oracle function that could
have static numeric/character arguments)
and suddenly its filthy...Still, I'd like something
more dramatic
Minor correction, cursor_sharing did work in versions under 8.1.7.3 (I
used it in 8.1.6) but there was a bug relating to very specific usage.
I never encountered it, I know you can look up the details of the bug
on Metalink.
Having said that, I used cursor_sharing=force instead of flushing the
okay, who do you still know inside Oracle who can push this
enhancement? sounds eminently reasonable to me!
Rachel
--- Cary Millsap [EMAIL PROTECTED] wrote:
I think an excellent Oracle kernel enhancement would be to bias in
the
LRU scheme against SQL that uses literals, just like the buffer
Wow, I think that's a brilliant idea. It would be a huge benefit to me, where all of
our code is VB, and the developers refuse to use bind variables. My sql area is .5 GB
and is 95% garbage.
-Original Message-
Sent: Thursday, April 25, 2002 9:03 AM
To: Multiple recipients of list
I lost the fight to have the code fixed, and so turned on
cursor_sharing. Worked like a charm
Been there, done that... but now I feel better knowing that a tenacious
goddess of the DBA battlefields also lost this fight. :-)
It's a tough fight when embedded SQL is scattered all over the place
It sounds a cute idea at first sight (pardon the mixed
metaphor) - but then what do you do about the situation
where you deliberately have a handful of versions of
the 'same' SQL which are identified by the presence of
a literal string; or the SQL that you build with one
literal and many binds
So have you tried dropping your SGA to 275MB
so that the stuff that is useful can be found quicker
and latches are held for a shorter time ?
Also consider looking at cursor_sharing - it's
a band-aid but it can work well in extremis.
Jonathan Lewis
http://www.jlcomp.demon.co.uk
Author of:
Some truisms I've found after losing the fight at several different
locations:
1) If the programming staff was there before you got there, you will
lose every fight
2) If the programming staff was hired after you got there, but has a
prior working history with management, you will lose every
Beth,
What reasons do your programmers give for not wanting to use bind variables?
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Thursday, April 25, 2002 8:43 AM
Wow, I think that's a brilliant idea. It would be a huge benefit to me,
where all
Greg,
That its not as easy as just using embedded sql. I don't agree, it
takes just a little bit more thought and a couple extra lines of code
per call, but I lost that battle...
-Original Message-
Sent: Thursday, April 25, 2002 4:40 PM
To: Multiple recipients of list ORACLE-L
Rachel,
Shall we crown you the Jerry Quarry of Oracle DBAs?
-Original Message-
Carmichael
Sent: Thursday, April 25, 2002 12:09 PM
To: Multiple recipients of list ORACLE-L
Some truisms I've found after losing the fight at several different
locations:
1) If the programming staff
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rachel
Carmichael
Sent: Thursday, April 25, 2002 1:09 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Curious question about flushing the Pool
4) If you haven't convinced the development
Hey Dan! I've seen Jerry Quarry fight, he's done better in his fights
than I have in some of mine!
did you ever do the startup tests we talked about?
Rachel
--- Daniel W. Fink [EMAIL PROTECTED] wrote:
Rachel,
Shall we crown you the Jerry Quarry of Oracle DBAs?
-Original
begin rant -
It's *ALWAYS* a good idea to try to understand the underlying causes, for
any and every situation. Too often people attempt to attack new problems
with the same approach that they used before (or heard some guru advise),
in a different context, in a different environment,
I think an excellent Oracle kernel enhancement would be to bias in the
LRU scheme against SQL that uses literals, just like the buffer cache
algorithm biases against blocks that are read via full-table scan. Think
about it... What's the likelihood that a SQL statement that's filthy
with literal
21 matches
Mail list logo
