Thanks to all for the advice. I plan to test sometime soon and will post results on
how it works for us.
John
-Original Message-
Sent: Wednesday, August 20, 2003 12:44 PM
To: Multiple recipients of list ORACLE-L
Like I said, it works fine here, but then again I also said, YMMV:
I was curious about your statement the kernel only peeks once per
session. I wondered if another session that executed the same statement
would be impacted by the peeking or would the optimizer reparse the
statement.
So I set up a test. Million row table with 2 columns. c1 - number, c2 -
date. C1
Hi!
How did you check which execution plan was chosen? Explain plan and
autotrace lie, use 10046 or v$sql_plan instead.
For num_buckets, dba_tab_cols view substracts one from real bucket count for
some reason. To get real value go to base tables and check row_cnt from
sys.hist_head$ or just
May be it should say that the peek is only done at the hard parse stage (seems
to be implied by example of Jonathan Lewis)
On Friday 22 August 2003 00:09, Tanel Poder wrote:
Hi!
How did you check which execution plan was chosen? Explain plan and
autotrace lie, use 10046 or v$sql_plan
Subject: Re: cursor_sharing in 8.1.7.4 - good or bad
I was curious about your statement the kernel only peeks once per
session. I wondered if another session that executed the same statement
would be impacted by the peeking or would the optimizer reparse the
statement.
So I set up a test
Anjo,
My tests in 9.2.0.1 on W2k showed, that each session can get it's own
execution plan if it's first execution's bind and histogram values require
to. If a different execution plan is computed (only soft parse needed - hard
parse count stayed zero for given session), then just a different
Title: Message
I know
of a site that has been using cursor_sharing=forceon 8.1.7 for over two years now with no
noticeable side-effects (except that many of the
programmers still think it's okay to use literals).
Gudmundur
Does anyone have
any experienceusing cursor_sharing in
: raju pa
[mailto:[EMAIL PROTECTED]Sent: Tuesday, August 19, 2003 7:34
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
cursor_sharing in 8.1.7.4 - good or bad
Point noted. Excellent posts from both you and Walt. I guess that
is what theforum is for. To present one's experience
Like I said, it works fine here, but then again I also said, YMMV:
MYSID;/usr/oracle uname -a
HP-UX mybox B.11.00 .
MYSID;/usr/oracle sqlplus /
SQL*Plus: Release 8.1.7.0.0 - Production on Wed Aug 20 10:43:20 2003
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Connected
: Cary Millsap [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2003 11:59 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: cursor_sharing in 8.1.7.4 - good or bad
And don't count too heavily upon 9i's bind value peek capability.
Here's a simple test that Jonathan Lewis conjured up
Hi!
Another interesting thing is that explain plan command doesn't often give
you correct information which execution plan was used when using bind
variables and histograms. You see index acces in v$sql_plan and 10046 trace,
but explain plan keeps talking about FTS. (since autotrace uses explain
Hi,
No. I recommend that you do not change cursor_sharing if you are doing it just to get rid of 4031. There could be serious problems. ora-600 etc.Maybe Oracle has fixed everythingin latest 817 but I suggest not to take that chance.
For 4031 you can do the following :pin pl/sql sql preferably
True, but using binds isn't always an option, like when running a 3rd party
product. I also could not justify weeks of recoding homegrown software for
the relatively minor gains we would have using binds. And scalability (or
lack thereof) didn't seem to be argument enough.
We're using CS=F on
of list
ORACLE-L
Subject: Re: cursor_sharing in
8.1.7.4 - good or bad
Hi,
No. I recommend that you do not change cursor_sharing if you are
doing it just to get rid of 4031. There could be serious problems. ora-600
etc.Maybe Oracle has fixed everythingin latest 817 but I suggest
not to take
Point noted. Excellent posts from both you and Walt. I guess that is what theforum is for. To present one's experience without trashing someone else's point of view.
Since you have first hand experience on the latestI guess John should listen to both of you first. Thanks
"Jesse, Rich" [EMAIL
And don't count too heavily upon 9i's bind value peek capability.
Here's a simple test that Jonathan Lewis conjured up last year:
PREPARATION. Create data for select c1, c2 from t1 where c1 = :bind1,
where different bind1 values could have different paths if we used
literals.
1. flush shared
16 matches
Mail list logo
