Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
comp.databases.oracle.server
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion long running select min(timestamp) query
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
fitzjarrell@cox.net  
View profile  
 More options Jan 28 2008, 12:49 pm
Newsgroups: comp.databases.oracle.server
From: "fitzjarr...@cox.net" <fitzjarr...@cox.net>
Date: Mon, 28 Jan 2008 09:49:08 -0800 (PST)
Local: Mon, Jan 28 2008 12:49 pm
Subject: Re: long running select min(timestamp) query
Print | View thread | Show original | Report this message | Find messages by this author
On Jan 28, 9:40 am, "bobdu...@gmail.com" <bobdu...@gmail.com> wrote:

> Hi,

> I have a basic event table in my 10g database, primary integer key,
> and a nonnull timestamp "eventdate" field.  When executing the
> following command:

> select min(eventdate) from events;

> It can occasionally take a VERY long time.  There is a standard btree
> index on "eventdate", and roughly 20 other columns, a few of which
> also have basic btree indexes.

> In my current scenario, the table has less than a million records, and
> the query seems to be taking upwards of 10 minutes!!!  Here's what the
> console says the plan is:

> Operation       Object  Object Type     Order   Rows    Size (KB)       Cost    Time (sec)      CPU
> Cost    I/O Cost
> SELECT STATEMENT                        3                               4
>  SORT AGGREGATE                         2       1       0.011
>   INDEX FULL SCAN (MIN/MAX) EVENTS_EVENTDATE    INDEX   1       736195  7,908.345
> 4       1       28686   4

> I've run the ADDM, it updated the stats, but that doesn't seem to help
> (i run it again it has no recommendations).  Am i doing something
> silly with this table or is there some better way for me to phrase
> this query?

> Thanks,
> Bob

Sorry to say, but '10g' doesn't say much about which release of Oracle
you're using, as that covers releases 10.1.0.2 through 10.2.0.3, and
the optimizer changed between those two base versions.

My suggestion is you configure the PLUSTRACE role, grant it to the
user in question then set autotrace on and run your query.  The query
plan itself won't tell you nearly as much as the resulting statistics
reported by autotrace.  As an example:

Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
        293  bytes sent via SQL*Net to client
        245  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          7  rows processed

SQL>

The db block gets, consistent gets and physical reads can reveal much
about what Oracle is doing with your query.  Another example shows
this:

Statistics
----------------------------------------------------------
          4  recursive calls
          0  db block gets
       7944  consistent gets
        239  physical reads
          0  redo size
     867354  bytes sent via SQL*Net to client
      53760  bytes received via SQL*Net from client
       7647  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
     114688  rows processed

SQL>

Such information can be of great help in diagnosing and tuning a
query.

Another excellent resource is 'Cost-Based Oracle Fundamentals', by
Jonathan Lewis ( a semi-regular poster to this newsgroup ).  I
strongly suggest you purchase a copy, read it and work through the
examples provided.  A wealth of information is packed inside those
pages.

With what you have supplied it's difficult to know where this query is
going awry.  Please post the autotrace output for a sluggish run of
this query so we can see what else Oracle may be doing that isn't
apparent from the bare query plan.

David Fitzjarrell


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google