Basic query - Index Skip Scan

Hello

I have a very basic question.

I use Autotrace to check the Plan for this query

Table definition:
------------------------------------
create table tb_emp)
sextype varchar2 (1).
EmpID number
);

Array of values
-----------------------------------------------
insert into tb_emp values ('F', 98);
insert into tb_emp values ('F', 100);
insert into tb_emp values ('F', 102);
insert into tb_emp values ('F', 104);
insert into tb_emp values('M',101);
insert into tb_emp values('M',103);
insert into tb_emp values('M',105);
commit;

Index:
-----------------------------------------------------------------------------
create index EMP_SEXTYPE_EMP_IDX on tb_emp (SEXTYPE, empid);


Query:
--------------------------------------------------------------------------------------------------------------
Select * from tb_emp where empid = 101;

---------------------------------------------------------------------------------------------------------------
Execution plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer = ALL_ROWS (cost = 0 card = 1 bytes = 15)
1 INDEX 0 (COMPLETE ANALYSIS) OF 'EMP_SEXTYPE_EMP_IDX' (INDEX) (cost = 0 card = 1 bytes = 15)

According to b14211 this should translate into an index Skip Scan,

A pointer to what am I missing or other parameters that could affect the execution plan.
Thank you and best regards,
Ashish.

The case of test used by you is not a real. With 7 records in a table is important if the optimizer goes for a systematic index scan or a full scan?

make it a little big and try

SQL> truncate table tb_emp
  2  /

Table truncated.

SQL> set autotrace off

SQL> edit
Wrote file afiedt.buf

  1  insert into tb_emp
  2  select decode(mod(level,2),0,'M','F'), level
  3    from dual
  4* connect by level <= 10000
SQL> /

10000 rows created.

SQL> commit
  2  /

Commit complete.

SQL> select sextype, count(*) from tb_emp group by sextype
  2  /

S   COUNT(*)
- ----------
M       5000
F       5000

SQL> exec dbms_stats.gather_table_stats(user,'TB_EMP',cascade=>true)

PL/SQL procedure successfully completed.

SQL> set autotrace traceonly explain
SQL> select * from tb_emp where empid = 3000
  2  /

Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=1 Bytes=5)
   1    0   INDEX (SKIP SCAN) OF 'EMP_SEXTYPE_EMP_IDX' (INDEX) (Cost=3 Card=1 Bytes=5)

Tags: Database

Similar Questions

  • Why the feature multiple column indexes using index skip scan?

    Hi all

    I have just been hired by a new company and I explored its database infrastructure. Interestingly, I see several function based indexed column used for all the tables. I found it strange, but they said ' we use Axapta to connect Axapta with Oracle, function index according to should be used to improve performance. Therefore, our DBAs create several indexes of feature based for each table in the database. "Unfortunately, I can not judge their business logic.

    My question is, I just created similar to my local database tables in order to understand the behavior of the function index according to several columns. In order to create indexes of based function (substr and nls_lower), I have to declare the columns as varchars2. Because in my business our DBAs had created a number of columns as a varchar2 data type. I created two excatly same table for my experience. I create miltiple function according to index on the my_first table, and then I create several normal index on the my_sec table. The interesting thing is, index skip scan cannot be performed on more than one basic function index (table my_first). However, it can be performed to normal several index on my_sec table. I hope that I have to express myself clearly.

    Note: I also ask the logic of the rule function based index, they said when they index a column they don't ((column length) * 2 + 1) formula. For example, I want to create indexes on the zip code column, column data type VARCHAR2 (3), so I have to use 3 * 2 + 1 = 7, (substr (nls_lower (areacode), 1, 7). substr (nls_lower ()) notation is used nested for any function function index. I know that these things are very illogical, but they told me, they use this type of implementation for Axapta.

    Anyway, in this thread, my question is reletad to function function with index index skip scan, not logical bussiness, because I can not change the business logic.

    Also, can you please give hints or clues for multiple function based indexes?

    Thanks for your help.


    SQL > create table my_first as select '201' codeZone, to_char (100 + rownum) account_num, dbms_random.st
    Ring name ('A', 10) from dual connect by level < = 5000;

    Table created.

    SQL > create table my_sec as select '201' codeZone, to_char (100 + rownum) account_num, dbms_random.st

    Ring name ('A', 10) from dual connect by level < = 5000;

    Table created.

    SQL > alter table my_first change account_num varchar2 (12);

    Modified table.


    SQL > alter table my_sec change account_num varchar2 (12);

    Modified table.

    SQL > alter table my_first change codeZone VARCHAR2 (3);

    Modified table.

    SQL > alter table my_sec change codeZone VARCHAR2 (3);

    Modified table.

    SQL > create index my_first_i on my_first (substr (nls_lower (areacode), 1, 7), substr (nls_lower (account_num), 1, 15));

    The index is created.

    SQL > create index my_sec_i on my_sec (area code, account_num);

    The index is created.

    SQL > analyze table my_first computing statistics for all columns indexed for all indexes.

    Parsed table.

    SQL > analyze table my_sec computing statistics for all columns indexed for all indexes.

    Parsed table.

    SQL > exec dbms_stats.gather_table_stats (USER, 'MY_FIRST');

    PL/SQL procedure successfully completed.

    SQL > exec dbms_stats.gather_table_stats (USER, 'MY_SEC');

    PL/SQL procedure successfully completed.

    SQL > my_first desc;
    Name                                      Null?    Type
    ----------------------------------------- -------- ----------------------------
    CODEZONE VARCHAR2 (3)
    ACCOUNT_NUM VARCHAR2 (12)
    NAME VARCHAR2 (4000)

    SQL > desc my_sec
    Name                                      Null?    Type
    ----------------------------------------- -------- ----------------------------
    CODEZONE VARCHAR2 (3)
    ACCOUNT_NUM VARCHAR2 (12)
    NAME VARCHAR2 (4000)

    SQL > select * from my_sec where account_num = '4000';


    Execution plan
    ----------------------------------------------------------
    Hash value of plan: 1838048852

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

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

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

    |   0 | SELECT STATEMENT |          |     1.    19.     3 (0) | 00
    : 00:01 |

    |   1.  TABLE ACCESS BY INDEX ROWID | MY_SEC |     1.    19.     3 (0) | 00
    : 00:01 |

    |*  2 |   INDEX SKIP SCAN | MY_SEC_I |     1.       |     2 (0) | 00
    : 00:01 |

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


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

    2 - access ("ACCOUNT_NUM" = '4000')
    Filter ("ACCOUNT_NUM" = '4000')


    Statistics
    ----------------------------------------------------------
    1 recursive calls
    0 db block Gets
    Gets 7 compatible
    0 physical reads
    0 redo size
    543 bytes sent via SQL * Net to client
    384 bytes received via SQL * Net from client
    2 SQL * Net back and forth to and from the client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed

    SQL > select * from my_first where substr (nls_lower (account_num), 1: 25) = '4000';


    Execution plan
    ----------------------------------------------------------
    Hash value of plan: 1110109060

    ------------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    ------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT |          |     1.    20.     9 (12) | 00:00:01 |
    |*  1 |  TABLE ACCESS FULL | MY_FIRST |     1.    20.     9 (12) | 00:00:01 |
    ------------------------------------------------------------------------------

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

    1 Filter (SUBSTR (NLS_LOWER ("MY_FIRST". "" "" ACCOUNT_NUM")(, 1, 15) ="4000"
    AND SUBSTR (NLS_LOWER ("ACCOUNT_NUM"), 1, 25) = '4000')


    Statistics
    ----------------------------------------------------------
    15 recursive calls
    0 db block Gets
    Gets 26 consistent
    0 physical reads
    0 redo size
    543 bytes sent via SQL * Net to client
    384 bytes received via SQL * Net from client
    2 SQL * Net back and forth to and from the client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed

    SQL > Select / * + INDEX_SS (MY_FIRST) * / * from my_first where substr (nls_lower (account_num), 1: 25) = '4000';


    Execution plan
    ----------------------------------------------------------
    Hash value of plan: 2466066660

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

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

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

    |   0 | SELECT STATEMENT |            |     1.    20.    17 (6) |
    00:00:01 |

    |*  1 |  TABLE ACCESS BY INDEX ROWID | MY_FIRST |     1.    20.    17 (6) |
    00:00:01 |

    |*  2 |   INDEX SCAN FULL | MY_FIRST_I |     1.       |    16 (7) |
    00:00:01 |

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


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

    1 - filter (SUBSTR (NLS_LOWER ("ACCOUNT_NUM"), 1, 25) = '4000')
    2 - access (SUBSTR (NLS_LOWER ("ACCOUNT_NUM"), 1, 15) = '4000')
    Filter (substr (NLS_LOWER ("ACCOUNT_NUM"), 1, 15) = '4000')


    Statistics
    ----------------------------------------------------------
    15 recursive calls
    0 db block Gets
    857 consistent gets
    0 physical reads
    0 redo size
    543 bytes sent via SQL * Net to client
    384 bytes received via SQL * Net from client
    2 SQL * Net back and forth to and from the client
    0 sorts (memory)
    0 sorts (disk)
    1 rows processed

    Check MoS for a bug with the FBI and Skip Scan - it sounds like it could be a bug.

    On 11.2.0.4 with your sample code 10053 trace shows the optimizer whereas an index FULL scan to the point where she should consider an index SKIP scan for "unique table path".

    A person with 12.1.0.1 practice would like to run your test and see if it's fixed in this version.

    Concerning

    Jonathan Lewis

  • Question on the composite index and index skip scan

    Hello
    I have a confusion.
    I read the post of Burleson on the column of the composite index command (http://www.dba-oracle.com/t_composite_index_multi_column_ordering.htm) where he writes that

    «.. . for composite indexes the most restrictive value of the column (the column with the highest unique values) should be made first to cut down the result set in... »


    But 10g performance tuning book tells the subject INDEX SKIP SCAN:

    "... Index scan Skip allows a composite index that is logically divided into smaller subindex. In Dumpster
    scanning, the first column in the composite index is not specified in the query. In other words, it is ignored.
    The number of logic subindex is determined by the number of distinct values in the first column.

    Skip scanning is advantageous if there are few distinct values in the main column of the composite index and many distinct values in the key do not tip of the index... »

    If design us a composite index according to what said Burleson, then how can we take advantage of index skip scan. These two staements to oppose each other, Don't they?

    Can someone explain this?

    Even if you're not skip scanning, it is best to put the column with less distinct values in the main column of the index.

    If a query specifies two key as predicates of equality columns, it doesn't really matter how columns are sorted in the index.
    If a query specifies a range on a key column, it is most likely on the second column of the index.

    BTW, sometimes even a column 3 or the index of the column 4 is useful. In order to not restrict simply yourself in 2 columns. However, do not create too many clues - especially if there is overlap between the index.

    Hemant K Collette

  • doubt about the Index Skip Scan

    Hi all

    I read the setting of Oracle performance guide (Version 11.2 Chapter 11). I just want to see index skip scan with an example. I created a table called t and inserted the test data. When I asked the table optimizer did not use the index skip scan path.

    Can you please let me know what mistake I am doing here.

    Thanks a lot for your help in advance.

    SQL > create table t (empno number
    2, ename varchar2 (2000)
    3, varchar2 (1) sex
    4, email_id varchar2 (2000));

    Table created

    SQL >
    SQL >-test data
    SQL > insert into t
    2 level, select "suri" | (level), ','suri.king' | level | ' @gmail.com'
    3 double
    4. connect by level < = 20000
    5.

    20000 lines inserted

    SQL >
    SQL > insert into t
    2 Select level + 20000, 'surya ' | (level + 20000), 'F', 'surya.princess'. (level + 20000) : ' @gmail.com '
    3 double
    4. connect by level < = 20000
    5.

    20000 lines inserted

    SQL > create index t_gender_email_idx on t (gender, email_id);

    Index created

    SQL > explain the plan for
    2 Select
    3 t
    4 where email_id = "[email protected]";

    He explained.

    SQL > select *.
    table 2 (dbms_xplan.display);

    PLAN_TABLE_OUTPUT
    ----------------------------------------------------------------------------------------------------------------
    Hash value of plan: 1601196873

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


    |   0 | SELECT STATEMENT |      |     4.  8076 |   103 (1) | 00:00:02 |
    |*  1 |  TABLE ACCESS FULL | T    |     4.  8076 |   103 (1) | 00:00:02 |
    --------------------------------------------------------------------------

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

    1 - Filter ("EMAIL_ID"= "[email protected]")

    Note
    -----
    -dynamic sample used for this survey (level = 2)

    17 selected lines.

    See you soon,.

    Suri

    You have just demonstrated how your execution plan gets screwed up if you do not have your statistics

    SQL > create table t
    () 2
    3 empno number
    4, ename varchar2 (2000)
    5, varchar2 (1) sex
    6, email_id varchar2 (2000)
    7  );

    Table created.

    SQL > insert into t
    2 Select level, "suri" | (level), ', 'suri.king'| level | ' @gmail.com'
    3 double
    4. connect by level<=>
    5.

    20000 rows created.

    SQL > insert into t
    2 Select level + 20000, 'surya ' | (level + 20000), 'F', 'surya.princess'. (level + 20000) : ' @gmail.com'
    3 double
    4. connect by level<=>
    5.

    20000 rows created.

    SQL > create index t_gender_email_idx on t (gender, email_id);

    The index is created.

    SQL > set autotrace traceonly explain
    SQL >
    SQL > select *.
    2 t
    3 where email_id = "[email protected]";

    Execution plan
    ----------------------------------------------------------
    Hash value of plan: 2153619298

    --------------------------------------------------------------------------
    | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
    --------------------------------------------------------------------------
    |   0 | SELECT STATEMENT |      |     3.  6057.    79 (4) | 00:00:01 |
    |*  1 |  TABLE ACCESS FULL | T    |     3.  6057.    79 (4) | 00:00:01 |
    --------------------------------------------------------------------------

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

    1 - Filter ("EMAIL_ID"= "[email protected]")

    Note
    -----
    -dynamic sampling used for this statement

    SQL > exec dbms_stats.gather_table_stats (user, 't', cascade-online true)

    PL/SQL procedure successfully completed.

    SQL > select *.
    2 t
    3 where email_id = "[email protected]";

    Execution plan
    ----------------------------------------------------------
    Hash value of plan: 2655860347

    --------------------------------------------------------------------------------------------------
    | ID | Operation | Name               | Lines | Bytes | Cost (% CPU). Time |
    --------------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT |                    |     1.    44.     1 (0) | 00:00:01 |
    |   1.  TABLE ACCESS BY INDEX ROWID | T                  |     1.    44.     1 (0) | 00:00:01 |
    |*  2 |   INDEX SKIP SCAN | T_GENDER_EMAIL_IDX |     1.       |     1 (0) | 00:00:01 |
    --------------------------------------------------------------------------------------------------

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

    2 - access ("EMAIL_ID"= '[email protected]')
    filter ("EMAIL_ID"= "[email protected]")

    SQL >

  • INDEX RANGE SCAN against INDEX SKIP SCAN

    Dear,

    Let me introduce you to the model, and then I'll ask my question
    SQL> select * from v$version;
    
    BANNER
    ----------------------------------------------------------------
    Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
    PL/SQL Release 10.2.0.5.0 - Production
    CORE    10.2.0.5.0      Production
    TNS for Solaris: Version 10.2.0.5.0 - Production
    NLSRTL Version 10.2.0.5.0 - Production
    
    SQL> create table t1
      2     as select rownum                  id1,
      3      mod(rownum,1000)                  id2,
      4      lpad(rownum,10,'0')              small_vc,
      5      rpad('x',1000)                   padding
      6  from dual
      7  connect by level <= 10000;
    
    Table created.
    
    SQL> create index t1_ind_id1 on t1(id1);
    
    Index created.
    
    SQL> create index t1_ind_id2 on t1(id2, id1);
    
    Index created.
    
    SQL> exec dbms_stats.gather_table_stats(user, 't1', cascade => true);
    
    PL/SQL procedure successfully completed.
    
    SQL> select index_name, num_rows, clustering_factor
      2  from user_indexes
      3  where index_name in ('T1_IND_ID1','T1_IND_ID2');
    
    INDEX_NAME                       NUM_ROWS CLUSTERING_FACTOR
    ------------------------------ ---------- -----------------
    T1_IND_ID1                          10000              1429
    T1_IND_ID2                          10000             10000
    
    
    SQL> select *
      2  from t1
      3  where id1=6;
    
     Execution Plan
    ----------------------------------------------------------
    Plan hash value: 2367654148
    
    ------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |            |     1 |  1019 |     2   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1         |     1 |  1019 |     2   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | T1_IND_ID1 |     1 |       |     1   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("ID1"=6)
    So far so good.

    What I want is to know how I can reproduce an example of real life where an index skip scan has been chosen by the CBO despite the presence of the index 'adequate '.

    Here, below, I tried several examples
    SQL> alter index t1_ind_id1 unusable;
    
    Index altered.
    
    SQL> select *
      2  from t1
      3  where id1=6;
    
      Execution Plan
    ----------------------------------------------------------
    Plan hash value: 2497247906
    
    ------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |            |     1 |  1019 |  1004   (1)| 00:00:03 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1         |     1 |  1019 |  1004   (1)| 00:00:03 |
    |*  2 |   INDEX SKIP SCAN           | T1_IND_ID2 |     1 |       |  1003   (1)| 00:00:03 |
    ------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("ID1"=6)
           filter("ID1"=6)
    It's predictable. Let replace them the usable index and change its grouping factor
    SQL> alter index t1_ind_id1 rebuild;
    
    Index altered.
    
    SQL> select *
      2  from t1
      3  where id1=6;
    
         
    Execution Plan
    ----------------------------------------------------------
    Plan hash value: 2367654148
    
    ------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |            |     1 |  1019 |     2   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1         |     1 |  1019 |     2   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | T1_IND_ID1 |     1 |       |     1   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("ID1"=6)
    
    SQL> exec dbms_stats.set_index_stats(user, 'T1_IND_ID1',clstfct => 20000);
    
    PL/SQL procedure successfully completed.
    
    SQL> select index_name, num_rows, clustering_factor
      2  from user_indexes
      3  where index_name in ('T1_IND_ID1','T1_IND_ID2');
    
    INDEX_NAME                       NUM_ROWS CLUSTERING_FACTOR
    ------------------------------ ---------- -----------------
    T1_IND_ID1                          10000             20000
    T1_IND_ID2                          10000             10000
    
    
    SQL> select *
      2  from t1
      3  where id1=6;
    
        
    Execution Plan
    ------------------------------------------------------------------------------------------
    Plan hash value: 2367654148
    ------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |            |     1 |  1019 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1         |     1 |  1019 |     3   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | T1_IND_ID1 |     1 |       |     1   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("ID1"=6)
    Still without success to produce an INDEX SKIP SCAN on T1_IND_ID2 in the presence of the T1_IND_ID1 index

    Any suggestions?

    Thank you

    Mohamed Houri
    www.hourim.WordPress.com

    What I want is to know how I can reproduce an example of real life where an index skip scan has been chosen by the CBO despite the presence of the 'adequate' index

    If, on behalf of the investigation, trying to 'force' the index skip scan, you must do two things:

    1. change the factor of grouping of TI_IND_ID1 to make it more expensive.

    While Hemant and Nikolay make good points on the fact that the grouping factor SHOULD BE irrelevant for a search of a single line, you are using a non-unique index is still part of the calculation of costs for a range scan.

    It had been a unique index so the factor of grouping of piracy would have been ineffective.

    But because only the cost calculation involves selectivity * factor clustering, you must change it by an order of magnitude (relevant to num_distinct obviously) to make significant change.

    For example:

    SQL> exec dbms_stats.set_index_stats(user, 'T1_IND_ID1',clstfct => 20000000);
    
    PL/SQL procedure successfully completed.
    
    SQL> explain plan for
      2  select /*+ index(t1 t1_ind_id1) */ *
      3  from t1
      4  where id1=6;
    
    Explained.
    
    SQL> select * from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    ---------------------------------------------------------------------------------------------------------
    Plan hash value: 3180815200
    
    ------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |            |     1 |  1019 |  2002   (1)| 00:00:25 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1         |     1 |  1019 |  2002   (1)| 00:00:25 |
    |*  2 |   INDEX RANGE SCAN          | T1_IND_ID1 |     1 |       |     1   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("ID1"=6)
    
    14 rows selected.
    
    SQL>
    

    This pushes the cost of analysis of the range up above the table scan complete:

    SQL> explain plan for
      2  select *
      3  from t1
      4  where id1=6;
    
    Explained.
    
    SQL>  select * from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    -----------------------------------------------------------------------------------------------
    Plan hash value: 3617692013
    
    --------------------------------------------------------------------------
    | Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    --------------------------------------------------------------------------
    |   0 | SELECT STATEMENT  |      |     1 |  1019 |   322   (1)| 00:00:04 |
    |*  1 |  TABLE ACCESS FULL| T1   |     1 |  1019 |   322   (1)| 00:00:04 |
    --------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       1 - filter("ID1"=6)
    
    13 rows selected.
    
    SQL>
    

    So, now to the next step.

    2. we need to artificially reduce the cost of the analysis of Skip - and the best way to do that is by changing the separate issue of the main column in the index (currently 1000):

    SQL> begin
      2     DBMS_STATS.SET_COLUMN_STATS
      3     (ownname       => USER,
      4      tabname       => 'T1',
      5      colname       => 'ID2',
      6      partname      => NULL,
      7      stattab       => NULL,
      8      statid        => NULL,
      9      distcnt       => 1,
     10      density       => 1,
     11      nullcnt       => 0,
     12      srec          => NULL,
     13      avgclen       => 4,
     14      flags         => NULL,
     15      statown       => NULL,
     16      no_invalidate => FALSE,
     17      force         => TRUE);
     18  end;
     19  /
    
    PL/SQL procedure successfully completed.
    
    SQL> 
    

    As a Skip Scan is now taken over by default:

    SQL> explain plan for
      2  select *
      3  from t1
      4  where id1=6;
    
    Explained.
    
    SQL> select * from table(dbms_xplan.display);
    
    PLAN_TABLE_OUTPUT
    ---------------------------------------------------------------------------------------------------
    Plan hash value: 3198394326
    
    ------------------------------------------------------------------------------------------
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |            |     1 |  1019 |     3   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1         |     1 |  1019 |     3   (0)| 00:00:01 |
    |*  2 |   INDEX SKIP SCAN           | T1_IND_ID2 |     1 |       |     2   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("ID1"=6)
           filter("ID1"=6)
    
    15 rows selected.
    
    SQL>
    

    Hope this helps

    Published by: Dom Brooks on October 24, 2012 12:49
    Reformulated

  • index skip scan

    Hi all
    excerpt from the page of doc guide 11-18 of rel2 11g performance tuning:
    Skip scanning is advantageous when there are few distinct
    values in the leading column of the composite index and many distinct values in the
    nonleading key of the index
    Anyone could explain it means by "nonleading key of the index?

    Best regards
    Val

    The key to an index is all the columns included in the index. The 'leader' or keys are the first column in the index. So, with an index on col1, col2, col3, you could make a request like:

    select * from table
    where col1 = value
    

    and have it use the index for a range scan. In this case, col1 is the main key. You could also do:

    select * from table
    where col1 = value and
          col2 = value
    

    In this case, col1 and col2 run keys. However, something like:

    select * from table
    where col2 = value and
          col3 = value
    

    does not use the main key to the index. According to a number of factors, Oracle may be able to skip scan this index to respond to your request.

    John

  • Estimates of cardinality for index range scan with bind variables

    Oracle 11.2.0.4

    I am struggling to explain that the cardinality estimates for a scan of the index systematic range when using the bind variable.

    Consider the following query:

    SELECT /*+ INDEX(t1) */ *
    FROM   t1
    WHERE  source_id <= ?;
    
    

    Cardinalities for the INDEX RANGE SCAN and ACCESS of the TABLE are the same for different literal predicates, for example, source_id < = 5:

    ------------------------------------------------------------------------------------
    | Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |      |    50 |   350 |    12   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1   |    50 |   350 |    12   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | IX1  |    50 |       |     2   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("SOURCE_ID"<=5)
    
    

    If a variable binding is used instead of a literal, the overall selectivity is 5%. However, why the optimizer based on CSSTidy gives a cardinality estimated 11 for the scan of the index systematic range? As with the predicates literal, surely the cardinalities of the index range scan and access table should be the same?

    ------------------------------------------------------------------------------------
    | Id  | Operation                   | Name | Rows  | Bytes | Cost (%CPU)| Time     |
    ------------------------------------------------------------------------------------
    |   0 | SELECT STATEMENT            |      |    50 |   350 |     5   (0)| 00:00:01 |
    |   1 |  TABLE ACCESS BY INDEX ROWID| T1   |    50 |   350 |     5   (0)| 00:00:01 |
    |*  2 |   INDEX RANGE SCAN          | IX1  |    11 |       |     2   (0)| 00:00:01 |
    ------------------------------------------------------------------------------------
    
    Predicate Information (identified by operation id):
    ---------------------------------------------------
    
       2 - access("SOURCE_ID"<=TO_NUMBER(:A))
    
    

    Unit test code:

    CREATE TABLE t1
    ( id NUMBER
    , source_id NUMBER
    );
    
    CREATE INDEX ix1 ON t1 (source_id);
    
    INSERT INTO t1
    SELECT level
         , ora_hash(level,99)+1
    FROM   dual
    CONNECT BY level <= 1000;
    
    exec DBMS_STATS.GATHER_TABLE_STATS(user,'T1')
    
    EXPLAIN PLAN FOR
    SELECT /*+ INDEX(t1) */ *
    FROM   t1
    WHERE  source_id <= 5;
    SELECT * FROM TABLE(dbms_xplan.display);
    
    EXPLAIN PLAN FOR
    SELECT /*+ INDEX(t1) */ *
    FROM   t1
    WHERE  source_id <= :a;
    SELECT * FROM TABLE(dbms_xplan.display);
    
    

    There are various places where the optimizer uses an assumption, and lie unpeekable (and of Villa "unknowable value") introduced guess.

    For unpeekable binds the conjecture for column<= {unknown}="" is="" 5%="" for="" table="" access="" (hence="" 50="" rows="" out="" of="" 1,000),="" but="" it's="" 0.009="" for="" index_column=""><= {unknown},="" which="" means="" i="" was="" expecting="" to="" see="" 9="" as="" the="" row="" estimate="" on="" the="" index="" range="">

    I just ran some quick tests, and EXPLAIN the PLAN seems to just use 0.011 selectivity in this case (in different versions of Oracle) although if we do the bind variable unpeekable at run time (and sample dynamic block etc.) optimization for execution is 0.009%.

    Concerning

    Jonathan Lewis

    Update: and this is a very old reference to the 0.009 (and 0.0045 for ' between the ' when it is applied to a clue: cost based Oracle - access Chapter 4 single B-tree )

  • Difference between Index Full Scan, and Scan select Index Full

    Quick Index Full Scan is an example of Index Full Scan, then what are the differences between Fast Full Index Scan and Index Full Scan. I have traveled the official documentation, but found it a bit complex, that no simple explanation will be great. Thanks in advance!

    Go to http://tahiti.oracle.com, select database Oracle 11g Release 2 (11.2) enter fast full scan small index in the 'Search' box, you may decide to read the results of three or four, but the fourth is setting performance Guide: the query optimizer

    Repeat the process for the analysis of comprehensive index of search term.

    Concerning

    Jonathan Lewis

  • Explain plan - index range scan lines increase while access to the table by the row id

    I use Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64 bit Production. Please help me understand why the rows returned from the index range scan is 3 but access the table by row index 10155 id. Please refer to explain the plan ID 7 and 8.


    PLAN_TABLE_OUTPUT                                                                                   
    ----------------------------------------------------------------------------------------------------
                                                                                                        
    ---------------------------------------------------------------------------------------------       
    | Id  | Operation                      |  Name                      | Rows  | Bytes | Cost  |       
    ---------------------------------------------------------------------------------------------       
    |   0 | SELECT STATEMENT               |                            |  8308 |   446K|  4408 |       
    |   1 |  SORT ORDER BY                 |                            |  8308 |   446K|  4408 |       
    |*  2 |   HASH JOIN                    |                            |  8308 |   446K|  4316 |       
    |*  3 |    HASH JOIN                   |                            |  8189 |   255K|  2256 |       
    |*  4 |     INDEX FAST FULL SCAN       | TUNE_CHD_07                |  8071 | 72639 |   199 |       
    |*  5 |     TABLE ACCESS BY INDEX ROWID| CLM_HDR_CLM_LN_STATUS      | 10155 |   228K|  2055 |       
    |*  6 |      INDEX RANGE SCAN          | XIF3CLM_HDR_CLM_LN_STATUS  |     3 |       |   120 |       
    |*  7 |    TABLE ACCESS BY INDEX ROWID | CLM_HDR_CLM_LN_STATUS      | 10155 |   228K|  2055 |       
    |*  8 |     INDEX RANGE SCAN           | XIF3CLM_HDR_CLM_LN_STATUS  |     3 |       |   120 |       
    ---------------------------------------------------------------------------------------------       
                                                                                                        
    Predicate Information (identified by operation id):                                                 
    ---------------------------------------------------                                                 
                                                                                                        
       2 - access("CHCLS"."CLAIM_HEADER_SID"="CHCLS1"."CLAIM_HEADER_SID")                               
       3 - access("CHD"."CLAIM_HEADER_SID"="CHCLS"."CLAIM_HEADER_SID")                                  
       4 - filter("CHD"."CLM_TYPE_CID"=2)                                                               
       5 - filter("CHCLS"."CLAIM_LINE_SID" IS NULL AND "CHCLS"."TO_DATE" IS NULL)                       
       6 - access("CHCLS"."STATUS_TYPE_CID"=8 AND "CHCLS"."STATUS_CID"=71)                              
       7 - filter("CHCLS1"."CLAIM_LINE_SID" IS NULL AND "CHCLS1"."TO_DATE" IS NULL)                     
       8 - access("CHCLS1"."STATUS_TYPE_CID"=2 AND "CHCLS1"."STATUS_CID"=130)                           
                                                                                                        
    Note: cpu costing is off                                                                            
    Thanks a lot for all the help...
  • Keithley UNFINISHED 420 'query' error Max scan for instruments

    Hello!

    We have a system for about 9 years. There is a PC with Windows XP and LabView 6.1. In the PC, there is a card GPIB PCI, and via the GPIB cable, 8 Keithley DVMs (including models like 2010, 2400, 2182) connected. A few days ago this old system began to malfunction. There are 4 screws are parallel on this old system - worked fine until now- but none of them are now able to communicate with the Keithley instruments.

    I got a virus check, also verified WinXP, checking the memory and so on (we had several BSOD also on the old PC). Because I couldn't trace the problem in the old system, I decided to check into the Keithleys with a new configuration.

    I have a new PC with a card GPIB + PCI and LabView 2010. I connected this new PC line above with the Keithley instruments GPIB. (old PC disconnected) When I open MAX and I navigate to the GPIB controller, and I scan for instruments, all DVMs Keithley started a signal sound and displays "error 420" on their screens. And I agree I get in MAX.

    So now I have to think that it is a hardware error? Since I have the same problem of communication the DVMs in this new configuration PC...?

    A defective digital Voltmeter can make unreliable GPIB communication? I have no idea where to go now...

    Moreover, in the case of the controller old PCs, I don't get any visible error, only the screw do not communicate (time error). I think I will also try to use the old system again, I will connect the new PC to GPIB channel and listen in the communication with the GPIB Analyzer functionality.

    Thanks for the tips!

    Basic troubleshooting: have you tried simply as an instrument both for the bus connecting? You can also check the cables.

  • Index Full scan

    Hi guys, I want to know how a Full Index Scan works in detail. It always parses the first block of sheets to the last block of sheets (all blocks) in the index, regardless of the place where the requirement is to say even if I have only one line satisfying the condition he analyzes all the index blocks?

    You actually store what appear to be of the numbers in a column of type char?

    My guess is that maybe done GOLD optimizer based on CSSTidy think that he cannot do a scan of the index systematic range

  • index range scan and full scan limited index

    Hi master,

    I always think to what is the difference between index scan and scan of comprehensive systematic index range...


    comprehensive index analysis applied to the full index sheet, block and root structure.

    How systematic index scan range works internally? How is it different from complete systematic index scan? When to use the scan of the index systematic range? which is expensive?

    I like what internals discuss some docs on these, but nobody... someone knows about any link lewis j. wrote about these scans?

    will be useful

    Thanks and greetings
    VD

    Vikrant dixit says:
    I always think to what is the difference between index scan and scan of comprehensive systematic index range...

    There is essentially no difference.

    Based on a seed value, Oracle checks the root block using the partial keys stored to select which block from the next down level (typically a layer of blocks of branch) to go to.

    Since the relevant branch block, she uses the partial keys to identify which block in the level down to go to (usually a block of sheets).

    When he reached a block of sheets, it can find the first relevant key value, then scroll through the list of keys to jump to the table. If it reaches the end of the block of sheets, it uses the "next" pointer to reach the next block of relevant leaves.

    Because the optimizer has enough information to establish a baseline and a final value for the analysis, the runtime can keep journal journal moving until it hits the sheet "stop".

    The only difference between the full analysis and analysis of the range is the full scan down through the branches to the first sheet of the index and traverses the index to the last sheet. (Indeed, the starting value is less "Infinity" and the end value is "more Infinity".)

    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

  • How to Auto poplulated fields of index for scanning profiles


    Hello

    I worked on Webcenter Capture 11.1.1.8.0, we have recently configured profiles customer capture and we have also set up Email profiles and analyze the profile.

    My concerns here, how to index get fields automatically filled for individual profiles of customers during the analysis of the images of the invoice.

    currently I feed the index on manual work fields. We want to avoid the manual work and it must be filled by full Auto the index fields in the analysis of the invoice for each individual customer profiles. Different index values should appearance for differnent customer profiles.

    the above requirement, is there configure everything can be done in Capture console. We must make this resolution with Console to capture only not to provide all the scripts. We do not want to use Scripts for this requirement.

    Please help me. This something urgent for the business scenario.

    If your question is: "How can I apply different default values of metadata based on the customer profile?" then I think that you will have to do so via the import processor (if you use is not a scanner), recognition or scripts custom.

    You can set up a default for each metadata field, but this won't cut it for you.

    You can probably do this through recognition jobs processor by creating a different one for each customer profile and defining your customer post-processor on his work of processor rcgn correspondent.

    Hope this helps,

    -ryan

    Sound clips SENA

  • Ineffective basic querying

    Hi all

    I have a basic requirement of the registration of all VMS on each Virtualcentre with their host name and cluster.

    And it's a way to do so;

    Get - VM | Select Name, @{N = 'Cluster'; {E = {Get-Cluster - VM $_}}, @{N = "ESX host"; {E = {Get-VMHost - VM $_}}

    But this seems very slow and I guess I'm going in loops every time to get the basic information that I suppose I could get only once as a property of the machine?

    If any of you have a better way to do it, I'd appreciate it.  To be honest, I need only really name host as I can that maps to a cluster name.  But even;

    Get - VM | Select Name, @{N = "ESX host"; {E = {Get-VMHost - VM $_}}

    is slow (and probably ineffective)...

    Apologies for stupid question in advance!

    Thank you very much

    Simon

    This should be faster

    Get - VM | Select Name,@{N="Host; E={$_. $host.name}}

    PS: there is no stupid questions :-)

  • Query Indexing internal

    Hello

    Can someone in the know tell me if my theory is correct? I have a script that runs through the document with a "find" for each asterisk in a certain style. It replaces the asterisk with a reference to "asterisk" in an endnote that it creates based on the previous 6 words or more. It also creates a cross-reference from the note the asterisk (so there are "clickable" notes back and forth)

    Now, when I'm in a loop of 'search', I do something like this:

    for (var i = 0; i < found.length; i ++) {}

    Replace [i] found a reference

    Take the previous few behind found words [i] .insertionPoints [0]

    }

    This works well for the first asterisk. But for the second one loses a character from previous words. And for the third, I lose two characters.

    ID uses a fixed character - rather than some internal pointer index in the document - reference to each element in "found", so that for example if I add "ABCDE" after having found [0], found .characters [1] [0] no longer the second asterisk, but something 5 tanks in front of the second asterisk? If that's true, how can I get the asterisk that should be found [1]?

    The strange thing is, I did it with notes (using story.footnotes.length) and appears not to happen.

    Sorry if this is rather obscure, I hope someone does what I mean.

    Thank you

    Alex

    It's an effect known; This is because the found picture is not "online". In other words: If you have an array of items, and you change one, the next (s) don't adjust automatically to the new State.

    The trick is to treat your items from the last to the first. Instead of

    ukzembla wrote:

    for (var i = 0; i)< found.length="" ;="" i++="" )="">

    ...

    Use this

    for (var i=found.length-1; i >= 0; i--) {
      ...
    

Maybe you are looking for

  • Firefox 31.3 incorrectly identifies as obsolete Flash plugin

    After the update to Firefox 31.3.0 ESR and ESR Flash 13.0.0.259, I get a message out of date, but there is no more recent version of Flash available. Firefox seems to identify the wrong Flash version it is not outdated, he even said there is no updat

  • Download windows10

    I recently downloaded Windows 10 on my pc, I have a problem because my continued pc go in safe mode, so I rang microsoft support, the lady told me to push the windows icon and type msconfig. After doing this my pc keeps just attempt to run windows, b

  • No active mixer available (audio driver)

    Hello After installation of windows xp with service pack 3, the sound system tray icon is gone and it displays a message (without active mixer available) when I try to drag and drop to control panel - sound and audio device.I checked the BIOS setting

  • Cannot install itune in vista.

    I use Windows Vista.  When I try to install the latest itune.  I got a message error "there is a problem with this Windows Installation Package.  A program required for this istall complete could not be run. "what program should I?

  • All stuck in 169.254.106.192 network adapters IP address help!

    Hello I tried everything to fix this. First of all it is just the wireless card for my laptop that got the question, so I went to an Ethernet directly between a router and that possessed the same auto config ip. Then, I used my tp link TL-WN722N usb