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

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

  • 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 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.

  • 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.

  • How to find BEx queries that were not used along with no of times executed

    Hi SDN,
    I need build a query which shows the BEx reports that were not used and also the number times the query was executed.
    I built the query on "multiprovider 0TCT_MC01" in which I used the KF "0TCTQUCOUNT" then the query is not capturing this information, while executing from Portal. ( as stated in /thread/716593 [original link is broken]).
    If anybosy happen to know the solution please share.
    Also
    as stated in this link (BW 3.5 Statistics - User Hits)
    Is there any infoobject which has the exact functionality as of the "0TCTNAVCTR" of 0BWTC_C02 (we can not use 0BWTC_C02 as we are in BW 7 SP16).
    I think it is very well known issue but there is not any exact solution to it if anybody finds the solution please update this points will be assigned
    Thank you,
    Prasaad
    Edited by: Prasaadbw on Mar 18, 2010 2:01 PM

    Hi,
    Try from one of these tables RSZRANGE, RSZELTXREF,
    RSZELTTXT,RSRREPDIR,RSZSELECT,RSZCOMPDIR.
    There is a field 'Last Used'.
    You can get some info when Query was used last
    -Vikram

  • 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.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • 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 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/                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • 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.

  • 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

  • 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.

  • Bitmap Index Not Used in PROD and used in DEV

    I am in a situation where in in DEV Bitmap Index is used and in PROD bitmap Index is not used. I checked the count, in PROD I have 10 mil rows and in DEV I have 16 mil rows. Optimizer is CHOOSE and also when I tried to force to use index in PROD, I got higher cost.
    Any suggestions why Index is not used in PROD as opposed to DEV

    As other says, no guarantee that the same query with same setting OS, ORACLE to produce the same execution plan. Also, as Justin said, dont every take cost as your tuning parameter, pay attention to response time, also, number of logical reads and physical reads. What are the wait events during?
    For an index, most important factors are, blevel, clustering_factor, number of distinct values. Clustering actor make a lot of difference. You said, when you force index to use, your performance has gained. If so, why not, why the HINTS there in place? Go ahed and use it, but, after all the R&D. Are the Optimizer* paraemters same on the both databases?
    If possible, post the execution plan of the query, with HINT and without HINT as well.
    Jaffar

  • 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.

Maybe you are looking for