Index in not used

Hi Guys,
I have a table FOLDER_CUSTOMER which has two columns folder_id and customer_id.
We have index on the customer id but the customer_id is in this format '000900000000000000000000035102' which is same for most of the customers except the last 5 digits .So the index is not getting used.
Can any one give me some inputs for getting the index used and also some tuning thoughts.
The sql query is below
SELECT FC1.FOLDER_ID FROM FOLDER_CUSTOMER FC1 WHERE FC1.CUSTOMER_ID ='000900000000000000000000035102';
Regards,
Papi

957590 wrote:
Thank you guys for all these inputs.
What I think the index is not being used because the indexed column has the values which has all most same data only difference in the last few numbers.So is there any way to create optimal index like function based index or reverse key index to help to perform better.
>Thank you guys for all these inputs.
What I think the index is not being used because the indexed column has the values which has all most same data only difference in the last few numbers.So is there any way to create optimal index like function based index or reverse key index to help to perform better.
No, I don't think it is to do with that. If they are unique values it doesn't matter if they only differ in the last few digits.
However, I suspect you have multiple rows with the same value in that table.
Remember indexed access can be slower than a full table scan in certain circumstances.
We need more information, please read: {message:id=9360003} and follow the advice there.

Similar Messages

Why index is not used by this table

Dear all,
Currently I'm facing problem with tuning one sql statement.
It shows that full table scan in ZTLTBC_FILTER cost 15:19.
But in table ZTLTBC_FILTER, it have index with field
index 1    MANDT INT_NAME FNAME VALUE
index 2    MANDT EXEC_ID COUNTER
index 3    MANDT INT_NAME VALUE
the last statistic date for these index is three months before
Could you please help to find out the reason why index is not used? statistics are old or small distinct value for field INT_NAME?
How to solve this full table scan problem?
Thanks & Regards,
Chris
sql statement
SELECT T_00."MANDT",T_00."EXEC_ID",T_00."COUNTER",T_00."FNAME",T_00."INT_NAME",T_00."VALUE"
FROM "ZTLTBC_FILTER" T_00
WHERE T_00."MANDT"=:A0 AND T_00."INT_NAME"=:A1 AND EXISTS
(SELECT T_100."INT_NAME"
FROM "ZTLTBC_MIRR_BUFF" T_100
WHERE T_100."MANDT"=:A2 AND T_100."INT_NAME"=:A3 AND T_100."EXEC_ID"=T_00."EXEC_ID" AND
T_100."COUNTER"=T_00."COUNTER")
| Id | Operation            | Name               | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |                    |       |       |       |   176K(100)|          |
|* 1 | HASH JOIN RIGHT SEMI|                    | 9958K| 1111M|   598M|   176K (2)| 00:17:53 |
|* 2 |   INDEX RANGE SCAN   | ZTLTBC_MIRR_BUFF~0 | 9958K|   484M|       | 6265   (1)| 00:00:39 |
|* 3 |   TABLE ACCESS FULL | ZTLTBC_FILTER      |    13M|   822M|       |   150K (2)| 00:15:19 |
   1 - access("T_100"."EXEC_ID"="T_00"."EXEC_ID" AND "T_100"."COUNTER"="T_00"."COUNTER")
   2 - access("T_100"."MANDT"=:A2 AND "T_100"."INT_NAME"=:A3)
   3 - filter(("T_00"."INT_NAME"=:A1 AND "T_00"."MANDT"=:A0))

Hello Bret,
I'm using oracle 11.2
Thanks & Regards,
Chris

Index is not used (why and what should i do) table too big

hi guys,
having a headache now. (on 10gR2 on linux system)
I used to have a large table and this is how i managed it. (i am on standard edition (thus i have no partitioning)
i would have a
1) cron job run daily to keep track of the lowest and highest ID of the table PER MONTH (inserted into a table)
2) below is the table
CDR     MONTH     01-AUG-11 00:00:00     94118236     97584656
CDR     MONTH     01-SEP-11 00:00:00     97581362     100573669
CDR     MONTH     01-OCT-11 00:00:00     100570865     103631203
CDR     MONTH     01-NOV-11 00:00:00     103629760     106497084
CDR     MONTH     01-DEC-11 00:00:00     106494085     107306335
so as you can see, for the month of dec for example, the lowest CDR is 10649408 and the highest is 107306335.
3) so everytime i write a sql on this table if i want to get data for NOV
select * from cdr where ID >= get_cdr_id('CDR','NOV','SMALLEST');
and it would be
select * from cdr where ID >= 103629760;
In the past, the index will be used (index range scan), but now the optimiser is doing a FTS and is taking too much time.
therefore i went to force the index
select /*+INDEX(C, CDR_PK)*/* from cdr C where cdr_id > 103629760 and cdr_id < 106497084;
and the COST -> 1678927 (CDR, INDEX_ROWID)
13158 (CDR_PK, RANGE SCAN)
-- the result return is fast and good.
without the index
select * from cdr C where cdr_id > 100570865 and cdr_id < 103631203
the COST -> 440236 (CDR,FULL)
-- but the result return is slow like anything
My question is
1) which cost should i look at ?
the one with index hint have much higher COST, but the results return are so FAST.
1678927 (with hint) compare with 440236 (FTS)
2) is using the index is the correct way, why isnt my optimiser using it ?! how do i make the optimiser used it ?
Regards,
Noob

Iordan Iotzov wrote:
About the clustering factor– I think there are two possibilities:
1) The “clustering factor” is generally correct, i.e. it represents the true value of how the data is “scattered” through the table. The clustering factor for the fragment of data you are interested in (where cdr_id > 100570865 and cdr_id < 103631203), however, is different (smaller).
2)Oracle did not compute the “clustering factor” correctly. It is not uncommon occurrence, particularly in 10g. This blog entry by Randolf Geist is quite informative - http://oracle-randolf.blogspot.com/2010/01/clusteringfactor-what-if-analysis.html. Comprehensive information on that topic is available in Jonathan Lewis’ book Cost Based Oracle Fundamentals (chapter 5).
You can make the index more attractive by setting lower “clustering factor” value using DBMS_STATS.SET_INDEX_STATS. If you choose to do that, you should review your whole stats gathering procedure, because the next gathering would most likely reset the “clustering factor” to its old (high) value.
Iordan Iotzov
http://iiotzov.wordpress.com/

Index is not used, although hint.

DBVersion: 10.2.0.3
CREATE TABLE "ESW"."DURCHLAUFZEIT_SONDER_AG"
   (     "AG" NUMBER(3,0) DEFAULT 0 NOT NULL ENABLE,
     "TAGE" NUMBER(5,0) DEFAULT 0 NOT NULL ENABLE,
     "ABTEILUNG" VARCHAR2(20 BYTE),
Content of this table
AG    TAGE ABTEILUNG
910     1     EAV
133     1     TG
743     2     TM
719     2     TM
706     2     TM
979     10     TMWhen I use a select like this no index on tabel "walze w2" is used:
select /*+ index(apl(arbeitsgang_nr))*/
       /*+ index(w2 WALZE_IND1)*/
        SUM (dsa.tage) tage,
         w2.walzen_nr walzen_nr,
        w2.walzen_ng walzen_ng
      from durchlaufzeit_sonder_ag dsa,
           auftrag_arbeitsplan apl,
           walze w2
      where apl.arbeitsgang_nr in
          ( select dsa1.ag ag
            from durchlaufzeit_sonder_ag dsa1
            where dsa1.abteilung = 'TM' )*and apl.auftr_nr = w2.auftr_nr
and apl.auftr_jj = w2.auftr_jj
and apl.auftr_pos = w2.auftr_pos
and apl.auftr_los = w2.auftr_los
and dsa.abteilung = 'TM'
and dsa.ag = apl.arbeitsgang_nr
GROUP BY w2.walzen_nr,
     w2.walzen_ng;
| Id | Operation                       | Name                           | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT                |                                |    21 | 1155 | 4927 |
|   1 | SORT GROUP BY                  |                                |    21 | 1155 | 4927 |
|* 2 |   HASH JOIN                     |                                |    21 | 1155 | 4922 |
|   3 |    NESTED LOOPS                 |                                |   333 | 11655 | 4682 |
|   4 |     NESTED LOOPS                |                                | 16215 |   427K| 4682 |
|   5 |      TABLE ACCESS BY INDEX ROWID| DURCHLAUFZEIT_SONDER_AG        |     4 |    40 |     2 |
|* 6 |       INDEX RANGE SCAN          | DURCHLAUFZEIT_SONDER_AG_INDEX1 |     4 |       |     1 |
|   7 |      TABLE ACCESS BY INDEX ROWID| AUFTRAG_ARBEITSPLAN            | 4054 | 68918 | 1170 |
|* 8 |       INDEX RANGE SCAN          | AUFTRAG_ARBEITSPLAN_IND3       | 4054 |       |     7 |
|* 9 |     INDEX RANGE SCAN            | DURCHLAUFZEIT_SONDER_AG_INDEX2 |     1 |     8 |       |
| 10 |    *TABLE ACCESS FULL*            | WALZE                          | 75432 | 1473K|   239 |
--------------------------------------------------------------------------------------------------When I start the same sql with providing the select from tabel "durchlaufzeit_sonder_ag" by my own the index is used:
select /*+ index(apl(arbeitsgang_nr))*/
       /*+ index(w2 WALZE_IND1)*/
        SUM (dsa.tage) tage,
         w2.walzen_nr walzen_nr,
        w2.walzen_ng walzen_ng
      from durchlaufzeit_sonder_ag dsa,
           auftrag_arbeitsplan apl,
           walze w2
      where apl.arbeitsgang_nr in
                      ( 743, 719, 706, 979 )
and apl.auftr_nr = w2.auftr_nr
and apl.auftr_jj = w2.auftr_jj
and apl.auftr_pos = w2.auftr_pos
and apl.auftr_los = w2.auftr_los
and dsa.abteilung = 'TM'
and dsa.ag = apl.arbeitsgang_nr
GROUP BY w2.walzen_nr,
w2.walzen_ng;
| Id | Operation                        | Name                           | Rows | Bytes | Cost |
|   0 | SELECT STATEMENT                 |                                |     2 |    94 | 1161 |
|   1 | SORT GROUP BY                   |                                |     2 |    94 | 1161 |
|   2 |   TABLE ACCESS BY INDEX ROWID    | WALZE                          |     1 |    20 |     2 |
|   3 |    NESTED LOOPS                  |                                |     2 |    94 | 1156 |
|* 4 |     HASH JOIN                    |                                |    31 |   837 | 1094 |
|   5 |      INLIST ITERATOR             |                                |       |       |       |
|   6 |       TABLE ACCESS BY INDEX ROWID| DURCHLAUFZEIT_SONDER_AG        |     3 |    30 |     2 |
|* 7 |        INDEX RANGE SCAN          | DURCHLAUFZEIT_SONDER_AG_INDEX2 |     3 |       |     1 |
|   8 |      INLIST ITERATOR             |                                |       |       |       |
|   9 |       TABLE ACCESS BY INDEX ROWID| AUFTRAG_ARBEITSPLAN            | 2276 | 38692 | 1091 |
|* 10 |        INDEX RANGE SCAN          | AUFTRAG_ARBEITSPLAN_IND3       | 2276 |       |     8 |
|* 11 |     INDEX RANGE SCAN             | WALZE_IND1                     |     1 |       |     1 |
---------------------------------------------------------------------------------------------------I do not understand this. Why oracle do not use the index (provided in hint) when I select the values from table durchlaufzeit_sonder_ag, but when providing the values by my own, it uses the index?

As far as I am aware only the first hint comment within a given query block is considered.
So these would be valid (provided hint_one is correctly specified)...
SELECT /*+ hint_one hint_two */
       column_name
FROM   table_name;
SELECT /*+
       hint_one
       hint_two
       column_name
FROM   table_name;
SELECT /*+ hint_one
       hint_two */
       column_name
FROM   table_name;
SELECT --+ hint_one hint_two
       column_name
FROM   table_name;But this would not (irrespective of whether hint_one is correctly specified)...
SELECT /*+ hint_one */
       /*+ hint_two */
       column_name
FROM   table_name;Also I don't believe your specification of the INDEX hint is correct, a single set of parenthesis should be used and the table alias and index name should be separated by either a space or comma.
So these would be fine...
SELECT /*+ INDEX (table_alias index_name) */
       column_name
FROM   table_name;
SELECT /*+ INDEX (table_alias, index_name) */
       column_name
FROM   table_name;But this would not...
SELECT /*+ INDEX (table_alias (index_name)) */
       column_name
FROM   table_name;Also you should be aware that an INDEX hint will only be considered provided that a given join order supports it.

Why index is not used if oracle have to do implicit conversion?

my db version: 10gR2
I created bitmap index on each of the column used in below sql.
the datatype of all three columns are VARCHAR2,
while i am using NUMBER in the query, which means oracle needs to do the implicit conversion before running the sql.
the problem is that, when I use NUMBER as below, execution plan will not use bitmap indexes at all.
but when I use STRING instead, it will make use of those bitmap indexes.
select FI_YTD,1,2,FI_KPI_ID
from DM_F_FI_ALL_KPI
where
    FI_KPI_ID=4140
    and FI_PERIOD=201012
    and FI_ORG_ID=10000000;So, I wonder why? how the implicit conversion affects the access path?
Edited by: PhoenixBai on Jan 30, 2011 10:52 AM
Edited by: PhoenixBai on Jan 31, 2011 9:21 AM --added database version as 10gR2

sybrand_b wrote:
Implicit conversion in Oracle is always done like this
empno='10'
is rewritten as
to_char(empno)='10'
Now you have <function>(<indexed columnn>) = <hardcoded literal>
Oracle never puts a conversion function at the right hand side of the expresssion. NEVER.
SQL> create table emp as select * from scott.emp;
Table created.
SQL> alter table emp add constraint emp_pk primary key (empno);
Table altered.
SQL> @desc emp
Name                                      Null?    Type
EMPNO                                     NOT NULL NUMBER(4)
ENAME                                              VARCHAR2(10)
JOB                                                VARCHAR2(9)
MGR                                                NUMBER(4)
HIREDATE                                           DATE
SAL                                                NUMBER(7,2)
COMM                                               NUMBER(7,2)
DEPTNO                                             NUMBER(2)
SQL> select * from emp where empno = '10'
2
SQL> @xplan
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Compatibility is set to 11.2.0.0.0
Plan hash value: 4024650034
| Id | Operation                   | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |        |     1 |    87 |     1   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    87 |     1   (0)| 00:00:01 |
|* 2 |   INDEX UNIQUE SCAN         | EMP_PK |     1 |       |     0   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("EMPNO"=10)Edited by: William Robertson on Jan 30, 2011 12:56 PM - added DESCRIBE

Index was not used in join tables query

I tested the following query on my dev 10g and the explain plan did not indicated to use the index of a(t$trec, t$tdoc)
select a.somecolumns, b.othercolumns
from a, b
where (a.t$trec = 1 or a.t$trec = 4 and t$tdoc = ' ')
and a.t$ttyp = b.t$ityp and a.t$ninv = b.t$idoc
| Id | Operation          | Name         | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |              |   613 | 81529 |   578   (1)| 00:00:07 |
|* 1 | HASH JOIN         |              |   613 | 81529 |   578   (1)| 00:00:07 |
|   2 |   TABLE ACCESS FULL| B            | 2362 |   186K|    32   (0)| 00:00:01 |
|* 3 |   TABLE ACCESS FULL| A            | 9988 |   507K|   545   (1)| 00:00:07 |
-----------------------------------------------------------------------------------t$tdoc = ' ' is NO NULL column with a [space] value when no enter entered.
So why system did not pick up the index?

Because Oracle believes, for any number of possible reasons, that the use of the index would be less efficient.
Force the index usage with a hint and see how Oracle reacts or run a 10053 trace and see why Oracle is making the decision it is making.
Perhaps it is as impressed by a column holding a single space as a placeholder for null as I am. <g>

Index is not used

I have a simple query to select from a huge table and where clause has a function to return a single value like this:
select id from tab where status=get_status(flag);
However, it's doing a full-table scan which cause problem for us. If I replace the function with a value or add a hint, then it's using indexes:
select id from tab where status='L'; or select /*+ index (tab, status) */ id from tab where status=get_status(flat);
What could be the cause of the index not being used in the original query?

I suppose that 'flag' is a column in the table. If so then a full table scan (or full index scan) will probably be the fastest method to get the result.
You could try to create an index on a function like
decode(status,get_status(flag),1,null)and then have
decode(status,get_status(flag),1,null)=1in your where clause.
One peace of warning: if status is NULL and get_status(flag) also is null then this function will 1 and not null.

Index is not using for this query

I have this query and it doesn't use index. Can you put your suggestion please?
SELECT /*+ ORDERED USE_HASH(IC_GSMRELATION) USE_HASH(IC_UTRANCELL) USE_HASH(IC_SECTOR) USE_HASH(bt) */
/* cp */
bt.value value,
bt.tstamp tstamp,
ic_GsmRelation.instance_id instance_id
FROM
xr_scenario_tmp IC_GSMRELATION,
xr_scenario_tmp IC_UTRANCELL,
xr_scenario_tmp IC_SECTOR,
rg_busyhour_tmp bt
WHERE
bt.instance_id != -1
AND (IC_GSMRELATION.entity_id = 133)
AND (IC_GSMRELATION.parentinstance_id = ic_UtranCell.instance_id)
AND (IC_UTRANCELL.entity_id = 254)
AND (IC_UTRANCELL.parentinstance_id = ic_Sector.instance_id)
AND (IC_SECTOR.entity_id = 227)
AND (IC_SECTOR.parentinstance_id = bt.instance_id);
table : xr_scenario_tmp
entity_id          num
instance_id          num
parentinstance_id     num
localkey          varchar
indexes: 1. entity_id+instance_id
     2. entity_id+parentinstance_id
table : rg_busyhour_tmp
instance_id     notnull     num
tstamp          notnull     date
rank          notnumm     num
value               float
index: instance_id+tstamp+rank
thanks

user5797895 wrote:
Thanks for the update
1. I don't understand where to put {}. you meant in the forum page like below
Use the tag. Read the [FAQ|http://wiki.oracle.com/page/Oracle+Discussion+Forums+FAQ?t=anon] for more information. It's the link on the top right corner.
>
2. AROUND 8000 IN DEV MACHINE. BUT 1.5M IN PRODUCTION
It's a more or less useless exercise if you have that vast difference between the two systems. You need to test this thoroughly using a similar amount of data.
3.
Note: cpu costing is off, PLAN_TABLE' is old version
You need to re-create your PLAN_TABLE. That's the reason why important information is missing from your plans. It's the so called "Predicate Information" section below the execution plan and it requires the correct version of the plan table. Drop your current plan table and re-run in SQL*Plus on the server:
@?/rdbms/admin/utlxplan
to re-create the plan table.
Dynamic sampling doesn't alter the plan in any way no matter what sampling level I choose.
When I added Cardinality it switched from 1 full table scan and 2 index read
Can you post the statements with the hints included resp. just the first line including the hints used for the different attempts?
# WITH dbms_stats.gather_table_stats, without cardinality it uses indexes all the time.
How did you call DBMS_STATS.GATHER_TABLE_STATS, i.e. which parameter values where you using?
# After deleting the table stats performance improved back
All these different attempts are not really helpful if you don't say which of them was more effective than the other ones. That's why I'm asking for the "Predicate Information" section so that this information can be used to determine which of your tables might benefit from an indexed access path and which don't.
As already mentioned several times if you use SQL tracing as described in one of the links provided you could see which operation produces how many rows. This would allow to determine if it is efficient or not.
But given that you're doing all this with your test data it doesn't say much about the performance in your production environment.
4. whether GTT created with "ON COMMIT PRESERVE ROWS"?
YES - BUT DIFFERENT SESSIONS HAS DIFFERENT NUMBER OF ROWS
The question is, whether the number of rows differs significantly, if yes, then you shouldn't use the DBMS_STATS approach
5. neigher (48 sec. / 25 sec. run time) are sufficient, then what is the expected?
ACTUALLY I AM DOING IT IN DEVELOPMENT MACHINVE. IN PRODUCTION THE NUMBER OF ROWS ARE DIFFERENT. LAST TIME WHEN WE RELEASED THE
PATCH WITH THIS CODE, THE PERFORMANCE WAS BAD.
See 2., you need to have a suitable test environment. It's a more or less useless exercise if you only have a fraction of the actual amount of data.
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/

Performance Issue - Index is not used when a zero padded string is queried

Hi All,
I have a table T1 which has many columns. One such column say C1 is a varchar2(20). T1 has 10 million rows and there is an index called I1 on C1. Stats are current for both tables and indexes. These are the scenarios:
Scenario 1
select *   from T1 where C1 = '0013206263' --Uses index I1
187 ms
Scenario 2
select *   from T1 where C1 = '8177341863' --Uses index I1
203 ms
*Scenario 3*
*select *   from T1 where C1 = '0000000945' --Uses Fulll Table Scan --Very Slow*
*45 seconds*
When I force the sql to use the index through a hint, it is working fine:
Scenario 4
select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '0013206263' --Uses index I1
123 ms
Scenario 5
select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '8177341863' --Uses index I1
201 ms
*Scenario 6*
*select /*+ INDEX (t1 i1) */ *   from T1 where C1 = '0000000945' --Uses index I1*
*172ms*Is there any reason for this performance issue? Why does the optimizer goes for FTS in Scenario 3?
Edited by: user539954 on May 14, 2009 12:22 PM
Edited by: user539954 on May 14, 2009 12:32 PM

user539954 wrote:
Please see the replies below:
- How many distinct values for C1 out of that 10 million rows? I'm guessing that histograms were created for C1, correct?
=>7 million distinct c1 values. I have not gathered a histogram yet. Should I try that?
SQL> explain plan for select * from T1 where C1 = '0000000954';
| Id | Operation         | Name           | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT |                |   244K|    19M| 26228   (5)|
|   1 | TABLE ACCESS FULL| T1 |   244K|    19M| 26228   (5)|
SQL> explain plan for select * from T1 where C1 = '0033454555';
| Id | Operation                   | Name               | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT            |                    |   532 | 43624 |   261   (0)|
|   1 | TABLE ACCESS BY INDEX ROWID| T1     |   532 | 43624 |   261   (0)|
|   2 |   INDEX RANGE SCAN          | I1 |   532 |       |     2   (0)|
It's possible you do have a histogram, even though you didn't plan on creating it, if you're running 10g.
In the absence of a histogram and with 7M distinct keys in 10M rows, Oracle should have predicted 2 rows for both queries, not 244,000 and 532.
If you do have a histogram, you probably need to get rid of it.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.

Optimize double max queries, index plan not used.

Hi,
In my 9.2.0.8 I've got test case like :
create table t (id1 number ,id2 number) ;
begin
for i in 1 .. 1000000
loop
     insert into t values(i, i+10);
end loop;
end;
create index id1 on t(id1) ;
create index id2 on t(id2);
exec dbms_stats.gather_table_stats(user, 'T', cascade => true);
set autotrace traceonly
select max(id1), max(id2) from t;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=127 Card=1 Bytes=9)
   1    0   SORT (AGGREGATE)
   2    1     TABLE ACCESS (FULL) OF 'T' (Cost=127 Card=1000000 Bytes=9000000)
Statistics
          0 recursive calls
          0 db block gets
       2068 consistent gets
          0 physical reads
          0 redo size
        232 bytes sent via SQL*Net to client
        238 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
whereas
SQL> select max(id1) from t;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=127 Card=1 Bytes=5)
   1    0   SORT (AGGREGATE)
   2    1     INDEX (FULL SCAN (MIN/MAX)) OF 'ID1' (NON-UNIQUE) (Cost=127 Card=1000000 Bytes=5000000)
Statistics
          0 recursive calls
          0 db block gets
          3 consistent gets
          1 physical reads
          0 redo size
        211 bytes sent via SQL*Net to client
        238 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processed
SQL> select max(id2) from t;
Execution Plan
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=127 Card=1 Bytes=5)
   1    0   SORT (AGGREGATE)
   2    1     INDEX (FULL SCAN (MIN/MAX)) OF 'ID2' (NON-UNIQUE) (Cost=127 Card=1000000 Bytes=5000000)
Statistics
          0 recursive calls
          0 db block gets
          3 consistent gets
          1 physical reads
          0 redo size
        214 bytes sent via SQL*Net to client
        238 bytes received via SQL*Net from client
          2 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          1 rows processedSo, why Oracle cant use both indexes to do optimal index min/max scan ?
How to rewrite that query ?
Regards
GregG

Hi,
Does this help,
with
p
as
(select max(id1)
from t),
q as
(select max(id2)
from t )
select * from p,qRegards,
CKLP

Index not using in select query

Hello All,
I have table CITY with 2 composite primary key CITYCODE, COUNTRYCODE of course they are NOT NULL.
i created an index.
CREATE UNIQUE INDEX CITYKEY ON CITY     (CITYCODE, COUNTRYCODE);
then i run explain plan as follows
explain plan for
select CityCode, CityName, CountryCode, LexiconId, UserId, Status
from City
where CountryCode = 'IR';
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 803 | 57013 | 112 (2)| 00:00:02 |
|* 1 | TABLE ACCESS FULL| CITY | 803 | 57013 | 112 (2)| 00:00:02 |
later i analyze table rebuild indexes but again explain plan gives me the same result.
Could any 1 please guide me to solve this issue.
Thanks
Edited by: mohsin javed on Feb 17, 2011 10:10 AM

Hello All,
Again with one more query which having join:
table SDNMASTER with sdnid pk and SDNMASTER_PK index on SDNID, table SDNALIAS sdnid pk and SDNALIAS_PK index on SDNID.
explain plan for
SELECT a.SourceId,
          a.SourceName,
          b.LastName,
          a.Status
FROM SdnMaster a,
          SdnAlias b
WHERE a.SdnId = b.SdnId
AND a.Status in ('1', '3')
AND b.LastName is not null
ORDER BY b.LastName;
PLAN_TABLE_OUTPUT
Plan hash value: 1153036645
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2399 | 64773 | 69 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 2399 | 64773 | 69 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 2399 | 64773 | 68 (3)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| SDNALIAS | 2399 | 21591 | 11 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL| SDNMASTER | 4562 | 82116 | 56 (2)| 00:00:01 |
Even after analyzing table and rebuilding index its not using the index..
Thanks

Indexes not used in Oracle 8i

Hi Everybody,
Does anybody know how can i know which indexes are not used in our Oracle 8iR3 Database.
We need to purge as soon as possible all indexes not used
in our Datawarehousing system because they're growing and growing.
I know there's some mechanism in Oracle 9i to query which are unused is it possible to simulate something similar?
Kind regards and thank you in advance.
José Luis Pérez
[email protected]

Are you asking about index monitoring in 8i? One way (and there aren't very many at all) of doing this is to collect (query them out of the DD) execution plans and scan those for index usage.

Query on virtual column that is defined in XMLIndex does not use the index

Hello,
I am facing an issue in executing queries on a virtual column that is defined in an XMLIndex: it appears as if the index is not used.
Database details:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE 11.2.0.3.0 Production
TNS for 64-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
For this use case the XML documents adhere to the following XSD and are stored in an XMLType column in a table:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="http://a_name_space/v1"
    targetNamespace="http://a_name_space/v1"
    elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0">
    <xsd:element name="fields">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="field" maxOccurs="unbounded">
                    <xsd:complexType>
                        <xsd:choice>
                            <xsd:element name="value" minOccurs="1" maxOccurs="1">
                                <xsd:complexType>
                                    <xsd:simpleContent>
                                        <xsd:extension base="notEmptyString4000Type"/>
                                    </xsd:simpleContent>
                                </xsd:complexType>
                            </xsd:element>
                            <xsd:element name="values" minOccurs="1" maxOccurs="1">
                                <xsd:complexType>
                                    <xsd:sequence>
                                        <xsd:element name="value" minOccurs="1" maxOccurs="1">
                                            <xsd:complexType>
                                                <xsd:simpleContent>
                                                    <xsd:extension base="notEmptyString4000Type">
                                                        <xsd:attribute name="startDate" type="xsd:date" use="required"/>
                                                        <xsd:attribute name="endDate" type="xsd:date" />
                                                    </xsd:extension>
                                                </xsd:simpleContent>
                                            </xsd:complexType>
                                        </xsd:element>
                                    </xsd:sequence>
                                </xsd:complexType>
                            </xsd:element>
                        </xsd:choice>
                        <xsd:attribute name="name" type="string30Type" use="required"/>
                        <xsd:attribute name="type" type="dataType" use="required"/>
                    </xsd:complexType>
                </xsd:element>
            </xsd:sequence>
        </xsd:complexType>
    </xsd:element>
    <xsd:simpleType name="dataType">
        <xsd:annotation>
            <xsd:documentation>Char, Date, Number</xsd:documentation>
        </xsd:annotation>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="C"/>
            <xsd:enumeration value="D"/>
            <xsd:enumeration value="N"/>
        </xsd:restriction>
    </xsd:simpleType>
    <xsd:simpleType name="string30Type">
        <xsd:restriction base="xsd:string">
            <xsd:maxLength value="30"/>
        </xsd:restriction>
    </xsd:simpleType>
    <xsd:simpleType name="notEmptyString4000Type">
        <xsd:restriction base="xsd:string">
            <xsd:maxLength value="4000"/>
            <xsd:pattern value=".+"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:schema>A field can have a single value as well as multiple values.
The XMLIndex is defined as follows:
CREATE INDEX test_xmltype_idx ON test_xmltype (additional_fields) INDEXTYPE IS XDB.XMLIndex
PARAMETERS
XMLTable dt_fld_tab (TABLESPACE "TAB_SPACE" COMPRESS FOR OLTP) ''fields/field''
COLUMNS
name varchar2(30 char) PATH ''@name''
,dataType varchar2(1 char) PATH ''@type''
,val varchar2(4000 char) PATH ''value/text()''
,vals XMLType PATH ''values/value'' VIRTUAL
XMLTable dt_fld_multi_value_tab (TABLESPACE "TAB_SPACE" COMPRESS FOR OLTP) ''value'' passing vals
COLUMNS
val varchar2(4000) PATH ''text()''
,startDate varchar2(30 char) PATH ''@startDate''
,endDate varchar2(30 char) PATH ''@endDate''
');The following b-tree indexes are defined:
create index dt_field_name_idx on dt_fld_tab (name);
create index dt_field_value_idx on dt_fld_tab (val);
create index dt_field_values_idx on dt_fld_multi_value_tab (val);And stats are properly computed before the queries are executed:
call dbms_stats.gather_table_stats(user, 'test_xmltype', estimate_percent => null);Queries for single values are cost efficient and fast. With 600K rows in the table these return with 0.002 seconds.
Queries for multi-valued fields / elements are not though, these result in a full table scan.
Sample XML snippet:
<fields>
<field name="multiVal" type="C">
    <values>
      <value startDate="2013-01-01" endDate="2013-01-01">100</value>
      <value startDate="2014-01-01">120</value>
    </values>
</field>
</fields>Examples of costly and slow queries:
select id from test_xmltype
where xmlexists('/fields/field/@name="multiVal"' passing additional_fields)
and xmlexists('/fields/field/values/value[@startDate="2013-01-01"]' passing additional_fields)
and xmlexists('/fields/field/values/value[text()="100"]' passing additional_fields)
select id from test_xmltype
where xmlexists('/fields/field/@name="multiVal"' passing additional_fields)
and xmlexists('/fields/field/values/value[@startDate="2013-01-01" and .="100"]' passing additional_fields);Whereas the following query on the multi valued field is fast:
select id from test_xmltype
where xmlexists('/fields/field/@name="multiVal"' passing additional_fields)
and xmlexists('/fields/field/values/value[@startDate="2013-01-01"]' passing additional_fields);For the XPath /fields/field/values/value[@startDate="2013-01-01"] the index is used.
Suspected cause: XPath issue for the value of a multi valued field, e.g. /fields/field/values/value[text()="aValue"].
Any hints are appreciated: what am I overlooking here?
Thanks in advance,
-Sjoerd
Edited by: user615230 on May 27, 2013 7:46 AM

Hello,
This is using binary XML. The table creation script is:
create table test_xmltype
(id number(14,0) not null primary key
,member_code varchar2(30 char) not null
,period_code varchar2(30 char) not null
,amount number(12,2) not null
,additional_fields xmltype
);The schema is not registered in the database. Is that required? It is primarily used to generate Java classes that will be used in order to construct the XML documents.
And you are right: for our initial investigation the sample XML documents are generated with a PLSQL routine and do not contain namespaces. But for the single valued fields there are also no namespaces and the queries on these are executed with very satisfactory plans.
Thanks for the swift reply.
-Sjoerd

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

Index not used

Hello all,
I have a large table (20 million rows) partitioned by date (2 million rows/part) that includes an hour column. The hour data is stored in the '99' format as we only have 24 values/day. However the client wants the data displayed as '9999' so we created a set of views that display the data as hour||'00'. Our base table unique index includes the hour column, but now all the queries are seen by the database as where hour ='1100' as oposed to where hour='11' and the index is not used any more. How can we tell the optimizer that the '1100' that the client is selecting through the web views is actually our '11' that is stored in the already existing index?
Please note that I would like to avoid having to create a function index. The existing index already takes 1.3Gb, don't wnt to spend another 1.3 Gb.
Thank you very much,

Your description doesn't quite compute.
Access to rows in the WHERE clause has no relationship to what is displayed from the SELECT clause of a view. You may want to post the DDL and DML to explain how this is happening.

Index in not used

Similar Messages

Maybe you are looking for