Path: news.f.de.plusline.net!news-fra1.dfn.de!newsfeed.hanau.net!newsfeed2.scan-plus.net!news.germany.com!out01a.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!postnews.google.com!u30g2000hsc.googlegroups.com!not-for-mail
From: Charles Hooper <hooperc2000@yahoo.com>
Newsgroups: comp.databases.oracle.server
Subject: Re: Slow SQL, too many logical reads ?
Date: 4 May 2007 16:53:25 -0700
Organization: http://groups.google.com
Lines: 65
Message-ID: <1178322805.645891.279390@u30g2000hsc.googlegroups.com>
References: <1178026044.339158.173310@n76g2000hsh.googlegroups.com>
   <1178039702.039366.18770@o5g2000hsb.googlegroups.com>
   <v8udnZ106fxZ6KbbnZ2dnUVZ8qeknZ2d@bt.com>
NNTP-Posting-Host: 63.158.169.118
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1178322806 29268 127.0.0.1 (4 May 2007 23:53:26 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Fri, 4 May 2007 23:53:26 +0000 (UTC)
In-Reply-To: <v8udnZ106fxZ6KbbnZ2dnUVZ8qeknZ2d@bt.com>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506),gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: u30g2000hsc.googlegroups.com; posting-host=63.158.169.118;
   posting-account=ytcoAwwAAADhCs0M3G1mFO5tqSfx4ge9
Xref: news.f.de.plusline.net comp.databases.oracle.server:197456

On May 4, 2:03 pm, "Jonathan Lewis" <jonat...@jlcomp.demon.co.uk>
wrote:
> "Charles Hooper" <hooperc2...@yahoo.com> wrote in message
> ALTER SESSION SET STATISTICS_LEVEL=ALL;
>
> (Run your query)
>
> SELECT
>   *
> FROM
>   TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS'));
> ---------------
>
> For instance, ALLSTATS (note, might want to flush the shared pool
> first so that Starts indicates the number of times that portion of the
> SQL statement executed):
>
> Charles,
>
> There is an option for display_cursor which is 'ALLSTATS LAST'. this give
> you the stats from the last execution of the query, and makes the shared
> pool
> flush unnecessary.
>
> --
> Regards
>
> Jonathan Lewis http://jonathanlewis.wordpress.com
>
> Author: Cost Based Oracle: Fundamentalshttp://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
>
> The Co-operative Oracle Users' FAQhttp://www.jlcomp.demon.co.uk/faq/ind_faq.html

Jonathan,

Thanks a lot for the tip (I was hoping that I was overlooking
something).  The impact of the plan is very hard to determine without
specifying the "LAST" keyword, or without flushing the shared pool
first.  Based on a very quick test, the Starts, A-Rows, Buffers
columns all increase in value with each execution, while the A-Time,
and Reads columns do not increase when the "LAST" keyword is not
specified.  When the "LAST" keyword is specified, the impact of the
plan is much more clear, but the READS column is no longer returned.

Just out of curiosity, do you think that DBMS_XPLAN is retrieving its
source data by querying V$SQL_PLAN_STATISTICS_ALL (or the underlying
views), and when the LAST keyword is specified, only returns those
columns which are prefixed with LAST_ ?  The reason that I ask is that
I am currently investigating performance problems with a packaged
application that is running against Oracle 10.2.0.2.  Due to bind
variable peeking, and the fact that the packaged application is either
not supplying bind variable values during the initial parse call, or
is specifying out of bounds values, Oracle is selecting to perform an
index range scan using an index on a column that contains only two
distinct values, when it should be using the index on the primary key
column to retrieve table data.  Oracle selects the correct index if
bind variable peeking is disabled.  I am trying to develop a logical
approach to determine which SQL statements need to have an outline
developed when bind variable peeking is disabled at the session
level.

Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

