11g R2 optimizer is not using indexes

I have the table named OPT_TEST in my database 11g R2.
There is an index on the ename column of the table above.
11g does not use this index when I ask above table on the basis of the ename column.

SQL > select count (*) in the opt_test;

COUNT (*)
----------
851969

SQL > select count (*) in the opt_test where ename = 'KING '.

COUNT (*)
----------
1

SQL > exec dbms_stats.gather_table_stats ('SCOTT', 'OPT_TEST', method_opt = > 'for all columns size skewonly');

SQL > explain plan for select * from opt_test where ename = 'KING '.

He explained.

SQL > select parent_id, operation, options, object_name, id, io_cost from plan_table;

ID PARENT_ID OPERATION OPTIONS OBJECT_NAME IO_COST
---------- ---------- ------------------------------ ------------------------------ ------------------------------ ----------
0 SELECT STATEMENT 1365
1 0 TABLE ACCESS FULL OPT_TEST 1365


There is on one employee with the name 'KING' in the OPT_TEST table.
I have also generated stats on the table and the index but still optimizer makes complete analysis.

user8916506 wrote:

SQL> select count(distinct ename) from opt_test ;

COUNT(DISTINCTENAME)
--------------------
14

SQL> select ename,count(*) from opt_test  group by ename;

ENAME        COUNT(*)
---------- ----------
ALLEN           65536
JONES           65536
FORD            65536
CLARK           65536
MILLER          65536
SMITH           65536
WARD            65536
MARTIN          65536
SCOTT           65536
TURNER          65536
ADAMS           65536
BLAKE           65536
KING                1
JAMES           65536

14 rows selected.

The answer is b - I thought of:
You enabled Oracle to make a sample auto size, and he stopped on a very small sample because he thought that he had obtained a stable result. But he has never seen the line after line with KING. Therefore, when you query for KING oracle saw "not in the histogram. For versions of Oracle 10.2.0.3 beyond estimation is then "half the number of lines for the least popular value', which comes to 32 768.

Concerning
Jonathan Lewis

Tags: Database

Similar Questions

  • Setting the query: optimizer does not use the index function

    Hello

    I have a request written by a developer that I can't change.

    It is here that the condition:

    (   UPPER(TRIM (CODFSC)) = UPPER (TRIM ( '01923980500'))

           OR UPPER(TRIM (CODUIC)) = UPPER (TRIM ( '01923980500')))

    There is an index on CODFSC and on CODUIC1.

    the plan is:

    Plan

    INSTRUCTION SELECT ALL_ROWS cost: 9 194 bytes: 3 206 502 cardinality: 15 054

    ACCESS FULL ANAGRAFICA cost TABLE TABLE 1: 9 194 bytes: 3 206 502 cardinality: 15 054

    So I created two new index on SUPERIOR (TRIM ()CODFSC)) and SUPERIOR (TRIM ()CODUIC)) but the plan

    complete analysis of STIL.

    Modifing where condition in:

    (   CODFSC = UPPER (TRIM ( '01923980500'))

           OR CODUIC = UPPER (TRIM ( '01923980500')))

    the plan is:

    SELECT STATEMENT ALL_ROWSCost: 157 bytes: 426 cardinality: 2

    CONCATENATION OF 5

    TABLE ACCESS BY INDEX ROWID ANAGRAFICA cost TABLE 2: cardinality of 5 bytes: 213: 1

    1 INDEX RANGE SCAN INDEX ANAGRAFICA_IDX01 cost: cardinality 3: 1

    TABLE ACCESS BY INDEX ROWID ANAGRAFICA cost TABLE 4: cardinality 152 bytes: 213: 1

    3 INDEX SKIP SCAN INDEX ANAGRAFICA_IDX02 cost: cardinality 1: 151

    Why optimizer not use my funct index?

    Thank you.

    Franck,

    I always forget that the default value for the GOLD expansion depends on a path indexed for each branch.

    2 in your use of or_predicates (2) depends on the position of complex predicate which must be expanded.  If you change the order of predicate 'State = 0' to display AFTER the complex predicate, you must change the indicator of "or_predicates (1).

    Outside of the current state of undocumented indicator, it also introduces the disturbing thought that, for a more complex query, a change in the transformation may result in another set of query blocks generated with a different ranking of the predicates. Yet another case to ensure that if you suggest anything suggest you (or create a SQL database).

    Concerning

    Jonathan Lewis

  • Optimizer not use indexes even after giving the indication

    Hi all

    I wonder why the Optimixzer does not use the index in the query below
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
    
    
    SQL> select column_expression
      2  from ALL_IND_EXPRESSIONS
      3  where table_name like 'GTXN_DTL_V1'
      4  and index_name = 'IDX_TXN11_V1';
    
    COLUMN_EXPRESSION
    -----------------------------------------
    TO_DATE("BOOKING_DATE",'YYYYMMDD')
    
    SQL> select num_rows from all_tables
      2  where table_name like 'GTXN_DTL_V1';
    
      NUM_ROWS
    ----------
      29020867
    
    SQL>  explain plan for select * from gtxn_dtl_v1 where to_date(booking_date,'yyyymmdd') = to_date('030109','DDMMRR');
    
    Explained.
    
    SQL> select * from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    -------------------------------------------------------------------------------------------
    Plan hash value: 3140624094
    
    ---------------------------------------------------------------------------------
    | Id  | Operation         | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT  |             | 55489 |    15M|   215K  (4)| 00:43:08 |
    |*  1 |  TABLE ACCESS FULL| GTXN_DTL_V1 | 55489 |    15M|   215K  (4)| 00:43:08 |
    ---------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       1 - filter(TO_DATE("BOOKING_DATE",'yyyymmdd')=TO_DATE('030109','DDMMRR
                  '))
    
    14 rows selected.
    
    --Giving Hint..
    
    SQL> explain plan for select /*+ index(gtxn_dtl_v1 IDX_TXN11_V1) */ *
      2  from gtxn_dtl_v1
      3  where to_date(booking_date,'yyyymmdd') = to_date('030109','DDMMRR')
      4  /
    
    Explained.
    
    SQL> select * from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    ------------------------------------------------------------------------------------------
    Plan hash value: 3140624094
    
    ---------------------------------------------------------------------------------
    | Id  | Operation         | Name        | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT  |             | 55489 |    15M|   215K  (4)| 00:43:08 |
    |*  1 |  TABLE ACCESS FULL| GTXN_DTL_V1 | 55489 |    15M|   215K  (4)| 00:43:08 |
    ---------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       1 - filter(TO_DATE("BOOKING_DATE",'yyyymmdd')=TO_DATE('030109','DDMMRR
                  '))
    
    14 rows selected.
    Please suggest.

    Thanks in advance,
    Jac

    Hello
    you have created the index with uppercase letters (YYYYMMDD), but you try to run the query with small letters (YYYYMMDD), while acceptable with the name of the column it is not acceptable with a part of the function of the order of the function.

    Yuri

  • SQL not using indexes at runtime, but by using the index in "explain plan".

    Hi all

    I am facing a problem here that I don't get to think.

    I have a SQL that makes a FULL ACCESS of TABLE into two tables and its costs are very high, but it occurs only when I run it in my program (I saw it in the session trace). If I do a "explain plan" sqlplus (SQL Navigator or PLSQL Developer) it shows that he use indexes and have a low cost. I already checked the statistics from both tables, and they are up to date.

    Did someone never facing a similar problem or knows something I can do to find my problem?

    Thank you all very much.

    Hello

    As far as I KNOW, optimizer Oracle never guarantees that an Index scan in query explain plan will be necessarily used during query execution.

    ORACLE-BASE - DBMS_XPLAN: Oracle display execution Plans

    Could you please read the above, run the query, as described and check the execution using DBMS_XPLAN plan. The cursor cache DISPLAY_CURSOR and not PLAN_TABLEs.

  • View does not use index Mview underlying but mview uses indexes

    Hello

    I faced a situation where, while querying data to display based on mview does not use the index, but when we wonder of mview it uses index and produce quick results.

    Here are the details:

    
    querying from view: (completes in more than a minute even after passing hint)
    ================================
    explain plan for select /*+ index(  ITGI_CREDITOR_LEDGER_CMV ITGI_CREDITOR_LEDGER_INDX) */ * from CR_LEDGER_REP_V where vendor_id='1474911';
    
    Plan hash value: 463951623
    
    ---------------------------------------------------------------------------------------------------
    | Id  | Operation              | Name                     | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT       |                          |  9056K|  5648M| 97644   (1)| 00:00:04 |
    |*  1 |  VIEW                  | CR_LEDGER_REP_V          |  9056K|  5648M| 97644   (1)| 00:00:04 |
    |   2 |   COUNT                |                          |       |       |            |          |
    |   3 |    MAT_VIEW ACCESS FULL| ITGI_CREDITOR_LEDGER_CMV |  9056K|  2159M| 97644   (1)| 00:00:04 |
    ---------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       1 - filter("VENDOR_ID"=1474911)
    
    
    
    Querying from mview: (completes within a second)
    ==============================
    
    explain plan for select /*+ index(  ITGI_CREDITOR_LEDGER_CMV ITGI_CREDITOR_LEDGER_INDX) */ * from ITGI_CREDITOR_LEDGER_CMV where vendor_id='1474911';
    
    
    Plan hash value: 1726512073
    
    --------------------------------------------------------------------------------------------------------------------
    | Id  | Operation                              | Name                      | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT                       |                           |    21 |  5880 |    21   (0)| 00:00:01 |
    |   1 |  MAT_VIEW ACCESS BY INDEX ROWID BATCHED| ITGI_CREDITOR_LEDGER_CMV  |    21 |  5880 |    21   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN                     | ITGI_CREDITOR_LEDGER_INDX |    22 |       |     3   (0)| 00:00:01 |
    --------------------------------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("VENDOR_ID"=1474911)
    
    
    
    View DDL
    ========================
    
    CREATE OR REPLACE FORCE VIEW SANJAY.CR_LEDGER_REP_V
    (
       QRY,
       SR_NO,
       VENDOR_ID,
       VENDOR_TYPE,
       VENDOR_NUMBER,
       VENDOR_NAME,
       VENDOR_SITE_ID,
       VENDOR_SITE_CODE,
       GL_DATE,
       ACCOUNTING_DATE,
       PO,
       INVOICE_TYPE,
       AP_INVOICE_NO,
       INVOICE_DOC_CAT,
       AP_INVOICE_DATE,
       INVOICE_VOUCHER_NO,
       PAYMENT_VOUCHER_NO,
       CHQ_NO,
       DESCRIPTION,
       PAYMENT_DATE,
       ACC_CODE,
       PAYMENT_METHOD,
       CURR_CODE,
       DEBIT,
       CREDIT
    )
    AS
       SELECT qry,
              ROWNUM srn,
              vendor_id,
              vendor_type_lookup_code,
              vendor_no,
              vendor_name,
              vendor_site_id,
              vendor_site_code,
              gl_date,
              accounting_date,
              po_distribution_id,
              invoice_type_lookup_code,
              invoice_num,
              doc_category_code,
              invoice_date,
              inv_voucher_num,
              payment_num,
              check_number,
              description,
              pay_accounting_date,
              account_code,
              payment_method_code,
              invoice_currency_code,
              debit,
              credit
         FROM sanjay.itgi_creditor_ledger_cmv;
    
    
    
    

    The plan does not change even if I do not use advice.

    Although I said developer to use mview directly, but I did not understand this behavior.

    DB version: 12.1

    OPERATING SYSTEM: AIX 6.1

    Kind regards

    Gerard

    Note that the query on the view plan is only to apply your filter predicates on line 1, rather than against the mview in line 3. Line 2 said you that enforcement must correspond to a kind of County before it can filter which is due to the virtual rownum in your point of view.

    You need this column? In my opinion, it's meaningless. Remove the column from the view would mean that the view doesn't have to be assessed in its entirety (if not, how it will calculate rownums?) before allowing you to filter. You asked the developer to implement the work is likely to come with a different value of sr_no (if the developer is even using it?) than what he would have obtained by using the view.

    The column tries to catch a unique key for the view? Are you aware that rownum values can and will change between requests to the same table as the order lines are selected is not guaranteed. If the column is actually useful (and it is correct to calculate at this level) you then could it sense it is calculated inside the mview? This means that you can only refresh the mview completely and rownum values can (and will) only change on refresh.

  • Query is not using indexes

    Hello
    I wonder if there is a way to make my query to use an index without specifying the INDEX indicator.

    Thank you
    Laurent

    PS: I'm using 9.2.0.8
    SQL> create table lsc_t1(a number primary key, b number);
    
    Table created.
    
    SQL> create table lsc_t2(a number primary key, b number);
    
    Table created.
    
    SQL> create table lsc_t3(a number primary key, b number);
    
    Table created.
    
    SQL> insert into lsc_t1(a,b) select rownum, dbms_random.value from dual connect by level<10000;
    
    9999 rows created.
    
    SQL> insert into lsc_t2(a,b) select rownum, dbms_random.value from dual connect by level<1000;
    
    999 rows created.
    
    SQL> insert into lsc_t3(a,b) select rownum, dbms_random.value from dual connect by level<1000;
    
    999 rows created.
    
    SQL> commit;
    
    Commit complete.
    
    SQL> begin
      2    dbms_stats.gather_table_stats(user,'LSC_T1');
      3    dbms_stats.gather_table_stats(user,'LSC_T2');
      4    dbms_stats.gather_table_stats(user,'LSC_T3');
      5  end;
      6  /
    
    PL/SQL procedure successfully completed.
    
    SQL> set timi on
    SQL> select --+ INDEX(lsc_t1)
      2    * from lsc_t1
      3  where a in (select a from lsc_t2 where b<.01 union all select a from lsc_t3 where b<.01);
    
             A          B
    ---------- ----------
           140 .138460932
           161 .928661302
           281 .830010122
           440 .071851157
           443 .355640404
           516 .791276412
           598 .508219846
           600 .158621147
           643 .748363911
           747 .777346635
           836 .390349029
           869 .292453677
           874 .914353702
           881 .930301092
    
    14 rows selected.
    
    Elapsed: 00:00:00.03
    SQL> select
      2    * from lsc_t1
      3  where a in (select a from lsc_t2 where b<.01 union all select a from lsc_t3 where b<.01);
    
             A          B
    ---------- ----------
           140 .138460932
           161 .928661302
           281 .830010122
           440 .071851157
           443 .355640404
           516 .791276412
           598 .508219846
           600 .158621147
           643 .748363911
           747 .777346635
           836 .390349029
           869 .292453677
           874 .914353702
           881 .930301092
    
    14 rows selected.
    
    Elapsed: 00:00:00.26
    SQL> set timi off autot trace exp
    SQL> select --+ INDEX(lsc_t1)
      2    * from lsc_t1
      3  where a in (select a from lsc_t2 where b<.01 union all select a from lsc_t3 where b<.01);
    
    Execution Plan
    ----------------------------------------------------------
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=19 Card=17 Bytes=476)
       1    0   NESTED LOOPS (Cost=19 Card=17 Bytes=476)
       2    1     VIEW OF 'VW_NSO_1' (Cost=2 Card=17 Bytes=68)
       3    2       SORT (UNIQUE)
       4    3         UNION-ALL
       5    4           TABLE ACCESS (FULL) OF 'LSC_T2' (Cost=2 Card=9 Bytes=216)
       6    4           TABLE ACCESS (FULL) OF 'LSC_T3' (Cost=2 Card=8 Bytes=192)
       7    1     TABLE ACCESS (BY INDEX ROWID) OF 'LSC_T1' (Cost=1 Card=1 Bytes=24)
       8    7       INDEX (UNIQUE SCAN) OF 'SYS_C001186489' (UNIQUE)
    
    
    
    SQL> select
      2    * from lsc_t1
      3  where a in (select a from lsc_t2 where b<.01 union all select a from lsc_t3 where b<.01);
    
    Execution Plan
    ----------------------------------------------------------
       0      SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=17 Bytes=476)
       1    0   NESTED LOOPS (Cost=6 Card=17 Bytes=476)
       2    1     TABLE ACCESS (FULL) OF 'LSC_T1' (Cost=6 Card=9999 Bytes=239976)
       3    1     VIEW OF 'VW_NSO_1'
       4    3       SORT (UNIQUE)
       5    4         UNION-ALL (PARTITION)
       6    5           TABLE ACCESS (BY INDEX ROWID) OF 'LSC_T2' (Cost=2 Card=1 Bytes=24)
       7    6             INDEX (UNIQUE SCAN) OF 'SYS_C001186490' (UNIQUE) (Cost=1 Card=1)
       8    5           TABLE ACCESS (BY INDEX ROWID) OF 'LSC_T3' (Cost=2 Card=1 Bytes=24)
       9    8             INDEX (UNIQUE SCAN) OF 'SYS_C001186491' (UNIQUE) (Cost=1 Card=1)

    Laurent,

    If check you my post carefully, you'll notice that the rewrite "is" using the filter outside the "union all" condition generates a plan that is - though not identical due to the operation "UNIQUE SORT" being outside instead of inside the definition of the view - point of view 'execution', 'equality' from my point of view. Please let me know if you think that this is not the case.

    Kind regards
    Randolf

    Oracle related blog stuff:
    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/

    Published by: Randolf Geist Sep 22, 2008 10:09

    Solution of Tubby is not due to the execution of the sort after the LOOP IMBRIQUEE

  • SQL, not not using index on a partitioned table

    I partitioned table that has rows over 15 million
    I have a query that selects records based on the flag = 1
    There are only 2 possible values for the flag, it is 0 or 1
    I tried two index and local bitmap index on this field.
    The query always uses full table scan
    any suggestions?

    Assuming that you have an index

    CREATE INDEX idx_maint_chg_flag
       ON a_maintenance( CASE WHEN record_changed = 1 THEN 1 ELSE NULL END);
    

    your request would be

    SELECT *
      FROM a_maintenance
     WHERE (CASE WHEN record_changed = 1 THEN 1 ELSE NULL END) = 1
    

    Of course, it may be easier to follow if you create a function is_record_changed

    CREATE FUNCTION is_record_changed( p_flag NUMBER )
      RETURN NUMBER
    IS
    BEGIN
      IF( p_flag = 1 )
      THEN
        RETURN p_flag;
      ELSE
        RETURN NULL;
      END IF;
    END;
    

    create an index on this function

    CREATE INDEX idx_maint_chg_flag
       ON a_maintenance( is_record_changed( record_changed ) );
    

    and use this function in your query

    SELECT *
      FROM a_maintenance
     WHERE is_record_changed( record_changed ) = 1
    

    Justin

  • Index is not used, although suspicion.

    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     TM
    When I use a select statement like that 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 run the same sql to the delivery of the selection from tabel 'durchlaufzeit_sonder_ag' by my own 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 don't understand this. Why oracle do not use index (provided in the indicator) when I select the values in the durchlaufzeit_sonder_ag table, but when they provide my own values, it uses the index?

    As far as I know only the first comment of suspicion in a given query block is considered.

    So it would be valid (unless hint_one is specified correctly)...

    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 should not (regardless of if hint_one is specified correctly)...

    SELECT /*+ hint_one */
           /*+ hint_two */
           column_name
    FROM   table_name;
    

    Also I do not believe your INDEX index specification is correct, a single set of brackets should be used and the alias name and index table must be separated by a space or a comma.

    So it would be nice...

    SELECT /*+ INDEX (table_alias index_name) */
           column_name
    FROM   table_name;
    
    SELECT /*+ INDEX (table_alias, index_name) */
           column_name
    FROM   table_name;
    

    But it would not...

    SELECT /*+ INDEX (table_alias (index_name)) */
           column_name
    FROM   table_name;
    

    Also, you should be aware that an INDEX indicator is only considered provided that supports a given join order.

  • FBI and XMLINDEX not use by the optimizer

    Hello

    I've created a function based index but optimizer is never using my index and found for BINARYXML FBI is not suggested rather THAN XMLINDEX is good, it seems does not work for me, but even.

    I tried to use tips but doesn't help me at all. Any suggestions would be really useful.

    SQL > show parameter index

    VALUE OF TYPE NAME
    ------------------------------------ ----------- ------------------------------
    optimizer_index_caching integer 0
    OPTIMIZER_INDEX_COST_ADJ integer 1
    optimizer_use_invisible_indexes boolean FALSE
    skip_unusable_indexes Boolean TRUE
    SQL >

    SQL > desc FXXX_SEC_POS_FB
    Name                                                                                  Null?    Type
    ------------------------------------------------------------------------------------- -------- ----------------------------------------------------------
    RECID A NOT NULL VARCHAR2 (255)
    XMLRECORD                                                                                      SYS. XMLTYPE BINARY STORAGE

    SQL >

    SQL * more: Production release 11.2.0.4.0 Wed Feb 11 06:34:39 2015

    Copyright (c) 1982, 2013, Oracle.  All rights reserved.


    Connected to:
    Oracle Database 11 g Enterprise Edition Release 11.2.0.4.0 - 64 bit Production
    With partitioning, OLAP, Data Mining and Real Application Testing options

    INDEX_NAME INDEX_TYPE VISIBILITY FUNCIDX_ DOMIDX_MANAGEM
    ------------------------------ --------------------------- --------- -------- --------------
    SYS_IL0000174507C00003$ $ LOB VISIBLE
    BASED ON A NORMAL VISIBLE ENABLED FUNCTION IX_FBNK_SEC_POS_FB_C2
    BASED ON A NORMAL VISIBLE ENABLED FUNCTION IX_FBNK_SEC_POS_FB_C81

    SELECT t.RECID FROM FBNK_SEC_POS_FB WHERE SECURITY_NUMBER = t'000566-000' and xmlexists ("$xmlrecvar/row [c81/text () ="US0010001"]' by the WAY ')

    XMLRECORD AS 'xmlrecvar')

    The higher the SQL statement execution Plan:

    Hash value of plan: 4259655978

    --------------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    --------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT |                 |   361K |   738 M |   197K (2) | 00:39:31 |
    |   1.  SEMI NESTED LOOPS.                 |   361K |   738 M |   197K (2) | 00:39:31 |
    |*  2 |   TABLE ACCESS FULL | FBNK_SEC_POS_FB |  4427 |  9247K |  75786 (1) | 00:15:10 |
    |*  3 |   XPATH EVALUATION.                 |       |       |            |          |
    --------------------------------------------------------------------------------------

    Name of the query block / Alias object (identified by the operation identity card):
    -------------------------------------------------------------

    1 SALT$ BCF67709
    2 SALT$ BCF67709 / T@SEL$1

    Information of predicates (identified by the operation identity card):
    ---------------------------------------------------

    2 - filter("SECURITY_NUMBER"='000566-000')
    3 - filter("P".") C_01$ "= 'US0010001')

    Projection of the column information (identified by the operation identity card):
    -----------------------------------------------------------

    1 (#keys = 0) "T". "RECID" [VARCHAR2, 255], "T" "." " SYS_NC00003$ '[LOB, 4000],
    "SECURITY_NUMBER" [VARCHAR2, 12]
    2 - « T ». "RECID" [VARCHAR2, 255], "T" "." " SYS_NC00003$ '[LOB, 4000],
    "SECURITY_NUMBER" [VARCHAR2, 12]
    3 VALUE (A0) [4000]

    Note
    -----
    -dynamic sample used for this survey (level = 2)
    LETTER: SQL: 2:Full: SELECT t.RECID FROM FBNK_SEC_POS_FB WHERE SECURITY_NUMBER = t'000566-000' and xmlexists (' $xmlrecvar/row [c81 / text ()])

    (= "US0010001"]' in PASSING XMLRECORD AS 'xmlrecvar')

    4096 selected records

    You probably won't see the difference in approach...

    I have NOT used and not STRUCTURED XML, but a STRUCTURED index rather XML index...

    • Index unstructured XML when introduced in 11.1 and use an ARRAY of path. Unstructured XML indexes are mainly used for research "blurred".
    • Structured XML indexes where introduced in 11.2 and make use of one or more TABLES of CONTENTS that contain, must contain content of the structured parts in the XML document

    So I have not used

    CREATE INDEX IX_FXXX_AAA_BBB_FB_FB
    ON FXXX_AAA_BBB_FB (XMLRECORD)
    INDEXTYPE IS XDB.XMLINDEX
    PARAMETERS ('  PATH TABLE IX_PATH_TABLE
                    PATHS (  INCLUDE ( /row/c2 /row/c81 ))'
                );
    

    but instead I used a XML structured, based on the function XMLTABLE index

    CREATE INDEX IX_FXXX_AAA_BBB_FB_FB
      ON FXXX_AAA_BBB_FB (XMLRECORD)
    INDEXTYPE IS XDB.XMLINDEX
      PARAMETERS (q'# GROUP SXI_GROUP
                      XMLTABLE SXI_CONTENT_TABLE
                      '/row'
                      COLUMNS
                        C2  VARCHAR2(100)     PATH 'c2'
                      , C81 VARCHAR2(100)     PATH 'c81'
                    #');
    

    On those, I also created EXTRA build secondary indexes on the columns of the TABLE CONTENT with the name 'SXI_CONTENT_TABLE '.

    create index SEC_FXXX_C2_FB on SXI_CONTENT_TABLE(C2);
    create index SEC_FXXX_C81_FB on SXI_CONTENT_TABLE(C81);
    create unique index SEC_FXXX_RIDC2C81_FB on SXI_CONTENT_TABLE(RID, C2, C81);
    

    ...

  • Query not using Full Scan Index

    Hello world

    I'm on 11.2.0.3.0 AIX 6.1.

    There is a query such as:

    Select: sys_b_0 | Count (distinct (column_name)) table;

    that goes for the analysis full table. The column was values separate only 104 with not NULL values. To save memory buffer gets, I created an index on the table with the column used in the query (i.e. whose distinct values are recovered).

    The problem is that even after the creation of indexes and force the flag index that it does not use the full scan of the index. The provided indication is correct in syntax and was the only clue in the query, so there is no question of conflicts with others.

    Can anyone suggest me what I might be missing?

    Thank you

    It seems to me that if print_branch_code is defined as nullable in the table. If this is the case, the optimizer goes for a sweep of index, even if there is no real NULL values

  • Why index is not used on an editable view update?

    I need help to understand why Oracle 11.2.0.3 is an index for an editable view.  When I refer to the base table, offer$, I access index.  When I reference the view, offer, I get a comprehensive analysis of the offer$.  There's a trigger on the view instead.  Who is factor in there somehow?

    > EXPLAIN the PLAN FOR

    UPDATE OFFER$ SET PRESENTABLE_FLAG = 'F', ACCEPTED_OFFER_FLAG 'T =' WHERE ASSIGNED_OFFER_ID = (SELECT SOLICITATION_REF_ID FROM TENDER WHERE SOLICITATION_ID =: B1)

    plan FOR successful.

    > SELECT * FROM TABLE (DBMS_XPLAN. Display (null, NULL, 'ALL'))

    PLAN_TABLE_OUTPUT

    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Hash value of plan: 3047622554

    -------------------------------------------------------------------------------------------------------------

    | ID | Operation | Name                       | Lines | Bytes | Cost (% CPU). Time |

    -------------------------------------------------------------------------------------------------------------

    |   0 | UPDATE STATEMENT.                            |     1.    25.     2 (0) | 00:00:01 |

    |   1.  UPDATE                        | OFFER$                     |       |       |            |          |

    |   2.   TABLE ACCESS BY INDEX ROWID | OFFER$                     |     1.    25.     1 (0) | 00:00:01 |

    |*  3 |    INDEX UNIQUE SCAN | AK_OFFER_ASSIGNED_OFFER_ID |     1.       |     1 (0) | 00:00:01 |

    |   4.     TABLE ACCESS BY INDEX ROWID | TENDER $ |     1.    20.     1 (0) | 00:00:01 |

    |*  5 |      INDEX UNIQUE SCAN | PK_SOLICITATION$ |     1.       |     1 (0) | 00:00:01 |

    -------------------------------------------------------------------------------------------------------------

    Name of the query block / Alias object (identified by the operation identity card):

    -------------------------------------------------------------

    1 UPD$ 1

    2 UPD$ 1 / OFFER$@UPD$1

    3 UPD$ 1 / OFFER$@UPD$1

    4 SALT$ F5BB74E1 / SOLICITATION$@SEL$2

    5. SALT$ F5BB74E1 / SOLICITATION$@SEL$2

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    3 - access ("ASSIGNED_OFFER_ID" = (SELECT "SOLICITATION_REF_ID" FROM KOHP." "TENDER CALL $ '.

    "TENDER CALL $ ' WHERE 'SOLICITATION_ID' = TO_NUMBER (:B1)))

    5 - access ('SOLICITATION_ID' = TO_NUMBER (:B1))

    Projection of the column information (identified by the operation identity card):

    -----------------------------------------------------------

    2 - (upd = 4, 6, 7 cmp = 3, 7; cpy = 2, 4, 5) "OFFER$". ROWID [ROWID, 10], "OFFER$". " DECISION_ID '[NUMBER, 22],

    "ASSIGNED_OFFER_ID" [VARCHAR2, 255], "ACCEPTED_OFFER_FLAG" [CHARACTER, 1],

    "OFFER$". " CURRENT_OFFER_FLAG "[CHARACTER, 1],"PRESENTABLE_FLAG "[CHARACTER, 1],"

    "OFFER$". " CHNG_DTTM ' [TIMESTAMP, 11].

    3. "OFFER$". ROWID [ROWID, 10], "ASSIGNED_OFFER_ID" [VARCHAR2, 255]

    4. "TENDER CALL $ '. ROWID [ROWID, 10], "SOLICITATION_ID" [NO.22].

    "SOLICITATION_REF_ID" [VARCHAR2, 50]

    5. "TENDER CALL $ '. ROWID [ROWID, 10], "SOLICITATION_ID" [NO.22]

    40 selected lines

    > EXPLAIN the PLAN FOR

    UPDATE OFFER SET PRESENTABLE_FLAG = 'F', ACCEPTED_OFFER_FLAG 'T =' WHERE ASSIGNED_OFFER_ID = (SELECT SOLICITATION_REF_ID FROM TENDER WHERE SOLICITATION_ID =: B1)

    plan FOR successful.

    > SELECT * FROM TABLE (DBMS_XPLAN. Display (null, NULL, 'ALL'))

    PLAN_TABLE_OUTPUT

    ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    Hash value of plan: 1083159671

    --------------------------------------------------------------------------------------------------

    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

    --------------------------------------------------------------------------------------------------

    |   0 | UPDATE STATEMENT.                  |   958K |   987 M |  9182 (1) | 00:01:51 |

    |   1.  UPDATE                       | OFFER |       |       |            |          |

    |*  2 |   VIEW                        | OFFER |   958K |   987 M |  9181 (1) | 00:01:51 |

    |   3.    TABLE ACCESS FULL | OFFER$ |   958K |   127 M |  9181 (1) | 00:01:51 |

    |   4.    TABLE ACCESS BY INDEX ROWID | TENDER $ |     1.    20.     1 (0) | 00:00:01 |

    |*  5 |     INDEX UNIQUE SCAN | PK_SOLICITATION$ |     1.       |     1 (0) | 00:00:01 |

    --------------------------------------------------------------------------------------------------

    Name of the query block / Alias object (identified by the operation identity card):

    -------------------------------------------------------------

    1 UPD$ 1

    2 SALT$ 1 / OFFER@UPD$1

    3 SALT$ 1 / OFFER$@SEL$1

    4 SALT$ 335DD26A / SOLICITATION$@SEL$3

    5. SALT$ 335DD26A / SOLICITATION$@SEL$3

    Information of predicates (identified by the operation identity card):

    ---------------------------------------------------

    2 - filter ("ASSIGNED_OFFER_ID" = (SELECT "SOLICITATION_REF_ID" FROM

    KOHP. ' ' TENDER $ "" PROMPT$ ' WHERE 'SOLICITATION_ID' = TO_NUMBER (:B1)))

    5 - access ('SOLICITATION_ID' = TO_NUMBER (:B1))

    Projection of the column information (identified by the operation identity card):

    -----------------------------------------------------------

    2 - (upd = 13, 45; cmp = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 2

    7,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,46,47,48,49,50)

    'OFFER '. "OFFER_ID" [NO.22], "PROVIDE" "." " DECISION_ID '[NUMBER, 22],

    'OFFER '. "OFFER_TYPE_CD" [NO.22], "PROVIDE" "." " PROMO_ID '[NUMBER, 22],

    'OFFER '. "PYMT_METHOD_TYPE_CD" [NO.22], "PROVIDE" "." " CS_RESULT_ID '[NUMBER, 22],

    'OFFER '. "CS_RESULT_USAGE_TYPE_CD" [NO.22], "PROVIDE" "." " RATE_INDEX_TYPE_CD '[NUMBER, 22],

    'OFFER '. "SUB_PRODUCT_ID" [NO.22], "PROVIDE" "." " CAMPAIGN_ID '[NUMBER, 22],

    'OFFER '. "MARKET_CELL_ID" [NO.22], "ASSIGNED_OFFER_ID" [VARCHAR2, 255], "" "

    "ACCEPTED_OFFER_FLAG" [CHARACTER, 1], 'OFFER '. "CURRENT_OFFER_FLAG"[CHARACTER, 1],

    'OFFER '. "OFFER_GOOD_UNTIL_DATE" [DATE, 7], "PROVIDE" "." " RESCINDABLE_DAYS '[NUMBER, 22],

    'OFFER '. "RESCINDED_DATE" [DATE, 7], "PROVIDE" "." " AMOUNT '[NUMBER, 22],

    'OFFER '. "MAX_AMOUNT" [NO.22], "PROVIDE" "." " AMOUNT_FINANCED '[NUMBER, 22],

    'OFFER '. "DOWN_PYMT" [NO.22], "PROVIDE" "." " RATE "[NO.22],"PROVIDE"". "" TERM_MM '[NUMBER, 22],

    'OFFER '. "ORIGINATION_FEE_AMOUNT" [NO.22], "PROVIDE" "." " ORIGINATION_FEE_RATE '[NUMBER, 22],

    'OFFER '. "FINANCE_CHARGE" [NO.22], "PROVIDE" "." " NBR_OF_PYMTS '[NUMBER, 22],

    'OFFER '. "PYMT" [NO.22], "PROVIDE" "." " TOTAL_PYMTS '[NUMBER, 22],

    'OFFER '. "FIRST_PYMT_DATE" [DATE, 7], "PROVIDE" "." " CONTRACT_DATE "[DATE, 7],

    'OFFER '. "ACCT_NBR" [VARCHAR2, 20], "PROVIDE" "." " ACCT_NBR_ASSIGNED_DTTM ' [TIMESTAMP, 11],

    'OFFER '. "ACCT_EXPIRATION_DTTM" [DATE, 8], "PROVIDE" "." " OFFER_DESC ' [VARCHAR2, 255],

    'OFFER '. "TIMEOUTMIN_RATE" [NO.22], "PROVIDE" "." " MAX_RATE '[NUMBER, 22],

    'OFFER '. "MIN_AMOUNT" [NO.22], "PROVIDE" "." " ANNUAL_FEE_AMOUNT '[NUMBER, 22],

    'OFFER '. "ANNUAL_FEE_WAIVED_MM" [NO.22], "PROVIDE" "." " LATE_FEE_PERCENT '[NUMBER, 22],

    'OFFER '. "LATE_FEE_MIN_AMOUNT" [NO.22], "PROVIDE" "." " OFFER_SALES_SCRIPT ' [VARCHAR2, 500],

    'OFFER '. "OFFER_ORDER" [NO.22], "PRESENTABLE_FLAG"[CHARACTER, 1], "

    'OFFER '. "INDEX_RATE" [NO.22], "PROVIDE" "." " ACTV_FLAG ' [VARCHAR2, 1],

    'OFFER '. "CORRELATION_ID" [VARCHAR2, 64], "PROVIDE" "." " OFFER_STATUS_TYPE_CD '[NUMBER, 22],

    'OFFER '. "PRESENTATION_INSTRUMENT_NBR" [VARCHAR2, 20].

    3. "OFFER_ID" [NO.22], "DECISION_ID" [NO.22], "OFFER_TYPE_CD" [NO.22],

    "PROMO_ID" [NO.22], "PYMT_METHOD_TYPE_CD" [NO.22], "CS_RESULT_ID" [NO.22],

    "CS_RESULT_USAGE_TYPE_CD" [NO.22], "RATE_INDEX_TYPE_CD" [NO.22],

    "SUB_PRODUCT_ID" [NO.22], 'CAMPAIGN_ID' [NO.22], "MARKET_CELL_ID" [NO.22],

    "ASSIGNED_OFFER_ID" [VARCHAR2, 255], "ACCEPTED_OFFER_FLAG" [CHARACTER, 1],

    "CURRENT_OFFER_FLAG" [CHARACTER, 1], "OFFER_GOOD_UNTIL_DATE" [DATE, 7],.

    "RESCINDABLE_DAYS" [NO.22], "RESCINDED_DATE" [DATE, 7], 'COME BACK' [NO.22].

    "MAX_AMOUNT" [NO.22], "AMOUNT_FINANCED" [NO.22], "DOWN_PYMT" [NO.22],

    'RATE' [NO.22], "TERM_MM" [NO.22], "ORIGINATION_FEE_AMOUNT" [NO.22],

    "ORIGINATION_FEE_RATE" [NO.22], "FINANCE_CHARGE" [NO.22],

    "NBR_OF_PYMTS" [NO.22], "PYMT" [NO.22], "TOTAL_PYMTS" [NO.22],

    "FIRST_PYMT_DATE" [DATE, 7], "CONTRACT_DATE" [DATE, 7], ' ACCT_NBR$ ' [RAW, 40].

    "ACCT_NBR_ASSIGNED_DTTM" [TIMESTAMP, 11], ' ACCT_EXPIRATION_DTTM$ ' [RAW, 40].

    "OFFER_DESC" [VARCHAR2, 255], "TIMEOUTMIN_RATE" [NO.22], "MAX_RATE" [NO.22].

    "MIN_AMOUNT" [NO.22], "ANNUAL_FEE_AMOUNT" [NO.22],

    "ANNUAL_FEE_WAIVED_MM" [NO.22], "LATE_FEE_PERCENT" [NO.22],

    "LATE_FEE_MIN_AMOUNT" [NO.22], "OFFER_SALES_SCRIPT" [VARCHAR2, 500].

    "OFFER_ORDER" [NO.22], "PRESENTABLE_FLAG" [CHARACTER, 1], "INDEX_RATE" [NO.22],

    "ACTV_FLAG" [VARCHAR2, 1], "CORRELATION_ID" [VARCHAR2, 64].

    "OFFER_STATUS_TYPE_CD" [NO.22], ' PRESENTATION_INSTRUMENT_NBR$ ' [RAW, 40]

    4. "TENDER CALL $ '. ROWID [ROWID, 10], "SOLICITATION_ID" [NO.22].

    "SOLICITATION_REF_ID" [VARCHAR2, 50]

    5. "TENDER CALL $ '. ROWID [ROWID, 10], "SOLICITATION_ID" [NO.22]

    82 selected lines

    CREATE OR REPLACE FORCE VIEW "OFFER" ("OFFER_ID","DECISION_ID","OFFER_TYPE_CD","PROMO_ID","PYMT_METHOD_TYPE_CD","CS_RESULT_ID","CS_RESULT_USAGE_TYPE_CD","RATE_INDEX_TYPE_CD","SUB_PRODUCT_ID","CAMPAIGN_ID","MARKET_CELL_ID","ASSIGNED_OFFER_ID","ACCEPTED_OFFER_FLAG","CURRENT_OFFER_FLAG","OFFER_GOOD_UNTIL_DATE","RESCINDABLE_DAYS","RESCINDED_DATE","AMOUNT","MAX_AMOUNT","AMOUNT_FINANCED" ,"DOWN_PYMT","RATE","TERM_MM","ORIGINATION_FEE_AMOUNT","ORIGINATION_FEE_RATE","FINANCE_CHARGE","NBR_OF_PYMTS","PYMT","TOTAL_PYMTS","FIRST_PYMT_DATE","CONTRACT_DATE","ACCT_NBR","ACCT_NBR_ASSIGNED_DTTM","ACCT_EXPIRATION_DTTM","OFFER_DESC","MIN_RATE","MAX_RATE","MIN_AMOUNT","ANNUAL_FEE_AMOUNT","ANNUAL_FEE_WAIVED_MM","LATE_FEE_PERCENT","LATE_FEE_MIN_AMOUNT","OFFER_SALES_SCRIPT","OFFER_ORDER","PRESENTABLE_FLAG" « INDEX_RATE » 'INSRT_DTTM', 'INSRT_USR_ID', 'CHNG_DTTM', 'CHNG_USR_ID', 'ACTV_FLAG', 'CORRELATION_ID', 'OFFER_STATUS_TYPE_CD', 'PRESENTATION_INSTRUMENT_NBR')

    AS

    SELECT

    OFFER_ID

    DECISION_ID

    OFFER_TYPE_CD

    PROMO_ID

    PYMT_METHOD_TYPE_CD

    CS_RESULT_ID

    CS_RESULT_USAGE_TYPE_CD

    RATE_INDEX_TYPE_CD

    SUB_PRODUCT_ID

    CAMPAIGN_ID

    MARKET_CELL_ID

    ASSIGNED_OFFER_ID

    ACCEPTED_OFFER_FLAG

    CURRENT_OFFER_FLAG

    OFFER_GOOD_UNTIL_DATE

    RESCINDABLE_DAYS

    RESCINDED_DATE

    QUANTITY

    MAX_AMOUNT

    AMOUNT_FINANCED

    DOWN_PYMT

    RATE

    TERM_MM

    ORIGINATION_FEE_AMOUNT

    ORIGINATION_FEE_RATE

    FINANCE_CHARGE

    NBR_OF_PYMTS

    DATED THE

    TOTAL_PYMTS

    FIRST_PYMT_DATE

    CONTRACT_DATE

    , CAST (zcrypto.decrypt (ACCT_NBR$) AS VARCHAR2 (20)) ACCT_NBR

    ACCT_NBR_ASSIGNED_DTTM

    , ACCT_EXPIRATION_DTTM TO_DATE (zcrypto.decrypt (ACCT_EXPIRATION_DTTM$))

    OFFER_DESC

    TIMEOUTMIN_RATE

    MAX_RATE

    MIN_AMOUNT

    ANNUAL_FEE_AMOUNT

    ANNUAL_FEE_WAIVED_MM

    LATE_FEE_PERCENT

    LATE_FEE_MIN_AMOUNT

    OFFER_SALES_SCRIPT

    OFFER_ORDER

    PRESENTABLE_FLAG

    INDEX_RATE

    INSRT_DTTM

    INSRT_USR_ID

    CHNG_DTTM

    CHNG_USR_ID

    ACTV_FLAG

    CORRELATION_ID

    OFFER_STATUS_TYPE_CD

    , CAST (zcrypto.decrypt (PRESENTATION_INSTRUMENT_NBR$) AS VARCHAR2 (20)) PRESENTATION_INSTRUMENT_NBR

    Of

    OFFER$;

    CREATE OR REPLACE TRIGGER "OFFER_IO" INSTEAD OF

    INSERT OR

    UPDATE

    THEN OFFER REFERENCING NEW AS NEW AS OF OLD FOR THE BEGINNING OF EACH ROW SO (INSERT)

    INSERT

    IN

    OFFER$

    (

    OFFER_ID

    DECISION_ID

    OFFER_TYPE_CD

    PROMO_ID

    PYMT_METHOD_TYPE_CD

    CS_RESULT_ID

    CS_RESULT_USAGE_TYPE_CD

    RATE_INDEX_TYPE_CD

    SUB_PRODUCT_ID

    CAMPAIGN_ID

    MARKET_CELL_ID

    ASSIGNED_OFFER_ID

    ACCEPTED_OFFER_FLAG

    CURRENT_OFFER_FLAG

    OFFER_GOOD_UNTIL_DATE

    RESCINDABLE_DAYS

    RESCINDED_DATE

    QUANTITY

    MAX_AMOUNT

    AMOUNT_FINANCED

    DOWN_PYMT

    RATE

    TERM_MM

    ORIGINATION_FEE_AMOUNT

    ORIGINATION_FEE_RATE

    FINANCE_CHARGE

    NBR_OF_PYMTS

    DATED THE

    TOTAL_PYMTS

    FIRST_PYMT_DATE

    CONTRACT_DATE

    , ACCT_NBR$

    ACCT_NBR_ASSIGNED_DTTM

    , ACCT_EXPIRATION_DTTM$

    OFFER_DESC

    TIMEOUTMIN_RATE

    MAX_RATE

    MIN_AMOUNT

    ANNUAL_FEE_AMOUNT

    ANNUAL_FEE_WAIVED_MM

    LATE_FEE_PERCENT

    LATE_FEE_MIN_AMOUNT

    OFFER_SALES_SCRIPT

    OFFER_ORDER

    PRESENTABLE_FLAG

    INDEX_RATE

    ACTV_FLAG

    CORRELATION_ID

    OFFER_STATUS_TYPE_CD

    , PRESENTATION_INSTRUMENT_NBR$

    )

    VALUES

    (

    : NEW. OFFER_ID

    ,: NEW. DECISION_ID

    ,: NEW. OFFER_TYPE_CD

    ,: NEW. PROMO_ID

    ,: NEW. PYMT_METHOD_TYPE_CD

    ,: NEW.CS_RESULT_ID

    ,: NEW.CS_RESULT_USAGE_TYPE_CD

    ,: NEW. RATE_INDEX_TYPE_CD

    ,: NEW. SUB_PRODUCT_ID

    ,: NEW. CAMPAIGN_ID

    ,: NEW. MARKET_CELL_ID

    ,: NEW. ASSIGNED_OFFER_ID

    ,: NEW. ACCEPTED_OFFER_FLAG

    ,: NEW. CURRENT_OFFER_FLAG

    ,: NEW. OFFER_GOOD_UNTIL_DATE

    ,: NEW. RESCINDABLE_DAYS

    ,: NEW. RESCINDED_DATE

    ,: NEW. AMOUNT

    ,: NEW. MAX_AMOUNT

    ,: NEW. AMOUNT_FINANCED

    ,: NEW. DOWN_PYMT

    ,: NEW. RATE

    ,: NEW. TERM_MM

    ,: NEW. ORIGINATION_FEE_AMOUNT

    ,: NEW. ORIGINATION_FEE_RATE

    ,: NEW. FINANCE_CHARGE

    ,: NEW. NBR_OF_PYMTS

    ,: NEW. DATED THE

    ,: NEW. TOTAL_PYMTS

    ,: NEW. FIRST_PYMT_DATE

    ,: NEW. CONTRACT_DATE

    , zcrypto.encrypt (: NEW.) ACCT_NBR)

    ,: NEW. ACCT_NBR_ASSIGNED_DTTM

    , zcrypto.encrypt (: NEW.) ACCT_EXPIRATION_DTTM)

    ,: NEW. OFFER_DESC

    ,: NEW. TIMEOUTMIN_RATE

    ,: NEW. MAX_RATE

    ,: NEW. MIN_AMOUNT

    ,: NEW. ANNUAL_FEE_AMOUNT

    ,: NEW. ANNUAL_FEE_WAIVED_MM

    ,: NEW. LATE_FEE_PERCENT

    ,: NEW. LATE_FEE_MIN_AMOUNT

    ,: NEW. OFFER_SALES_SCRIPT

    ,: NEW. OFFER_ORDER

    ,: NEW. PRESENTABLE_FLAG

    ,: NEW. INDEX_RATE

    ,: NEW. ACTV_FLAG

    ,: NEW. CORRELATION_ID

    ,: NEW. OFFER_STATUS_TYPE_CD

    , zcrypto.encrypt (: NEW.) PRESENTATION_INSTRUMENT_NBR)

    );

    ON THE OTHER

    UPDATE

    OFFER$

    SET

    DECISION_ID =: NEW. DECISION_ID

    , OFFER_TYPE_CD =: NEW. OFFER_TYPE_CD

    , PROMO_ID =: NEW. PROMO_ID

    , PYMT_METHOD_TYPE_CD =: NEW. PYMT_METHOD_TYPE_CD

    , CS_RESULT_ID =: NEW.CS_RESULT_ID

    , CS_RESULT_USAGE_TYPE_CD =: NEW.CS_RESULT_USAGE_TYPE_CD

    , RATE_INDEX_TYPE_CD =: NEW. RATE_INDEX_TYPE_CD

    , SUB_PRODUCT_ID =: NEW. SUB_PRODUCT_ID

    , = CAMPAIGN_ID: NEW. CAMPAIGN_ID

    , MARKET_CELL_ID =: NEW. MARKET_CELL_ID

    , ASSIGNED_OFFER_ID =: NEW. ASSIGNED_OFFER_ID

    , ACCEPTED_OFFER_FLAG =: NEW. ACCEPTED_OFFER_FLAG

    , CURRENT_OFFER_FLAG =: NEW. CURRENT_OFFER_FLAG

    , OFFER_GOOD_UNTIL_DATE =: NEW. OFFER_GOOD_UNTIL_DATE

    , RESCINDABLE_DAYS =: NEW. RESCINDABLE_DAYS

    , RESCINDED_DATE =: NEW. RESCINDED_DATE

    , QUANTITY =: NEW. AMOUNT

    , MAX_AMOUNT =: NEW. MAX_AMOUNT

    , AMOUNT_FINANCED =: NEW. AMOUNT_FINANCED

    , DOWN_PYMT =: NEW. DOWN_PYMT

    ,RATE                         = :NEW. RATE

    , TERM_MM =: NEW. TERM_MM

    , ORIGINATION_FEE_AMOUNT =: NEW. ORIGINATION_FEE_AMOUNT

    , ORIGINATION_FEE_RATE =: NEW. ORIGINATION_FEE_RATE

    , FINANCE_CHARGE =: NEW. FINANCE_CHARGE

    , NBR_OF_PYMTS =: NEW. NBR_OF_PYMTS

    ,PYMT                         = :NEW. DATED THE

    , TOTAL_PYMTS =: NEW. TOTAL_PYMTS

    , FIRST_PYMT_DATE =: NEW. FIRST_PYMT_DATE

    , CONTRACT_DATE =: NEW. CONTRACT_DATE

    , ACCT_NBR$ = zcrypto.encrypt (: NEW.) ACCT_NBR)

    , ACCT_NBR_ASSIGNED_DTTM =: NEW. ACCT_NBR_ASSIGNED_DTTM

    , ACCT_EXPIRATION_DTTM$ = zcrypto.encrypt (: NEW.) ACCT_EXPIRATION_DTTM)

    , OFFER_DESC =: NEW. OFFER_DESC

    , TIMEOUTMIN_RATE =: NEW. TIMEOUTMIN_RATE

    , MAX_RATE =: NEW. MAX_RATE

    , MIN_AMOUNT =: NEW. MIN_AMOUNT

    , ANNUAL_FEE_AMOUNT =: NEW. ANNUAL_FEE_AMOUNT

    , ANNUAL_FEE_WAIVED_MM =: NEW. ANNUAL_FEE_WAIVED_MM

    , LATE_FEE_PERCENT =: NEW. LATE_FEE_PERCENT

    , LATE_FEE_MIN_AMOUNT =: NEW. LATE_FEE_MIN_AMOUNT

    , OFFER_SALES_SCRIPT =: NEW. OFFER_SALES_SCRIPT

    , OFFER_ORDER =: NEW. OFFER_ORDER

    , PRESENTABLE_FLAG =: NEW. PRESENTABLE_FLAG

    , INDEX_RATE =: NEW. INDEX_RATE

    , ACTV_FLAG =: NEW. ACTV_FLAG

    , CORRELATION_ID =: NEW. CORRELATION_ID

    , OFFER_STATUS_TYPE_CD =: NEW. OFFER_STATUS_TYPE_CD

    , PRESENTATION_INSTRUMENT_NBR$ = zcrypto.encrypt (: NEW.) PRESENTATION_INSTRUMENT_NBR)

    WHERE

    OFFER_ID =: NEW. OFFER_ID;

    END IF;

    END;

    /

    zsysdba wrote:

    I need help to understand why Oracle 11.2.0.3 is an index for an editable view.  When I refer to the base table, offer$, I access index.  When I reference the view, offer, I get a comprehensive analysis of the offer$.  There's a trigger on the view instead.  Who is factor in there somehow?

    Almost certainly.

    Even if the view has not used the calls to the function and the trigger was simply "null;" as the body, the presence of the trigger seems to prevent the optimizer to push the subquery view internal and down to the index (and there is no change in 12 c).

    Concerning

    Jonathan Lewis

  • Performance problem - Index is not used when a string of zero padded is queried

    Hi all

    I have a table T1 that has many columns. One such column C1 is a varchar2 (20). T1 has 10 million rows and there is an index I1 called C1. His stats are updated for tables and indexes. Here 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 a reason for this problem of performance? Why the optimizer goes for FTS in scenario 3?

    Published by: user539954 on May 14, 2009 12:22

    Published by: user539954 on May 14, 2009 12:32

    user539954 wrote:

    one) says user_tab_histograms on the histogram on the column
    -Online there are about 250 lines for this query (varies from between 0 and 254 endpoint_number)
    Select * from user_tab_histograms where column_name like 'C1' and table_name like 'T1 '.

    It's balanced height histogram - by default in 10g if you do not deliberately block histograms you get histograms.

    >

    (b) If you "set autotrace traceonly explain' and run the queries a bit do you can predictions of a few lines for most of the values, but the predictions of a large number of lines when the value begins with zero, one or more zeros.
    => working on this now because there is a power outage now

    No need, your response to Justin provided examples which proved the point.
    If you expect always a few lines for all values of this column then you must ensure that this histogram does not builds. To avoid histograms in general, you must specify method_opt like 'for all columns size 1' in the call to dbms_stats.gather_table_stats; and don't forget that in 10g, you get an automatic job working at 22:00 that could remember his stats because he thinks that current statistics have gone stale.

    Concerning
    Jonathan Lewis
    http://jonathanlewis.WordPress.com
    http://www.jlcomp.demon.co.UK

    "Science is more than a body of knowledge; It's a way of thinking. "
    Carl Sagan

  • This index is not used

    Hi forum

    Dynamically generated in this query:

    SELECT TITULO_MEDIODEPAGO AS TITLE, IDA_MEDIODEPAGO AS IDA, COUNT (DISTINCT VISTA. ID1 | VISTA. ID2. VISTA. ID3) AS AMOUNT

    OF MVISTA VISTA

    WHERE ((COALESCE (VISTA. FECHAEXPIRACION, TO_DATE (' 01/01/9999 ',' dd/mm/yyyy ""))) > = SYSDATE) AND

    ((1=1) OR: p_rubro IS NULL) AND ((1=1) OR: p_subrubro IS NULL) AND

    (VISTA. TITULO_PROVINCIA =: p_provincia) AND ((1=1) OR: p_ciudad IS NULL) AND

    ((1=1) OR: p_barrio IS NULL) AND ((1=1) OR: p_mediopago IS NULL) AND

    ((1=1) OR: p_nrocuotas IS NULL) AND ((1=1) OR: p_porcentaje IS NULL) AND

    ((1=1) OR: p_dias IS NULL) AND ((1=1) OR: p_textoBusqueda IS NULL)

    TITULO_MEDIODEPAGO GROUP, IDA_MEDIODEPAGO

    : p_rubro is null

    : p_subrubro is null

    : p_provincia = "PROV1.

    : p_barrio is null

    : p_mediopago is null

    : p_nrocuotas is null

    : p_porcentaje is null

    : p_dias is null

    : p_textoBusqueda is null

    When I inspect the plan to explain it, I could see a full analysis on the materialized view MVISTA operation. I want to avoid this analysis complements the view with 500 k lines:

    MAT_VIEW_ACCESSMVISTA

    Filter predicates

    AND
    NLSSORT (VISTA. TITULO_PROVINCIA, "nls_sort = 'BINART_AI'") = NLSSORT (: P_PROVINCIA "nls_sort =" BINARY_AI"')
    COALESCE (VISTA. FECHAEXPIRACION, TIMESTAMP'9999-01-01 00:00:00 ') > = SYSDATE @!

    I add an index to the materialized view 'MVISTA' TITULO_PROVINCIA (CSA) and FECHAEXPIRACION (CSA) fields, but it is not used by the query. Why the index is not used? How to define the index serve him?

    Thank you very much

    One of the reasons for the index is not used because you apply the function nlssort on a single column.

    You must use an index of feature based using this function instead.

    In addition, I would rewrtite him coalesce to

    (VISTA. FECHAEXPIRACION > = SYSDATE or VISTA. FECHAEXPIRACION is null)

  • tablespace as defined in the model of the index is not used for manually defined indexes

    Hello

    in the 4.0.1.836 version, I defined under model in Modeler, model, physics, use index of preferences / Data (I use the German version, I hope that I have translated correctly) an index template that contains a value for the attribute tablespace.

    For indexes that are generated automatically (as defined in the properties of my model under the generation of index DDL/auto/properties") it works fine. There was a thread on this already Tablespace for the automatically generated index. It works very well. However, for indexes that manually in a table there is no tablespace clause in the generated ddl script generated. Is this a bug or am I missing something?

    Thanks for your help,

    Jochen

    Hello Jochen,

    Yes.  You are right.  For manually defined indexes, the Index model is applied when the Index is created in the first place.  As these properties are in the physical model, it is only effective if the relevant physical model is open when the Index is created in the first place.  The Tablespace defined in the template is applied only if the physical model contains a Tablespace with the same name.

    I guess it's a bit inconsistent for the automatically generated index Tablespace clause is generated when the physical model is not open.

    David

  • Oracle 10.2.0.4 Index on the time stamp column not used when SYSTIMESTAMP is used.

    Hello
    I have a table with a timestamp (6) column B. About 300000 rows in the tables...
    I created index 'idx' on column B.

    When I compare the column 'B' with systimestamp, it does not use the index, whereas if I compare 'B' with sysdate it uses the index.

    For example:
    Select count (*) in a b where clause < = sysdate;

    The above used the subscript "idx" and executed in 1 second

    Select count (*) in a b where clause < = systimestamp;

    The foregoing does not use the index and performed in 19 seconds.

    Any clue?

    Thanks in advance

    Oracle uses the internal functions when you use SYSTIMESTAMP:

    Work around is to use TO_TIMESTAMP as shown below... Or define a function based index...

    You can check the performance querying against a column "TIMESTAMP WITH time ZONE SCHEDULE" issue link too

    SQL> create table a(b timestamp(6));
    
    Table created.
    
    SQL> insert into a
      2  select systimestamp+(level/24) from dual connect by level <= 30000;
    
    30000 rows created.
    
    SQL> commit;
    
    Commit complete.
    
    SQL> create index ndx on a(b);
    
    Index created.
    
    SQL> explain plan for
      2  select count(*) from a where b <= sysdate;
    
    Explained.
    
    SQL> select * from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    Plan hash value: 3858831102
    
    --------------------------------------------------------------------------
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------
    |   0 | SELECT STATEMENT  |      |     1 |    13 |     1   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE   |      |     1 |    13 |            |          |
    |*  2 |   INDEX RANGE SCAN| NDX  |     1 |    13 |     1   (0)| 00:00:01 |
    --------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("B"<=SYSDATE@!)
    
    Note
    -----
       - dynamic sampling used for this statement
    
    18 rows selected.
    
    SQL> explain plan for
      2  select count(*) from a where b <= systimestamp;
    
    Explained.
    
    SQL>  select * from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    Plan hash value: 3918351354
    
    ---------------------------------------------------------------------------
    | Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    ---------------------------------------------------------------------------
    |   0 | SELECT STATEMENT   |      |     1 |    13 |    20  (15)| 00:00:01 |
    |   1 |  SORT AGGREGATE    |      |     1 |    13 |            |          |
    |*  2 |   TABLE ACCESS FULL| A    |     1 |    13 |    20  (15)| 00:00:01 |
    ---------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - filter(SYS_EXTRACT_UTC(INTERNAL_FUNCTION("B"))<=SYS_EXTRACT_UTC(S
                  YSTIMESTAMP(6)))
    
    Note
    -----
       - dynamic sampling used for this statement
    
    19 rows selected.
    
    --"Just tried using TO_TIMESTAMP"
    
    SQL> explain plan for
      2  select count(*) from a where b <= to_timestamp(systimestamp);
    
    Explained.
    
    SQL>
    SQL> select * from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    --------------------------------------------------------------------------------
    Plan hash value: 3858831102
    
    --------------------------------------------------------------------------
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------
    |   0 | SELECT STATEMENT  |      |     1 |    13 |     2   (0)| 00:00:01 |
    |   1 |  SORT AGGREGATE   |      |     1 |    13 |            |          |
    |*  2 |   INDEX RANGE SCAN| NDX  |     4 |    52 |     2   (0)| 00:00:01 |
    --------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("B"<=TO_TIMESTAMP(TO_CHAR(SYSTIMESTAMP(6))))
    
    14 rows selected.
    

    Published by: JAC on October 23, 2012 11:18

Maybe you are looking for

  • iBook G4 battery problem

    My iBook G4 has a problem where the battery says its operation to reserve power even if the battery has about 80% charge left in it. When I go to charge the battery it will go to 98% or sometimes it will go to 88%. a way to solve this problem?

  • Problem I had after having erased everything on my MacBook

    I recently got a new PC, so I decided to give my old MacBook mid 2010 to my friend who doesn't have a computer. I wanted to get rid of all my files on it first, so I rebooted and pressed command and R together to access the start menu. I clicked on t

  • Cannot print the invoice specifications, shows it is not possible to print

    It is not possible to print the e-invoicespec. I am connected to my bank on the internet (SEB). The page is imported from an external source and is displayed but is not possible to print.With Int Explorer printing is possible by a good mousepress

  • New laptop Satellite C50-A-1CK Fan make a static/crackling sound?

    I recently introduced a new laptop Satellite C50-A-1CK the December 8,. I didn't use the phone a lot.I noticed in the last days the fan made a static/crackling sound power, seems to come from the fan (on the upper right corner) when it turns. Is this

  • Streaming of Netflix problem with Airport Extreme

    Hello, I have netflix streaming problems, I have an Apple Airport Extreme that my main router, the problem is that I can access netflix app or website, I chose the title I want to watch that one and then an error message indicates Oops, something wen