Re: long running select min(timestamp) query

On Jan 28, 9:40 am, "bobdu..._at_gmail.com" <bobdu..._at_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 Received on Mon Jan 28 2008 - 11:49:08 CST