Re: long running select min(timestamp) query
Date: Mon, 28 Jan 2008 09:49:08 -0800 (PST)
On Jan 28, 9:40 am, "bobdu..._at_gmail.com" <bobdu..._at_gmail.com> wrote:
> 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?
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:
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:
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