Query taking ages...seem simple enough

Question

10.2.0.3.0 Standard ed.
RHEL
1 table, short query with 1 predicate.
1 index : TRANSACTION_IX9 which is a functional index on the column with the function in the where clause. Index is used in the plan see below.
Table has 100+ million rows. stats on table and index up to date.
Takes hours to come back. Plan shows this.
SQL> explain plan for
  2  select
  3        x1.session_id
  4        x1.received_date
  5  from transaction_tb x1
where trunc(x1.received_date) < '01-OCT-11';  -- for some reason the date I put in here isnt coming out in the code display on the forum, probably single quotes, anyway its just 01-oct-2011
  6
Explained.
set linesize 132
set pagesize 999
SQL> SQL>  SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY);
PLAN_TABLE_OUTPUT
Plan hash value: 2633564245
| Id  | Operation                   | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |                            |    17M|  1572M|  1599K  (1)| 05:19:51 |
|   1 |  TABLE ACCESS BY INDEX ROWID| TRANSACTION_TB  |    17M|  1572M|  1599K  (1)| 05:19:51 |
|*  2 |   INDEX RANGE SCAN          | TRANSACTION_IX9 |    17M|       | 48162   (1)| 00:09:38 |
Predicate Information (identified by operation id):
   2 - access(TRUNC(INTERNAL_FUNCTION("RECEIVED_DATE"))<'01-OCT-11')
14 rows selected.
SQL>Yes I know there are millions of rows returned which is probably (defintely!!) not helping the query, but playing with rows returned via the date range if I shorten the time span to reduce to say 20k rows returned, Im still looking at 15 minues to get them out with the index range scan in the plan staying the same. This shouldnt be to my mind. Any thoughts?
Edited by: deebee_eh on 26-Mar-2012 15:47

Answer 1

deebee_eh wrote:
10.2.0.3.0 Standard ed.
RHEL
SQL> explain plan for
2  select
3        x1.session_id
4        x1.received_date
5  from transaction_tb x1
where trunc(x1.received_date) < '01-OCT-11';  -- for some reason the date I put in here isnt coming out in the code display on the forum, probably single quotes, anyway its just 01-oct-2011
Before going to much further, you need to check that the actual execution plan matches the predicted plan.
set serveroutput off
select .... -- your query
select * from table(dbms_xplan.display_cursor);
{code]
You may find that Oracle handles the run-time situation differently.  (The appearance of the internal_function() suggests this as a possibility).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author:  <b><em><a href="http://www.apress.com/9781430239543">Oracle Core</a></em></b>