I thought 'set autotrace on' was already correct? It was just 'explain plan for' that could be inaccurate? I'll check the trace tomorrow. I think you are right about the full table scan vs. the index scan. I did a unique scan and retrieved 1 record. The index is 1 block. So it should be two LIOs. One to read the index block and 1 to read the record in the table. Wierd that an 'order by' would coax oracle to do the right plan. The table fits inside one 1 MB extent. Any idea how to calculate how many expected LIOs for a full table scan? If I do: 1 MB / 8192 block size I get 125, which is just about double my 63 LIOs? ----- Original Message ----- From: "Wolfgang Breitling" <breitliw@xxxxxxxxxxxxx> To: <oracle-l@xxxxxxxxxxxxx> Sent: Thursday, August 12, 2004 9:51 PM Subject: Re: Really Wierd Query tuning issue > Can you post the tkprof output from your sql trace or the trace itself. > With bind variables you can not entirely trust the explain plan (even > without you can not always). Could it be possible that the optimizer > mistakenly chose a full scan for the query without the order by, which > ended up using 63 LIO rather than the much fewer the optimizer expected. > But with the order by, it DID use the index to save on the sort. ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------