Tuning needed for sql:EXPLAIN PLAN attached

Question

DB Version:10gR2
The below sql was running slow, so i took an explain plan
SQL> explain plan for
  2  SELECT COUNT(1) FROM SHIP_DTL WHERE
  3  SHIP_DTL.PLT_ID = 'AM834'
  4  AND SHIP_DTL.WHSE = '34' AND
  5  SHIP_DTL.STAT_CODE != '845'
  6  ORDER BY SHIP_DTL.LOAD_SEQ ASC;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id  | Operation                    |  Name             | Rows  | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT             |                   |     1 |    18 |     5  (20)|
|   1 |  SORT AGGREGATE              |                   |     1 |    18 |            |
|*  2 |   TABLE ACCESS BY INDEX ROWID| SHIP_DTL        |   200 |  3600 |     5  (20)|
|*  3 |    INDEX RANGE SCAN          | SHIP_DTL_IND_4  |   203 |       |     3   (0)|
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   2 - filter("SHIP_DTL"."WHSE"='34' AND "SHIP_DTL"."STAT_CODE"<>845)
   3 - access("SHIP_DTL"."PLT_ID"='AM834')Why is there an INDEX RANGE scan where there is no BETWEEN operator in the query? What are various options(indexes, rewriting query) in tuning this query?

Answer 1

james_p wrote:
DB Version:10gR2
The below sql was running slow, so i took an explain planCheck your plan, the optimizer estimates that the following query:
select count(*)
from SHIP_DTL
where "SHIP_DTL"."PLT_ID"='AM834';only returns 200 records. Is this correct? Please post the result of above query.
It probably isn't the case, because retrieving 200 records per index range scan and single row random table access shouldn't take long, at maximum a couple of seconds if you need to read each block actually from disk rather than from the cache.
If the estimate is wrong you need to check the statistics on the table and index that were used by the optimizer to come to that conclusion.
Are you sure that this plan is the actual plan used at execution time? You can check for the actual plans used to execute by using the DBMS_XPLAN.DISPLAY_CURSOR function in 10g if the SQL is still cached in the Shared Pool. You need to pass the SQL_ID and SQL_CHILD_NUMBER which you can retrieve from V$SESSION while the statement is executing.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/