Query not using indexes

select *
          from hrm_career x
          WHERE x.begin_date = ( SELECT MAX(begin_date)
                         FROM hrm_career y
                         WHERE y.employee_id = x.employee_id AND
                              begin_date <= SYSDATE AND
                              primary_job = 'Y') AND
               x.primary_job = 'Y'
I have the above query which is not using the index created on the BEGIN_DT column
I tried to force using still not using
but when i apply a value say
select *
          from hrm_career x
          WHERE x.begin_date ='10-20-2007'
It is using index and resulting in very fast response
Can some throw some ideas on it...
Where should i look into here ..

SQL> set autotrace traceonly
SQL> select *
2 from hrm_career x
3 WHERE x.begin_date = ( SELECT MAX(begin_date)
4 FROM hrm_career y
5 WHERE y.employee_id = x.employee_id AND
6 begin_date <= SYSDATE AND
7 primary_job = 'Y') AND
8 x.primary_job = 'Y';
13454 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1417 Card=152 Bytes=
35568)
1 0 FILTER
2 1 SORT (GROUP BY) (Cost=1417 Card=152 Bytes=35568)
3 2 HASH JOIN (Cost=254 Card=47127 Bytes=11027718)
4 3 INDEX (FAST FULL SCAN) OF 'HRM_CAREER_PK' (UNIQUE) (
Cost=12 Card=25026 Bytes=500520)
5 3 TABLE ACCESS (FULL) OF 'HRM_CAREER' (Cost=81 Card=25
335 Bytes=5421690)
Statistics
3671 recursive calls
9 db block gets
1758 consistent gets
2130 physical reads
0 redo size
2217762 bytes sent via SQL*Net to client
10359 bytes received via SQL*Net from client
898 SQL*Net roundtrips to/from client
128 sorts (memory)
1 sorts (disk)
13454 rows processed
TKPROF
TKPROF: Release 9.2.0.6.0 - Production on Wed Dec 12 18:40:56 2007
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: qnhg_ora_500.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 34.45 34.45
select condition
from
cdef$ where rowid=:1
call count cpu elapsed disk query current rows
Parse 4 0.00 0.00 0 0 0 0
Execute 4 0.00 0.00 0 0 0 0
Fetch 4 0.00 0.00 0 8 0 4
total 12 0.00 0.00 0 8 0 4
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
Rows Row Source Operation
1 TABLE ACCESS BY USER ROWID CDEF$
select *
from hrm_career x
WHERE x.begin_date = ( SELECT MAX(begin_date)
FROM hrm_career y
WHERE y.employee_id = x.employee_id AND
begin_date <= SYSDATE AND
primary_job = 'Y') AND
x.primary_job = 'Y'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.07 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 898 0.00 2.39 2038 946 9 13454
total 900 0.00 2.46 2038 946 9 13454
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
13454 FILTER
25335 SORT GROUP BY
67496 HASH JOIN
25333 INDEX FAST FULL SCAN HRM_CAREER_PK (object id 25292)
25336 TABLE ACCESS FULL HRM_CAREER
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
13454 FILTER
25335 SORT (GROUP BY)
67496 HASH JOIN
25333 INDEX GOAL: ANALYZED (FAST FULL SCAN) OF 'HRM_CAREER_PK'
(UNIQUE)
25336 TABLE ACCESS GOAL: ANALYZED (FULL) OF 'HRM_CAREER'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 898 0.00 0.00
SQL*Net more data to client 877 0.00 0.05
db file sequential read 1 0.01 0.01
db file scattered read 60 0.00 0.14
direct path write 9 0.00 0.00
direct path read 125 0.05 0.13
SQL*Net message from client 898 0.02 1.47
DELETE FROM PLAN_TABLE
WHERE
STATEMENT_ID=:1
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 6 6 6
Fetch 0 0.00 0.00 0 0 0 0
total 4 0.00 0.00 0 6 6 6
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
0 DELETE
0 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 DELETE STATEMENT GOAL: CHOOSE
0 DELETE OF 'PLAN_TABLE'
0 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 14.77 14.79
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,
o.dataobj#,o.flags
from
obj$ o where o.obj#=:1
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3 0 1
total 3 0.00 0.00 0 3 0 1
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: SYS (recursive depth: 1)
EXPLAIN PLAN SET STATEMENT_ID='PLUS74964' FOR select *
from hrm_career x
WHERE x.begin_date = ( SELECT MAX(begin_date)
FROM hrm_career y
WHERE y.employee_id = x.employee_id AND
begin_date <= SYSDATE AND
primary_job = 'Y') AND
x.primary_job = 'Y'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.01 0 4 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.01 0 4 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
SQL*Net message from client 1 0.00 0.00
insert into plan_table (statement_id, timestamp, operation, options,
object_node, object_owner, object_name, object_instance, object_type,
search_columns, id, parent_id, position, other,optimizer, cost, cardinality,
bytes, other_tag, partition_start, partition_stop, partition_id,
distribution, cpu_cost, io_cost, temp_space, access_predicates,
filter_predicates )
values
(:1,SYSDATE,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15,:16,:17,:18,:19,
:20,:21,:22,:23,:24,:25,:26,:27)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 6 0.00 0.00 0 3 6 6
Fetch 0 0.00 0.00 0 0 0 0
total 7 0.00 0.00 0 3 6 6
Misses in library cache during parse: 1
Misses in library cache during execute: 2
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN) (recursive depth: 1)
Rows Execution Plan
0 INSERT STATEMENT GOAL: CHOOSE
select o.name, u.name
from
sys.obj$ o, sys.user$ u where obj# = :1 and owner# = user#
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Parsing user id: SYS (recursive depth: 1)
SELECT ID ID_PLUS_EXP,PARENT_ID PARENT_ID_PLUS_EXP,LPAD(' ',2*(LEVEL-1))
||OPERATION||DECODE(OTHER_TAG,NULL,'','*')||DECODE(OPTIONS,NULL,'','
('||OPTIONS||')')||DECODE(OBJECT_NAME,NULL,'',' OF '''||OBJECT_NAME||'''')
||DECODE(OBJECT_TYPE,NULL,'',' ('||OBJECT_TYPE||')')||DECODE(ID,0,
DECODE(OPTIMIZER,NULL,'',' Optimizer='||OPTIMIZER))||DECODE(COST,NULL,'','
(Cost='||COST||DECODE(CARDINALITY,NULL,'',' Card='||CARDINALITY)
||DECODE(BYTES,NULL,'',' Bytes='||BYTES)||')') PLAN_PLUS_EXP,OBJECT_NODE
OBJECT_NODE_PLUS_EXP
FROM
PLAN_TABLE START WITH ID=0 AND STATEMENT_ID=:1 CONNECT BY PRIOR ID=PARENT_ID
AND STATEMENT_ID=:1 ORDER BY ID,POSITION
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 0 22 0 6
total 4 0.00 0.00 0 22 0 6
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
6 SORT ORDER BY
6 CONNECT BY WITH FILTERING
1 NESTED LOOPS
1 TABLE ACCESS FULL PLAN_TABLE
1 TABLE ACCESS BY USER ROWID PLAN_TABLE
5 NESTED LOOPS
6 BUFFER SORT
6 CONNECT BY PUMP
5 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
6 SORT (ORDER BY)
6 CONNECT BY (WITH FILTERING)
1 NESTED LOOPS
1 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
1 TABLE ACCESS (BY USER ROWID) OF 'PLAN_TABLE'
5 NESTED LOOPS
6 BUFFER (SORT)
6 CONNECT BY PUMP
5 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.09 0.09
SELECT ID ID_PLUS_EXP,OTHER_TAG OTHER_TAG_PLUS_EXP,OTHER OTHER_PLUS_EXP
FROM
PLAN_TABLE WHERE STATEMENT_ID=:1 AND OTHER_TAG IS NOT NULL ORDER BY ID
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 3 0 0
total 3 0.00 0.00 0 3 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
Rows Row Source Operation
0 SORT ORDER BY
0 TABLE ACCESS FULL PLAN_TABLE
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
0 SORT (ORDER BY)
0 TABLE ACCESS (FULL) OF 'PLAN_TABLE'
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 2 0.00 0.00
SQL*Net message from client 2 0.00 0.00
ALTER SESSION SET EVENTS '10046 trace name context off'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 30 (ADMIN)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 7 0.00 0.09 0 4 0 0
Execute 8 0.00 0.00 0 6 6 6
Fetch 901 0.00 2.39 2038 971 9 13460
total 916 0.00 2.49 2038 981 15 13466
Misses in library cache during parse: 6
Misses in library cache during execute: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 906 0.00 0.00
SQL*Net message from client 906 34.45 50.82
SQL*Net more data to client 877 0.00 0.05
db file sequential read 1 0.01 0.01
db file scattered read 60 0.00 0.14
direct path write 9 0.00 0.00
direct path read 125 0.05 0.13
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 7 0.00 0.00 0 0 0 0
Execute 11 0.00 0.00 0 3 6 6
Fetch 5 0.00 0.00 0 11 0 5
total 23 0.00 0.00 0 14 6 11
Misses in library cache during parse: 4
Misses in library cache during execute: 2
9 user SQL statements in session.
6 internal SQL statements in session.
15 SQL statements in session.
5 statements EXPLAINed in this session.
Trace file: qnhg_ora_500.trc
Trace file compatibility: 9.02.00
Sort options: default
3 sessions in tracefile.
12 user SQL statements in trace file.
8 internal SQL statements in trace file.
15 SQL statements in trace file.
11 unique SQL statements in trace file.
5 SQL statements EXPLAINed using schema:
ADMIN.prof$plan_table
Default table was used.
Table was created.
Table was dropped.
3945 lines in trace file.
Message was edited by:
Maran Viswarayar

Similar Messages

  • Due to Upper() query not using Indexes.......

    Hi,
    I have query as under:
    SELECT max(A.REGION_ID)
      FROM SOP_REGION_COUNTRY_MAP  A,
           SOP_REGION_PRODLINE_MAP B,
           SOP_REGION_ACTIVITY_MAP C
    WHERE A.REGION_ID = B.REGION_ID
       AND A.REGION_ID = C.REGION_ID
       AND upper(trim(COUNTRY_NAME)) = upper(trim(:Var3))
       AND upper(trim(STATE_NAME)) = upper(trim(:Var2))
       AND upper(trim(PRODLINE_NAME)) = upper(trim(:Var1))
       AND A.BATCH_JOB_IND = 1
       AND B.BATCH_JOB_IND = 1The plan of the above query is as under:
         SELECT STATEMENT, GOAL = CHOOSE                                   Cost=7     Cardinality=1     Bytes=73
    SORT AGGREGATE                                                       Cardinality=1     Bytes=73
      NESTED LOOPS                                                  Cost=7     Cardinality=1     Bytes=73
       HASH JOIN                                                  Cost=6     Cardinality=1     Bytes=68
        TABLE ACCESS FULL     Object owner=SOP     Object name=SOP_REGION_COUNTRY_MAP     Cost=3     Cardinality=1     Bytes=25
        TABLE ACCESS FULL     Object owner=SOP     Object name=SOP_REGION_PRODLINE_MAP     Cost=3     Cardinality=1     Bytes=43
       INDEX RANGE SCAN     Object owner=SOP     Object name=FK1_SOP_REGION_ACTIVITY_MAP     Cost=2     Cardinality=48     Bytes=240Now, this query does full table access of sop_region_country_map and sop_region_prodline_map even though it has index on country_name,state_name and prodline_name columns but as i have used Upper function the index is not used. Now, I need this upper function as business req. states that none of the comparison should be missed jsut because user has entered country,state and prodline in mixed cases...
    Can you pls let me know what to do if i want to avoid this FTA and instaed use indexes.. without sacrificing Upper() functionlaity..?
    Thx

    okay...its something like query rewrite grant for user...
    when i give that...i can create functional index now..
    but still i can use trunc() for functional index...it tells me that functional index can be created only for pure function...what is pure and impure function in oracle.

  • Query not using index when using 'or' clause

    I have a problem with something I can't understand about indexes in Oracle 11g.
    We can create test data with:
    create table test2(field1 varchar2(100),field2 varchar2(100),field3 number,field4 varchar2(100));
    create index test2_idx1 on test2(upper(field1));
    create index test2_idx1b on test2(field1);
    create index test2_idx2 on test2(field3);
    DECLARE
    j NUMBER :=1;
    BEGIN
    FOR i IN 1..500000
    LOOP
    INSERT
    INTO test2
    (field1,field2, field3, field4)
    VALUES
    ('field1='||i,'a', j, 'i' );
    IF (i mod 1000)=0 THEN
    j := j+1;
    END IF;
    END LOOP;
    COMMIT;
    END;
    EXEC DBMS_STATS.GATHER_TABLE_STATS ('system', 'test2');
    Then I make some explain plans which result I can't understand
    Query 1:
    SELECT * FROM test2 WHERE field3=1;
    Explain plan:
    Explain plan for query 01
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1003 | 28084 | 10 (0)| 00:00:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
    |* 2 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
    Everything OK here. Index is used.
    Query 2:
    SELECT * FROM test2 WHERE upper(field1)='FIELD1=1';
    Explain plan
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1 | 28 | 4 (0)| 00:00:01 |
    | 1 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1 | 28 | 4 (0)| 00:00:01 |
    |* 2 | INDEX RANGE SCAN | TEST2_IDX1 | 1 | | 3 (0)| 00:00:01 |
    Everything OK again. Index is used.
    Query 3:
    SELECT /*+ USE_CONCAT */ * FROM test2 WHERE field1='FIELD1=1' OR field3=1;
    Explain plan
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1004 | 28112 | 14 (0)| 00:00:01 |
    | 1 | CONCATENATION | | | | | |
    | 2 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1 | 28 | 4 (0)| 00:00:01 |
    |* 3 | INDEX RANGE SCAN | TEST2_IDX1B | 1 | | 3 (0)| 00:00:01 |
    |* 4 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
    |* 5 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
    Indenxes are used in concatenation. No problem again.
    Query 4:
    SELECT /*+ USE_CONCAT */ * FROM test2 WHERE upper(field1)='FIELD1=1' OR field3=1;
    Explain plan
    | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
    | 0 | SELECT STATEMENT | | 1004 | 28112 | 641 (4)| 00:00:08 |
    | 1 | CONCATENATION | | | | | |
    |* 2 | TABLE ACCESS FULL | TEST2 | 1 | 28 | 631 (4)| 00:00:08 |
    |* 3 | TABLE ACCESS BY INDEX ROWID| TEST2 | 1003 | 28084 | 10 (0)| 00:00:01 |
    |* 4 | INDEX RANGE SCAN | TEST2_IDX2 | 1003 | | 5 (0)| 00:00:01 |
    Here my problem arises. Why is test2_idx1 not being used? Is it because it is a function index? Is there any workaround in this cases?
    Thanks a lot in advance.

    Interesting. A "workaround" which I thought first was:
    SELECT /*+ USE_CONCAT */ * FROM test2 WHERE upper(field1)='FIELD1=1'
    UNION ALL
    SELECT /*+ USE_CONCAT */ * FROM test2 WHERE field3=1;
    | Id  | Operation                    | Name       | Rows  | Bytes | Cost (%CPU)| Time     |                                                                                                                                                                                                                 
    |   0 | SELECT STATEMENT             |            |  1001 | 28042 |    15  (74)| 00:00:01 |                                                                                                                                                                                                                 
    |   1 |  UNION-ALL                   |            |       |       |            |          |                                                                                                                                                                                                                 
    |   2 |   TABLE ACCESS BY INDEX ROWID| TEST2      |     1 |    42 |     4   (0)| 00:00:01 |                                                                                                                                                                                                                 
    |*  3 |    INDEX RANGE SCAN          | TEST2_IDX1 |     1 |       |     3   (0)| 00:00:01 |                                                                                                                                                                                                                 
    |   4 |   TABLE ACCESS BY INDEX ROWID| TEST2      |  1000 | 28000 |    11   (0)| 00:00:01 |                                                                                                                                                                                                                 
    |*  5 |    INDEX RANGE SCAN          | TEST2_IDX2 |  1000 |       |     5   (0)| 00:00:01 |                                                                                                                                                                                                                 
    -------------------------------------------------------------------------------------------   But I do not like using UNION for such tricks. So I thought, what would ORACLE do without hint?
    SELECT  * FROM test2 WHERE upper(field1)='FIELD1=1' or field3=1;
    | Id  | Operation                        | Name       | Rows  | Bytes | Cost (%CPU)| Time     |                                                                                                                                                                                                             
    |   0 | SELECT STATEMENT                 |            |  1001 | 42042 |   176   (0)| 00:00:03 |                                                                                                                                                                                                             
    |   1 |  TABLE ACCESS BY INDEX ROWID     | TEST2      |  1001 | 42042 |   176   (0)| 00:00:03 |                                                                                                                                                                                                             
    |   2 |   BITMAP CONVERSION TO ROWIDS    |            |       |       |            |          |                                                                                                                                                                                                             
    |   3 |    BITMAP OR                     |            |       |       |            |          |                                                                                                                                                                                                             
    |   4 |     BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |                                                                                                                                                                                                             
    |*  5 |      INDEX RANGE SCAN            | TEST2_IDX2 |       |       |     5   (0)| 00:00:01 |                                                                                                                                                                                                             
    |   6 |     BITMAP CONVERSION FROM ROWIDS|            |       |       |            |          |                                                                                                                                                                                                             
    |*  7 |      INDEX RANGE SCAN            | TEST2_IDX1 |       |       |     3   (0)| 00:00:01 |                                                                                                                                                                                                             
    ----------------------------------------------------------------------------------------------- Thist looks perfect to me. (Please ignore the "higher" cost on the second plan. On your real data, it should be faster. Is it?)

  • Query not using index after delete?

    In 10 million table, i have purge a 5 millions and done table re-org, rebuilt of index and gather stats 100% including indexes.
    Query which is doing index scans eariler, now after purge explain plan has changed and its performing full table scan. Any idea, why behaviour has changed?
    its vendor based code can't change the query, any way to get back to index scan?

    Paulie wrote:
    Jonathan Lewis wrote:
    >
    I'm sure that Jonathan Lewis would not phrase it exactly like that, but in a nutshell, that's probably your answer.
    I certainly wouldn't phrase it like thatOf course not - I was merely poking fun at my rather simplistic and colloquial explanation - I certainly meant no
    offence.
    None taken (although perhaps I didn't make that clear enough -- I took your comment as tongue in cheek, anyway)
    >
    - and there definitely ISN'T a rule of thumb regarding proportion of data - Is it a common myth? I'm pretty sure that I have read about this "rule of thumb" to which I referred? I'll certainly
    take that on board in future.
    It is a very common myth - and one which various people have tried to dispel for years; unfortunately it gets resurrected fairly regularly by people who don't know any better. Critically, the choice of index is dictated by a combination of two factors, and mentioning one without the other is very misleading - the quantity of the data acquired and the scattering of the data. On top of that you have to remember that there are two "models" to consider - Oracle's estimate of quantity and scatter, and the actual quantity and scatter.
    >
    but the picture you're trying to invoke is probably the correct concept. We can safely assume that the
    re-organisation of the table has made it cheaper to use a brute-force method on the table (i.e. tablescan),
    and we can assume that he hasn't done anything to reduce the cost of the indexed access path in a
    similar way (and he may even have made it more expensive.) Well, that's a relief - I at least appear to be grasping the rudiments of the topic, in no small measure thanks
    to your chef d'oeuvre, Cost Based Oracle.
    Thanks
    Jonathan Lewis

  • Why is this query not using the index?

    check out this query:-
    SELECT CUST_PO_NUMBER, HEADER_ID, ORDER_TYPE, PO_DATE
    FROM TABLE1
    WHERE STATUS = 'N'
    and here's the explain plan:-
    1     
    2     -------------------------------------------------------------------------------------
    3     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
    4     -------------------------------------------------------------------------------------
    5     | 0 | SELECT STATEMENT | | 2735K| 140M| 81036 (2)|
    6     |* 1 | TABLE ACCESS FULL| TABLE1 | 2735K| 140M| 81036 (2)|
    7     -------------------------------------------------------------------------------------
    8     
    9     Predicate Information (identified by operation id):
    10     ---------------------------------------------------
    11     
    12     1 - filter("STATUS"='N')
    There is already an index on this column, as is shown below:-
         INDEX_NAME INDEX_TYPE     UNIQUENESS     TABLE_NAME     COLUMN_NAME     COLUMN_POSITION
    1     TABLE1_IDX2 NORMAL     NONUNIQUE     TABLE1      STATUS     1
    2     TABLE1_IDX NORMAL     NONUNIQUE     TABLE1     HEADER_ID     1
    So why is this query not using the index on the 'STATUS' Column?
    I've already tried using optimizer hints and regathering the stats on the table, but the execution plan still remains the same, i.e. it still uses a FTS.
    I have tried this command also:-
    exec dbms_stats.gather_table_stats('GECS','GEPS_CS_SALES_ORDER_HEADER',method_opt=>'for all indexed columns size auto',cascade=>true,degree=>4);
    inspite of this, the query is still using a full table scan.
    The table has around 55 Lakh records, across 60 columns. And because of the FTS, the query is taking a long time to execute. How do i make it use the index?
    Please help.
    Edited by: user10047779 on Mar 16, 2010 6:55 AM

    If the cardinality is really as skewed as that, you may want to look at putting a histogram on the column (sounds like it would be in order, and that you don't have one).
    create table skewed_a_lot
    as
       select
          case when mod(level, 1000) = 0 then 'N' else 'Y' end as Flag,
          level as col1
       from dual connect by level <= 1000000;
    create index skewed_a_lot_i01 on skewed_a_lot (flag);
    exec dbms_stats.gather_table_stats(user, 'SKEWED_A_LOT', cascade => true, method_opt => 'for all indexed columns size auto');Is an example.

  • Query can not use index

    1,i found a sql :select userid,repute from user_attribute where
    repute>3000 order by repute desc
    cost heavily;
    SELECT STATEMENT Cost = 637
    SORT ORDER BY
    TABLE ACCESS FULL USER_ATTRIBUTE
    2,i use: select index_name from user_indexes where table_name
    = 'USER_ATTRIBUTE'
    INDEX_NAME
    IDX_USER_ATTRIBUTE_FACE
    IDX_USER_ATTRIBUTE_POWER
    IDX_USER_ATTRIBUTE_REPUTE
    IDX_USER_ATTRIBUTE_USERID
    so column repute has indexed
    3, i use CBO with analysize shema compute
    optimizer_index_caching integer 99
    optimizer_index_cost_adj integer 5
    4,i use: select /*index(IDX_USER_ATTRIBUTE_REPUTE)*/
    userid,repute from user_attribute where repute>3000 order by
    repute desc
    i got same explain plan as old
    5,why it can not use index to query,thanks.

    I think your optimizer hint syntax is wrong. you need a "+"
    sign to indicate that the comment block is an optimizer hint,
    and the table name is not optional in the index hints
    select /*+ index(user_attribute
    IDX_USER_ATTRIBUTE_REPUTE)*/
    userid,repute from user_attribute where repute>3000 order
    by
    repute desc
    also, try ...
    select /*+ index_desc(user_attribute
    IDX_USER_ATTRIBUTE_REPUTE)*/
    userid,repute from user_attribute where repute>3000
    This should order the result for you.

  • Queries not using indexes

    We installed and configured a new environment of OBIEE and are trying to run a simple query in our data warehouse. This simple query takes only 7 seconds to complete in our previous data warehouse using TOAD but is taking 8+ minutes to complete in our new environment also using TOAD.
    Looking at the explain plans, the query in the new environment is not using indexes. Does anyone have an idea why it is not using the indexes? We checked and all of the indexes have been created and still exist. We also ran Analyze again on the two tables used n the query but the query still did not use the indexes.
    Please let me know if anyone has ideas ASAP since we are baffled.

    - Are the object statistics identical? The ANALYZE statement has been depricated for a while, particularly for data warehouse environments where there may be partitioning. Were you not using the DBMS_STATS package to gather statistics in the previous environment? Were statistics computed on the indexes?
    - Can you post the two query plans (formatted via DBMS_XPLAN and including the filter conditions)? It is not immediately obvious to me what index(es) might be useful here unless one of the two conditions is particularly selective which doesn't seem terribly likely based on just the table names involved.
    - When you do post the query plans, please use the \[code\] and \[code\] tags to preserve the white space so that the output is readable.
    Justin

  • Not Using Index on File Server When Accessing User Files Directly on Server

    It appears to me that on a server with an indexed network share (Desktop Experience and Search Indexing roles/features installed), if you access the share directly on the server using its drive path, you can search the folders using the index, which
    is much faster and supports finding words inside of the files in seconds). However, if you access the same shared folder via its network path from the server itself, the server ignores the index. I have this experience/problem across all shared folders on
    the Windows 2012 R2 Server. Details and my most specific goal follows.
    In addition to a laptop, I frequently work directly on a Windows Server 2012 R2 computer. We have Redirected Folders set up on DFS (for failover redundancy) so that my Documents folder is in:
    \\network\redirections\user\documents. This all works fine on Windows 7 and 8 client computers connected to the network via Offline Files.
    The problem is on the server itself. The server has Desktop Experience enabled and Windows Search is installed. If I navigate manually through the DFS root folder to my documents folder, I can search and it properly uses the index. This proves the location
    is properly indexed. However, if I access the folders through the official "Documents" folder from the Folder Redirection (a network share pointing to the same server computer I'm working on), it performs an un-indexed search (slow and ignores file
    contents, but does find files eventually if the search term is in their filename). Is there a way to force the server to use the indexed search on the Redirected Folders (my Documents folder in particular) when working on that server when logged in locally
    on that server?
    I suspect a workaround would be to go into the Registry and manually change the HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders to point to the local DFS folder instead of the network share name, but at least one problem
    with this is then if I save files with links to other files (e.g., a linked Excel table in a PowerPoint, a mail merge to Access database in Word, etc.) on the server computer, those links will point to d:\DFSroot\... (a physical drive on the computer) instead
    of \\network\redirections\user\... (a universally accessible network path) and so none of the other computers will be able to find the linked files, defeating one of the
    major benefits of using Redirected Folders.
    I can't believe that I need to choose between indexed searching and proper path names in saved files. Surely there is a way to use an indexed search on the server itself?
    If you need any more info to help me troubleshoot, please let me know.
    Thanks for any help,
    Colin

    Hi Colin,
    It seems that we can not use indexed search on DFS shares. Windows Search works well when users directly access the server. That is, the server is not made available through Distributed File System (DFS).
    For more detailed information, you could refer to the links below:
    Windows Search Service, Clustered File Services, DFS, Win7 Libraries
    https://social.technet.microsoft.com/Forums/windowsserver/en-US/31ac4c16-948b-4ca4-b18f-3a339cdfd5b9/windows-search-service-clustered-file-services-dfs-win7-libraries?forum=winserverfiles
    Windows Browse and Organize Features
    https://technet.microsoft.com/en-us/library/dd744693(WS.10).aspx
    Best Regards,
    Mandy 
    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact [email protected]

  • Querys not using indexes

    hi all.
    I want to know wich querys in not using indexes. this is posible??
    My db version is 10.2
    Thanks.

    gomcar wrote:
    hi all.
    I want to know wich querys in not using indexes. this is posible??
    My db version is 10.2
    Thanks.Here is something that I just put together as a possible solution. You probably do not want to execute this SQL statement frequently as it might cause a latching problem (note, not thoroughly tested):
    SELECT /*+ ORDERED */
      SP.SQL_ID,
      SP.HASH_VALUE,
      SP.CHILD_NUMBER,
      S.SQL_TEXT
    FROM
      (SELECT
        SP.SQL_ID,
        SP.HASH_VALUE,
        SP.CHILD_NUMBER,
        SUM(DECODE(INSTR(SP.OBJECT_TYPE,'INDEX'),0,0,1)) COUNTER
      FROM
        V$SQL_PLAN_STATISTICS_ALL SP
      WHERE
        SP.OBJECT_TYPE IS NOT NULL
      GROUP BY
        SP.SQL_ID,
        SP.HASH_VALUE,
        SP.CHILD_NUMBER
      HAVING
        SUM(DECODE(INSTR(SP.OBJECT_TYPE,'INDEX'),0,0,1))=0) SP,
      V$SQL S
    WHERE
      SP.SQL_ID=S.SQL_ID
      AND SP.HASH_VALUE=S.HASH_VALUE
      AND SP.CHILD_NUMBER=S.CHILD_NUMBER
    ORDER BY
      S.SQL_TEXT;Explanation of the above:
    The above looks at the stored execution plans for the queries currently in the shared pool, throwing out any line in the plan where no object is specified. If the OBJECT_TYPE column is found to not contain the word INDEX, a 0 is returned, otherwise a 1 is returned for that line in the plan. The sum of this generated column is calculated for each plan, and those plans having the sum of the generated column equal to 0 are returned. This inline view then drives into the V$SQL view to retrieve the matching SQL statements. An ordered hint is used to make certain that Oracle drives from the inline view into V$SQL.
    Charles Hooper
    IT Manager/Oracle DBA
    K&M Machine-Fabricating, Inc.

  • Not using Index when SDO_RELATE in Spatial Query is used in LEFT OUTER JOIN

    I want to know for every City (Point geometry) in which Municipality (Polygon geometry) it is.
    Some cities will not be covered by any municipality (as there is no data for it), so its municipality name should be blank in the result
    We have 4942 cities (point geometries)
    and 500 municipalities (polygon geometry)
    SELECT T1.NAME as City, T2.NAME as Municipality
    FROM CITY T1
    LEFT OUTER JOIN MUNICIPALITY T2 ON SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'The explain plan for this query is:
    SELECT STATEMENT
      FILTER
        Filter Predicates
          MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'
        MERGE JOIN
          TABLE ACCESS              CITY               FULL                            11
          BUFFER                                       SORT                        100605
              TABLE ACCESS          MUNICIPALITY       FULL                            20So the cost is in the BUFFER (whatever that is), it takes +2000 seconds to run this, it is not using the spatial index.
    And we are not getting all rows, but only the ones interacting with a municipality, e.g. 2436 rows.
    But I want all rows, including the ones not interacting with any Municipality.
    When we want only those cities that actually are in a municipality, I use a different query and it will use the index.
    SELECT T1.NAME as City, T2.NAME as Municipality
    FROM CITY T1, MUNICIPALITY T2
    WHERE SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'I get (only) 2436 rows (as expected) in 5 seconds (it is fast) and the explain plan shows it is using the spatial index.
    But in this case, I am not getting any cities not inside any municipality (of course)
    SELECT STATEMENT
       NESTED LOOPS
          TABLE ACCESS                   MUNICIPALITY       FULL                22
          TABLE ACCESS                   CITY               BY INDEX ROWID      22
             DOMAIN INDEX                CITY_SDX                                0
                Access Predicates
                   MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'I always thought a LEFT OUTER JOIN would return all rows from the Table, whatever happens in the next,
    but it seems the query has been rewritten so that it is now using a Filter Predicate in the end, which filters those geometries having no interaction.
    As an example I also do thing alphanumerically, I do get 4942 rows, including the ones which have no Municipality name.
    In this case the names must match, so its only for testing if the LEFT OUTER JOIN returns stuff correctly, which it does in this case.
    SELECT T1.NAME as City, T2.NAME as Municipality
    FROM CITY T1
    LEFT OUTER JOIN MUNICIPALITY T2 ON T1.NAME = T2.NAMEIs this an Oracle Spatial bug, e.g. not return 4942 rows, but only 2436 rows on the first query?
    Note all tests performed on Oracle 11g R2 (11.2.0.1.0)

    Patrick,
    Even so, your geoms in the relate were the wrong way around.
    Also, I don't recall you saying (or showing) that you wanted the municipality geometry returned. Still,
    no matter, easy to do.
    Here are some additional suggestions. I don't have your data so I have had to use some of my own.
    set serveroutput on timing on autotrace on
    SELECT T1.SPECIES as City,
           (SELECT T2.ADMIN_NAME FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as Municipality,
           (SELECT T2.GEOM       FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as geom
      FROM GUTDATA T1;
    762 rows selected
    Elapsed: 00:00:21.656
    Plan hash value: 2160035213
    | Id  | Operation                   | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |                            |   762 | 49530 |     5   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES          |     1 |   115 |     0   (0)| 00:00:01 |
    |*  2 |   DOMAIN INDEX              | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
    |   3 |  TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES          |     1 |   115 |     0   (0)| 00:00:01 |
    |*  4 |   DOMAIN INDEX              | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
    |   5 |  TABLE ACCESS FULL          | GUTDATA                    |   762 | 49530 |     5   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
       4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
       Statistics
                   7  user calls
               24576  physical read total bytes
                   0  physical write total bytes
                   0  spare statistic 3
                   0  commit cleanout failures: cannot pin
                   0  TBS Extension: bytes extended
                   0  total number of times SMON posted
                   0  SMON posted for undo segment recovery
                   0  SMON posted for dropping temp segment
                   0  segment prealloc tasksThe above can look messy as you add more (SELECT ...) attributes, but is is fast (though can't use in Materialized Views).
    /* The set of all cities not in municipalities */
    SELECT T1.SPECIES                 as City,
           cast(null as varchar2(42)) as municipality,
           cast(null as sdo_geometry) as geom
      FROM GUTDATA T1
    WHERE NOT EXISTS (SELECT 1
                         FROM AUSTRALIAN_STATES T2
                        WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
    UNION ALL
    /* The set of all cities in municipalities */
    SELECT T1.SPECIES    as City,
           T2.ADMIN_NAME as Municipality,
           T2.GEOM       as geom
      FROM GUTDATA T1
           INNER JOIN
           AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
    762 rows selected
    Elapsed: 00:00:59.953
    Plan hash value: 2854682795
    | Id  | Operation           | Name                       | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT    |                            |    99 | 13450 |    38  (87)| 00:00:01 |
    |   1 |  UNION-ALL          |                            |       |       |            |          |
    |*  2 |   FILTER            |                            |       |       |            |          |
    |   3 |    TABLE ACCESS FULL| GUTDATA                    |   762 | 49530 |     5   (0)| 00:00:01 |
    |*  4 |    DOMAIN INDEX     | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
    |   5 |   NESTED LOOPS      |                            |    61 | 10980 |    33   (0)| 00:00:01 |
    |   6 |    TABLE ACCESS FULL| AUSTRALIAN_STATES          |     8 |   920 |     3   (0)| 00:00:01 |
    |*  7 |    TABLE ACCESS FULL| GUTDATA                    |     8 |   520 |     4   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       2 - filter( NOT EXISTS (SELECT 0 FROM "AUSTRALIAN_STATES" "T2" WHERE "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE'))
       4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
       7 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
       Statistics
                   7  user calls
              131072  physical read total bytes
                   0  physical write total bytes
                   0  spare statistic 3
                   0  commit cleanout failures: cannot pin
                   0  TBS Extension: bytes extended
                   0  total number of times SMON posted
                   0  SMON posted for undo segment recovery
                   0  SMON posted for dropping temp segment
                   0  segment prealloc tasksMuch slower but Materialized View friendly.
    This one is a bit more "natural" but still slower than the first.
    set serveroutput on timing on autotrace on
    /* The set of all cities in municipalities */
    WITH municipal_cities As (
      SELECT T1.ID         as City,
             T2.ADMIN_NAME as Municipality,
             T2.GEOM       as geom
        FROM GUTDATA T1
             INNER JOIN
             AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
    SELECT T1.ID           as City,
           T2.Municipality as Municipality,
           T2.GEOM         as geom
      FROM GUTDATA          T1
           LEFT OUTER JOIN
           municipal_cities T2
           ON (T2.CITY = T1.ID);
    762 rows selected
    Elapsed: 00:00:50.228
    Plan hash value: 745978991
    | Id  | Operation             | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT      |                   |   762 | 44196 |    36   (3)| 00:00:01 |
    |*  1 |  HASH JOIN RIGHT OUTER|                   |   762 | 44196 |    36   (3)| 00:00:01 |
    |   2 |   VIEW                |                   |    61 |  3294 |    33   (0)| 00:00:01 |
    |   3 |    NESTED LOOPS       |                   |    61 | 10980 |    33   (0)| 00:00:01 |
    |   4 |     TABLE ACCESS FULL | AUSTRALIAN_STATES |     8 |   920 |     3   (0)| 00:00:01 |
    |*  5 |     TABLE ACCESS FULL | GUTDATA           |     8 |   520 |     4   (0)| 00:00:01 |
    |   6 |   INDEX FAST FULL SCAN| GUTDATA_ID_PK     |   762 |  3048 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - access("T2"."CITY"(+)="T1"."ID")
       5 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
       Statistics
                   7  user calls
               49152  physical read total bytes
                   0  physical write total bytes
                   0  spare statistic 3
                   0  commit cleanout failures: cannot pin
                   0  TBS Extension: bytes extended
                   0  total number of times SMON posted
                   0  SMON posted for undo segment recovery
                   0  SMON posted for dropping temp segment
                   0  segment prealloc tasksFinally, the Pièce de résistance: trick the LEFT OUTER JOIN operator...
    set serveroutput on timing on autotrace on
    SELECT T1.SPECIES    as City,
           T2.ADMIN_NAME as Municipality,
           T2.GEOM       as geom
      FROM GUTDATA           T1
           LEFT OUTER JOIN
           AUSTRALIAN_STATES T2
           ON (t2.admin_name = to_char(t1.ID) OR
               SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
    762 rows selected
    Elapsed: 00:00:50.273
    Plan hash value: 158854308
    | Id  | Operation           | Name              | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT    |                   |   762 | 92964 |  2294   (1)| 00:00:28 |
    |   1 |  NESTED LOOPS OUTER |                   |   762 | 92964 |  2294   (1)| 00:00:28 |
    |   2 |   TABLE ACCESS FULL | GUTDATA           |   762 | 49530 |     5   (0)| 00:00:01 |
    |   3 |   VIEW              |                   |     1 |    57 |     3   (0)| 00:00:01 |
    |*  4 |    TABLE ACCESS FULL| AUSTRALIAN_STATES |     1 |   115 |     3   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       4 - filter("T2"."ADMIN_NAME"=TO_CHAR("T1"."ID") OR
                  "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
       Statistics
                   7  user calls
                   0  physical read total bytes
                   0  physical write total bytes
                   0  spare statistic 3
                   0  commit cleanout failures: cannot pin
                   0  TBS Extension: bytes extended
                   0  total number of times SMON posted
                   0  SMON posted for undo segment recovery
                   0  SMON posted for dropping temp segment
                   0  segment prealloc tasksTry these combinations to see what works for you.
    Interestingly, for me, the following returns absolutely nothing.
    SELECT T1.SPECIES    as City,
           T2.ADMIN_NAME as Municipality
      FROM GUTDATA           T1
           LEFT OUTER JOIN
           AUSTRALIAN_STATES T2
           ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
    MINUS
    SELECT T1.SPECIES    as City,
           T2.ADMIN_NAME as Municipality
      FROM GUTDATA           T1
           LEFT OUTER JOIN
           AUSTRALIAN_STATES T2
           ON (t2.admin_name =  to_char(t1.ID) OR
               SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');(I leave it to you to see if you can see why as the LEFT OUTER JOIN seems to be working correctly for me but I am not going to dedicate time to detailed checking of results.)
    Note all tests performed on Oracle 11g R2 (11.2.0.1.0)
    If you get the answer you want: mark the post as answered to assign points.
    regards
    Simon

  • SQL Query not using Composite Index

    Hi,
    Please look at the below query:
    SELECT pde.participant_uid
    ,pde.award_code
    ,pde.award_type
    ,SUM(decode(pde.distribution_type
    ,'FORFEITURE'
    ,pde.forfeited_quantity *
    pde.sold_price * cc.rate
    ,pde.distributed_quantity *
    pde.sold_price * cc.rate)) AS gross_Amt_pref_Curr
    FROM part_distribution_exec pde
    ,currency_conversion cc
    ,currency off_curr
    WHERE pde.participant_uid = 4105
    AND off_curr.currency_iso_code =
    pde.offering_currency_iso_code
    AND cc.from_currency_uid = off_curr.currency_uid
    AND cc.to_currency_uid = 1
    AND cc.latest_flag = 'Y'
    GROUP BY pde.participant_uid
    ,pde.award_code
    ,pde.award_type
    In oracle 9i, i"ve executed this above query, it takes 6 seconds and the cost is 616, this is due to non usage of the composite index, Currency_conversion_idx(From_currency_uid, To_currency_uid, Latest_flag). I wonder why this index is not used while executing the above query. So, I've dropped the index and recreated it. Now, the query is using this index. After inserting many rows or say in 1 days time, if the same query is executed, again the query is not using the index. So everyday, the index should be dropped and recreated.
    I don't want this drop and recreation of index daily, I need a permanent solution for this.
    Can anyone tell me, Why this index goes stale after a period of time???? Please take some time and Solve this issue.
    -Sankar

    Hi David,
    This is Sankar here. Thankyou for your reply.
    I've got the plan table output for this problematic query, please go thro' it and help me out why the index CURRENCY_CONVERSION_IDX is used now and why it's not using while executing the query after a day or inserting some records...
    PLAN_TABLE_OUTPUT
    | Id | Operation | Name | Rows | Bytes | Cost |
    | 0 | SELECT STATEMENT | | 26 | 15678 | 147 |
    | 1 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 89 | 2 |
    |* 2 | INDEX UNIQUE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 61097 | | 1 |
    | 3 | SORT AGGREGATE | | 1 | 67 | |
    |* 4 | FILTER | | | | |
    |* 5 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | 67 | 2 |
    | 6 | SORT AGGREGATE | | 1 | 94 | |
    |* 7 | FILTER | | | | |
    |* 8 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_PAYOUT_SCHEDULE | 1 | 94 | 3 |
    |* 9 | INDEX RANGE SCAN | PART_AWARD_PAYOUT_SCHEDULE_PK1 | 1 | | 2 |
    |* 10 | FILTER | | | | |
    |* 11 | HASH JOIN | | 26 | 15678 | 95 |
    |* 12 | HASH JOIN OUTER | | 26 | 11596 | 91 |
    |* 13 | HASH JOIN | | 26 | 10218 | 86 |
    | 14 | VIEW | | 1 | 82 | 4 |
    | 15 | SORT GROUP BY | | 1 | 116 | 4 |
    |* 16 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_LEDGER | 1 | 116 | 2 |
    |* 17 | INDEX RANGE SCAN | PARTICIPANT_UID_IDX | 1 | | 1 |
    |* 18 | HASH JOIN OUTER | | 26 | 8086 | 82 |
    |* 19 | HASH JOIN | | 26 | 6006 | 71 |
    | 20 | NESTED LOOPS | | 36 | 5904 | 66 |
    | 21 | NESTED LOOPS | | 1 | 115 | 65 |
    | 22 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 18 | 756 | 2 |
    |* 23 | INDEX RANGE SCAN | KLS_IDX_CURRENCY_CONV | 3 | | 1 |
    | 24 | VIEW | | 1 | 73 | 4 |
    | 25 | SORT GROUP BY | | 1 | 71 | 4 |
    | 26 | TABLE ACCESS BY INDEX ROWID| PART_AWARD_VALUE | 1 | 71 | 2 |
    |* 27 | INDEX RANGE SCAN | PAV_PARTICIPANT_UID_IDX | 1 | | 1 |
    | 28 | TABLE ACCESS BY INDEX ROWID | PARTICIPANT_AWARD | 199 | 9751 | 1 |
    |* 29 | INDEX UNIQUE SCAN | PARTICIPANT_AWARD_PK1 | 100 | | |
    |* 30 | INDEX FAST FULL SCAN | PARTICIPANT_AWARD_TYPE_PK1 | 147 | 9849 | 4 |
    | 31 | VIEW | | 1 | 80 | 10 |
    | 32 | SORT GROUP BY | | 1 | 198 | 10 |
    |* 33 | TABLE ACCESS BY INDEX ROWID | CURRENCY_CONVERSION | 1 | 42 | 2 |
    | 34 | NESTED LOOPS | | 1 | 198 | 8 |
    | 35 | NESTED LOOPS | | 2 | 312 | 4 |
    | 36 | TABLE ACCESS BY INDEX ROWID| PART_DISTRIBUTION_EXEC | 2 | 276 | 2 |
    |* 37 | INDEX RANGE SCAN | IND_PARTICIPANT_UID | 1 | | 1 |
    | 38 | TABLE ACCESS BY INDEX ROWID| CURRENCY | 1 | 18 | 1 |
    |* 39 | INDEX UNIQUE SCAN | CURRENCY_AK | 1 | | |
    |* 40 | INDEX RANGE SCAN | CURRENCY_CONVERSION_AK | 2 | | 1 |
    | 41 | VIEW | | 1 | 53 | 4 |
    | 42 | SORT GROUP BY | | 1 | 62 | 4 |
    |* 43 | TABLE ACCESS BY INDEX ROWID | PART_AWARD_VESTING | 1 | 62 | 2 |
    |* 44 | INDEX RANGE SCAN | PAVES_PARTICIPANT_UID_IDX | 1 | | 1 |
    | 45 | TABLE ACCESS FULL | AWARD | 1062 | 162K| 3 |
    | 46 | TABLE ACCESS BY INDEX ROWID | CURRENCY | 1 | 18 | 2 |
    |* 47 | INDEX UNIQUE SCAN | CURRENCY_AK | 102 | | 1 |
    Predicate Information (identified by operation id):
    2 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2
    "PAPS"."INSTALLMENT_NUM"=1)
    4 - filter(4105=:B1)
    5 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
    7 - filter(4105=:B1)
    8 - filter("PAPS"."STATUS"='OPEN')
    9 - access("PAPS"."AWARD_CODE"=:B1 AND "PAPS"."PARTICIPANT_UID"=4105 AND "PAPS"."AWARD_TYPE"=:B2)
    10 - filter("CC_A_P_CURR"."FROM_CURRENCY_UID"= (SELECT /*+ */ "CURRENCY"."CURRENCY_UID" FROM
    "EWAPDBO"."CURRENCY" "CURRENCY" WHERE "CURRENCY"."CURRENCY_ISO_CODE"=:B1))
    11 - access("SYS_ALIAS_7"."AWARD_CODE"="A"."AWARD_CODE")
    12 - access("SYS_ALIAS_7"."AWARD_CODE"="PVS"."AWARD_CODE"(+))
    13 - access("SYS_ALIAS_8"."AWARD_CODE"="PALS"."AWARD_CODE" AND
    "SYS_ALIAS_8"."AWARD_TYPE"="PALS"."AWARD_TYPE")
    16 - filter(TRUNC("PAL1"."LEDGER_ENTRY_DATE")<=TRUNC(SYSDATE@!) AND "PAL1"."ALLOC_TYPE"='IPU')
    17 - access("PAL1"."PARTICIPANT_UID"=4105)
    filter("PAL1"."PARTICIPANT_UID"=4105)
    18 - access("SYS_ALIAS_8"."AWARD_CODE"="PDES"."AWARD_CODE"(+) AND
    "SYS_ALIAS_8"."AWARD_TYPE"="PDES"."AWARD_TYPE"(+))
    19 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_8"."AWARD_CODE")
    23 - access("CC_A_P_CURR"."TO_CURRENCY_UID"=1 AND "CC_A_P_CURR"."LATEST_FLAG"='Y')
    27 - access("PAV"."PARTICIPANT_UID"=4105)
    filter("PAV"."PARTICIPANT_UID"=4105)
    29 - access("SYS_ALIAS_7"."AWARD_CODE"="SYS_ALIAS_9"."AWARD_CODE" AND
    "SYS_ALIAS_7"."PARTICIPANT_UID"=4105)
    30 - filter("SYS_ALIAS_8"."PARTICIPANT_UID"=4105)
    33 - filter("CC"."LATEST_FLAG"='Y')
    37 - access("PDE"."PARTICIPANT_UID"=4105)
    filter("PDE"."PARTICIPANT_UID"=4105)
    39 - access("OFF_CURR"."CURRENCY_ISO_CODE"="PDE"."OFFERING_CURRENCY_ISO_CODE")
    40 - access("CC"."FROM_CURRENCY_UID"="OFF_CURR"."CURRENCY_UID" AND "CC"."TO_CURRENCY_UID"=1)
    43 - filter("PV"."VESTING_DATE"<=SYSDATE@!)
    44 - access("PV"."PARTICIPANT_UID"=4105)
    filter("PV"."PARTICIPANT_UID"=4105)
    47 - access("CURRENCY"."CURRENCY_ISO_CODE"=:B1)
    Note: cpu costing is off
    93 rows selected.
    Please help me out...
    -Sankar

  • Query not using the index

    Query
    SELECT case.case_objid FROM [email protected] case, table_x_cwp_tickect_details_vw t WHERE CASE.case_condition_cd IN ('OPEN', 'OPEN-DISPATCH', 'OPEN-REJECT', 'OPEN-RETURNED') AND case.case_type_cd in ('CUSTOMER FAULT', 'CHRONIC','SCHEDULED ACTIVITY','PROBLEM') AND ROWNUM <= 500 AND case.case_objid = t.ticket_objid AND ( ( case.account_id = '672286' ) ) ORDER BY case.case_id DESC
    From PROD
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 2,629 Bytes: 221,500 Cardinality: 500
         37 SORT ORDER BY Cost: 2,629 Bytes: 221,500 Cardinality: 500
              36 COUNT STOPKEY
                   35 NESTED LOOPS OUTER Cost: 2,628 Bytes: 279,533 Cardinality: 631
                        33 HASH JOIN OUTER Cost: 2,627 Bytes: 275,116 Cardinality: 631
                             31 NESTED LOOPS OUTER Cost: 2,249 Bytes: 266,282 Cardinality: 631
                                  28 NESTED LOOPS Cost: 1,766 Bytes: 257,448 Cardinality: 631
                                       26 NESTED LOOPS Cost: 1,765 Bytes: 253,031 Cardinality: 631
                                            24 NESTED LOOPS Cost: 1,764 Bytes: 248,614 Cardinality: 631
                                                 22 NESTED LOOPS Cost: 1,763 Bytes: 244,197 Cardinality: 631
                                                      19 NESTED LOOPS Cost: 1,258 Bytes: 235,363 Cardinality: 631
                                                           17 NESTED LOOPS Cost: 1,257 Bytes: 230,946 Cardinality: 631
                                                                14 NESTED LOOPS OUTER Cost: 752 Bytes: 217,695 Cardinality: 631
                                                                     12 HASH JOIN Cost: 751 Bytes: 213,278 Cardinality: 631
                                                                          1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                          11 HASH JOIN Cost: 748 Bytes: 208,861 Cardinality: 631
                                                                               2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                               10 HASH JOIN Cost: 746 Bytes: 204,444 Cardinality: 631
                                                                                    3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                    9 HASH JOIN Cost: 743 Bytes: 200,027 Cardinality: 631
                                                                                         4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,052 Cardinality: 1,436
                                                                                         8 NESTED LOOPS Cost: 741 Bytes: 195,610 Cardinality: 631
                                                                                              5 REMOTE REMOTE CASE Cost: 235 Bytes: 156,488 Cardinality: 631
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                     13 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                16 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                     15 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                           18 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      21 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                           20 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                 23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                            25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                       27 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                  30 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                       29 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                             bold 32 TABLE ACCESS FULL TABLE SA.TABLE_MOD_LEVEL Cost: 376 Bytes: 1,442,084 Cardinality: 103,006 bold
                        34 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    From DEV platform
    Plan
    SELECT STATEMENT HINT: FIRST_ROWS Cost: 591 Bytes: 61,134 Cardinality: 138
         37 SORT ORDER BY Cost: 591 Bytes: 61,134 Cardinality: 138
              36 COUNT STOPKEY
                   35 HASH JOIN Cost: 590 Bytes: 61,134 Cardinality: 138
                        1 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                        34 HASH JOIN Cost: 588 Bytes: 60,168 Cardinality: 138
                             2 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                             33 HASH JOIN Cost: 585 Bytes: 59,202 Cardinality: 138
                                  3 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                  32 HASH JOIN Cost: 583 Bytes: 58,236 Cardinality: 138
                                       4 INDEX FAST FULL SCAN INDEX (UNIQUE) SA.GBST_ELM_OBJINDEX Cost: 2 Bytes: 10,045 Cardinality: 1,435
                                       31 NESTED LOOPS OUTER Cost: 580 Bytes: 57,270 Cardinality: 138
                                            29 NESTED LOOPS OUTER Cost: 579 Bytes: 56,304 Cardinality: 138
                                                 27 NESTED LOOPS OUTER Cost: 469 Bytes: 54,372 Cardinality: 138
                                                      24 NESTED LOOPS Cost: 363 Bytes: 52,440 Cardinality: 138
                                                           22 NESTED LOOPS Cost: 362 Bytes: 51,474 Cardinality: 138
                                                                20 NESTED LOOPS Cost: 361 Bytes: 50,508 Cardinality: 138
                                                                     18 NESTED LOOPS Cost: 360 Bytes: 49,542 Cardinality: 138
                                                                          15 NESTED LOOPS Cost: 249 Bytes: 47,610 Cardinality: 138
                                                                               13 NESTED LOOPS Cost: 248 Bytes: 46,644 Cardinality: 138
                                                                                    10 NESTED LOOPS OUTER Cost: 138 Bytes: 43,746 Cardinality: 138
                                                                                         8 NESTED LOOPS Cost: 137 Bytes: 42,780 Cardinality: 138
                                                                                              5 REMOTE REMOTE CASE Cost: 26 Bytes: 34,224 Cardinality: 138
                                                                                              7 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_CASE Cost: 1 Bytes: 62 Cardinality: 1
                                                                                                   6 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.TC_C_CASE_OBJINDEX Cost: 1 Cardinality: 1
                                                                                         9 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.UN_PTT2CASE Cost: 1 Bytes: 7 Cardinality: 1
                                                                                    12 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_SITE Cost: 1 Bytes: 21 Cardinality: 1
                                                                                         11 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_OBJINDEX Cost: 1 Cardinality: 1
                                                                               14 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.BUS_ORG_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                          17 TABLE ACCESS BY INDEX ROWID TABLE SA.TABLE_ADDRESS Cost: 1 Bytes: 14 Cardinality: 1
                                                                               16 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.ADDRESS_OBJINDEX Cost: 1 Cardinality: 1
                                                                     19 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.COUNTRY_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                                21 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONTACT_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                           23 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.CONDITION_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
                                                      26 TABLE ACCESS BY GLOBAL INDEX ROWID TABLE SA.TABLE_SITE_PART Cost: 1 Bytes: 14 Cardinality: 1 Partition #: 34
                                                           25 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.SITE_PART_OBJINDEX Cost: 1 Cardinality: 1
                                       bold           28 INDEX RANGE SCAN INDEX SA.IND_PART_INFO2PART_NUM Cost: 1 Bytes: 14 Cardinality: 1 bold
                                            30 INDEX UNIQUE SCAN INDEX (UNIQUE) SA.PART_NUM_OBJINDEX Cost: 1 Bytes: 7 Cardinality: 1
    Conclusion:
    IND_PART_INFO2PART_NUM is not in use in Production environment
    PROD
    1. SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR
    IND_PART_INFO2PART_NUM 103023 46488
    DEV environment
    SQL> select index_name,NUM_ROWS,CLUSTERING_FACTOR,table_name from dba_indexes where index_name='IND_PART_INFO2PART_NUM';
    INDEX_NAME NUM_ROWS CLUSTERING_FACTOR TABLE_NAME
    IND_PART_INFO2PART_NUM 101982 45722 TABLE_MOD_LEVEL
    1. Index is rebuild
    2. stats are up to date
    3. Redef on table is done.
    Still no change in the plan .

    Osama-mustafa wrote:
    Aman.... wrote:
    Osama-mustafa wrote:
    alter index <index-name> rebuild ;Why?
    Aman....I faced this issue with query and indexes was need rebuildWhat issue Osama-that query wasn't using index and after rebuild it did start using it? Not just that this reply is wrong , this is OP has mentioned that he has done already. Please note that index rebuild is not the answer when the query is not using the index. There can be many reasons behind it. Have a look at Richard Foote's blog where he explains all of this in a very detailed way and in many posts.
    Aman....

  • Spatial Query not using Spatial Index

    Hi All,
    I have a query which uses the SDO_WITHIN_DISTANCE operator, but is taking far too long to complete.
    SELECT
                   RT.*,RD.RPD_NODE_ID, RD.RPD_XCOORD,RD.RPD_YCOORD
              FROM
                   railplan_data RD
                   LEFT JOIN Walk_data_sets WDS ON RD.RPD_RPS_ID = WDS.WDS_RPS_ID
                   LEFT JOIN RWNet_Temp RT ON WDS.WDS_ID = RT.RW_WDS_ID
              WHERE
                   WDS.wds_id = 441
              AND
                   MDSYS.SDO_WITHIN_DISTANCE(RT.RW_GEOM,RD.RPD_GEOLOC,'DISTANCE=' || TO_CHAR(RT.RW_BUFFER) || ' UNIT=METER') = 'TRUE';
    Upon generation of the explain plan I have realised that the spatial index is not being used in the query, but I can't for the life of me get the thing working
    3     | Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
    4     ------------------------------------------------------------------------------------------
    5     | 0 | SELECT STATEMENT | | 25841 | 99M| | 201 |
    6     |* 1 | FILTER | | | | | |
    7     | 2 | MERGE JOIN OUTER | | | | | |
    8     |* 3 | HASH JOIN | | 12652 | 420K| 2968K| 185 |
    9     | 4 | TABLE ACCESS FULL | RAILPLAN_DATA | 75910 | 2075K| | 60 |
    10     | 5 | TABLE ACCESS BY INDEX ROWID| WALK_DATA_SETS | 1 | 6 | | 1 |
    11     |* 6 | INDEX UNIQUE SCAN | WDS_PK | 1 | | | |
    12     |* 7 | SORT JOIN | | 16 | 63760 | | 16 |
    13     |* 8 | TABLE ACCESS FULL | RWNET_TEMP | 16 | 63760 | | 4 |
    If anyone could help me out in figuring out why the spatial index is not being used, I would be most appreciative.
    TIA
    Dan

    Hi all again,
    Well I finally got an upgrade to Oracle 10 (yay!), so I am now trying to implement the SDO_JOIN method as per my earlier posts. In fact it is actually working, but I have a question. When I run an explain plan it does not show the use of any domain indexes which I would expect to see, but performs fine (1.07s) with just a few records (10 in 1 table, 15000 in the other), please see code and explain plan below:
    SELECT
      Distinct
        RT.RW_ID, RD.RPD_NODE_ID,
        RD.RPD_XCOORD,RD.RPD_YCOORD
    FROM
        RPD_TEMP_762 RD,
        WALK_DATA_SETS WDS,
        RWNET_TEMP RT,
        TABLE
        (SDO_JOIN
            (  'RWNET_TEMP',
                'RW_GEOM',
                'RPD_TEMP_762',
                'RPD_GEOLOC',
                'distance= ' || TO_CHAR(RT.RW_BUFFER) || ' unit=meter')) SPATIAL_JOIN_RESULT
    WHERE WDS.WDS_ID = RT.RW_WDS_ID
    AND WDS.WDS_ID = 762
    AND SPATIAL_JOIN_RESULT.ROWID1 = RT.ROWID
    AND SPATIAL_JOIN_RESULT.ROWID2 = RD.ROWID
    PLAN_TABLE_OUTPUT                                                                                                                                                                                                                                                                                           
    | Id  | Operation                            | Name         | Rows  | Bytes | Cost (%CPU)|                                                                                                                                                                                                                  
    |   0 | SELECT STATEMENT                     |              |    74 |  5994 | 21753   (1)|                                                                                                                                                                                                                  
    |   1 |  SORT UNIQUE                         |              |    74 |  5994 | 21691   (1)|                                                                                                                                                                                                                  
    |*  2 |   HASH JOIN                          |              |  1046K|    80M|  1859   (1)|                                                                                                                                                                                                                  
    |   3 |    NESTED LOOPS                      |              |  6076 |   213K|  1824   (1)|                                                                                                                                                                                                                  
    |   4 |     NESTED LOOPS                     |              |    74 |  2516 |   194   (1)|                                                                                                                                                                                                                  
    |*  5 |      INDEX UNIQUE SCAN               | WDS_PK       |     1 |     4 |     0   (0)|                                                                                                                                                                                                                  
    |*  6 |      TABLE ACCESS FULL               | RWNET_TEMP   |    74 |  2220 |   194   (1)|                                                                                                                                                                                                                  
    |*  7 |     COLLECTION ITERATOR PICKLER FETCH| SDO_JOIN     |       |       |            |                                                                                                                                                                                                                  
    |   8 |    TABLE ACCESS FULL                 | RPD_TEMP_762 | 17221 |   756K|    28   (0)|                                                                                                                                                                                                                  
    ------------------------------------------------------------------------------------------  When i try to add hints to force the use of spatial indexes the performance of this query drops through the floor (it takes minutes / hours), index hint shown below:
    /*+ ORDERED INDEX(RW rw_geom) INDEX(RD rpd_geoloc) */My question is is the first query using domain indexes, and if not, how do I get it to?
    TIA
    Dan

  • Simple query but not using index..please help??

    I do have this column indexed. Why my query is not using this index?
    Any help .
    select count(*) from v_dis_sub_har;
    SQL>
      COUNT(*)
       4543289
    1 row selected.
    SQL>
    select vzw_vendor_id , count(*)
    from v_dis_sub_har
    group by vzw_vendor_id
    SQL>   2    3    4 
    VZW_VENDOR_ID   COUNT(*)
           200091     908653
           200013     908659
           200012     908659
           200057     908659
           200031     908659
    5 rows selected.
    SQL> SQL>
    explain plan for
    select
    event_seq
    from v_dis_sub_har b 
    where b.VZW_VENDOR_ID='200013'
    -- and b.status='P' and b.extract_date is null
    SQL>   2    3    4    5    6    7 
    Explained.
    SQL> SQL>
    select plan_table_output from table(dbms_xplan.display)
    SQL> SQL>   2 
    PLAN_TABLE_OUTPUT
    Plan hash value: 2852398983
    | Id  | Operation         | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |               |   908K|  7986K|  3132  (16)| 00:00:38 |
    |*  1 |  TABLE ACCESS FULL| V_DIS_SUB_HAR |   908K|  7986K|  3132  (16)| 00:00:38 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       1 - filter("B"."VZW_VENDOR_ID"=200013)
    13 rows selected.
    SQL> SQL>

    You are right Justin. Oracle is not stupid as you may want to say some times when things do not happen according to you. I just created a bitmap index on status field and look what appened. Som times it uses bitmap index and some times it does not. And the reason is clear. Row count by status. 'S' status uses bitmap index where 'P' does not.
    Thanks for your help.
    select   status, count(*)
    from v_dis_sub_har
    group  by status
    ;SQL>   2    3    4 
    S   COUNT(*)
    A    5844982
    P    2312759
    S      20178
    3 rows selected.
    SQL>
    explain plan for
    select
    event_seq
    from v_dis_sub_har b 
    where
    --b.VZW_VENDOR_ID=200013
    --  and
    b.status='S'
    --and b.extract_date is null
    select plan_table_output from table(dbms_xplan.display)
    SQL>   2    3    4    5    6    7    8    9   10 
    Explained.
    SQL> SQL> SQL> SQL>   2 
    PLAN_TABLE_OUTPUT
    Plan hash value: 829738689
    | Id  | Operation                    | Name                         | Rows  | Bytes | Cost (%CPU)| T
    ime     |
    PLAN_TABLE_OUTPUT
    |   0 | SELECT STATEMENT             |                              | 20290 |   118K|  2772   (1)| 0
    0:00:34 |
    |   1 |  TABLE ACCESS BY INDEX ROWID | V_DIS_SUB_HAR                | 20290 |   118K|  2772   (1)| 0
    0:00:34 |
    |   2 |   BITMAP CONVERSION TO ROWIDS|                              |       |       |            |
            |
    |*  3 |    BITMAP INDEX SINGLE VALUE | V_DISPATCH_SUBSCRIPTION_NDX2 |       |       |            |
            |
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
       3 - access("B"."STATUS"='S')
    15 rows selected.
    SQL> SQL> set line 120
    SQL> /
    PLAN_TABLE_OUTPUT
    Plan hash value: 829738689
    | Id  | Operation                    | Name                         | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT             |                              | 20290 |   118K|  2772   (1)| 00:00:34 |
    |   1 |  TABLE ACCESS BY INDEX ROWID | V_DIS_SUB_HAR                | 20290 |   118K|  2772   (1)| 00:00:34 |
    |   2 |   BITMAP CONVERSION TO ROWIDS|                              |       |       |            |          |
    |*  3 |    BITMAP INDEX SINGLE VALUE | V_DISPATCH_SUBSCRIPTION_NDX2 |       |       |            |          |
    PLAN_TABLE_OUTPUT
    Predicate Information (identified by operation id):
       3 - access("B"."STATUS"='S')
    15 rows selected.
    SQL>
    explain plan for
    select
    event_seq
    from v_dis_sub_har b 
    where
    --b.VZW_VENDOR_ID=200013
    --  and
    b.status='P'
    --and b.extract_date is null
    select plan_table_output from table(dbms_xplan.display)
          SQL>   2    3    4    5    6    7    8    9   10 
    Explained.
    SQL> SQL> SQL> SQL>   2 
    PLAN_TABLE_OUTPUT
    Plan hash value: 2852398983
    | Id  | Operation         | Name          | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |               |  2325K|    13M|  5784  (18)| 00:01:10 |
    |*  1 |  TABLE ACCESS FULL| V_DIS_SUB_HAR |  2325K|    13M|  5784  (18)| 00:01:10 |
    Predicate Information (identified by operation id):
    PLAN_TABLE_OUTPUT
       1 - filter("B"."STATUS"='P')
    13 rows selected.
    SQL>

  • Why is this query not using my index ?

    hey
    i have the following situation
    (i'm sorry but i can't add the acctual script or output)
    create table x as
    select      level high_card ,
         mod(level,1000) medium_card ,
         mod(level,10) low_card ,
         '***' padding
    from     dual
    connect by level < 100001;
    create index x_med_low_ix on x(low_card,medium_card);
    create index x_high_ix on x(high_card);
    exec dbms_stats.gather_table_stats(user,'x',cascade=>true,method_opt=>'for all indexed columns size auto');
    i'm running the following query
    select      *
    from      x
    where      low_card = 70
    and     medium_card = 70
    and     high_card = 70;
    i'm expecting a range scan on the x_high_ix index. the optimizer expects only one row. the stats on the high_card columns shows that (num_rows * density = 1).
    when i run the query the optimizer uses the x_med_low_ix and does 14 cr.
    when i force the use of x_high_ix the cr goes down to 4.
    i don't want to declare x_high_ix as unique.
    so, why isn't he using my index ?

    It's using that index for me:
    SQL> create table x as
      2  select level high_card ,
      3  mod(level,1000) medium_card ,
      4  mod(level,10) low_card ,
      5  '***' padding
      6  from dual
      7  connect by level < 100001;
    Table created.
    SQL>
    SQL> create index x_med_low_ix on x(low_card,medium_card);
    Index created.
    SQL>
    SQL> create index x_high_ix on x(high_card);
    Index created.
    SQL>
    SQL> exec dbms_stats.gather_table_stats(user,'x',cascade=>true,method_opt=>'for all indexed columns
    size auto');
    PL/SQL procedure successfully completed.
    SQL> ed
    Wrote file afiedt.buf
      1   select *
      2   from x
      3   where low_card = 70
      4   and medium_card = 70
      5*  and high_card = 70
    SQL>
    SQL> /
    no rows selected
    Execution Plan
    Plan hash value: 775193209
    | Id  | Operation                   | Name      | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT            |           |     1 |    15 |     2   (0)| 00:00:01 |
    |*  1 |  TABLE ACCESS BY INDEX ROWID| X         |     1 |    15 |     2   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | X_HIGH_IX |     1 |       |     1   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("LOW_CARD"=70 AND "MEDIUM_CARD"=70)
       2 - access("HIGH_CARD"=70)
    Statistics
              0  recursive calls
              0  db block gets
              3  consistent gets
              0  physical reads
              0  redo size
            454  bytes sent via SQL*Net to client
            370  bytes received via SQL*Net from client
              1  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
              0  rows processed
    SQL> set autot off
    SQL> select * from v$version;
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    PL/SQL Release 10.2.0.1.0 - Production
    CORE    10.2.0.1.0      Production
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
    NLSRTL Version 10.2.0.1.0 - Productionwhat is your version?
    By the way, when i force optimizer to use index X_MED_LOW_IX, it does 2 CR for me.

Maybe you are looking for