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

Tags: Database

Similar Questions

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

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

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 )

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

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 >

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

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)
```

A range scan using rather jump scan
Hello
In oracle 10g (10.2.0.1.0)
I have a table with a composite index based on 2 columns.

E.g.:

Table1 (number p1, d1 date, c2 varchar2 (10))

create indexes on table1 (d1, c2) table1x

in the query:

Select p1
FROM table1
where d1 between sysdate-10 and sysdate
and c2 = 'x '.

In this case, the optimizer chose to use an index skip scan (to use the second column which is c2) instead of using an analysis of index on the d1 column range.

I tried to use the NO_INDEX_SS indicator (table 1, table1x), so NO index has been used and the optimzer went for a full table scan.

Is there a way to force the optimzer use instead the scan interval on d1 or jump can be downloaded on C1?

Thank you...

AK
A sweeping break can be very effective. Something that I suspect you now know after reading the blog of Richard Foote.

My instinct would be to leave it alone based on what I've seen so far.

Performance problem, same range scan different execution time

Oracle 11 GR 1 material, execute queries within seconds of each other.

I have 2 questions that are logically the same. Even the explain command plans are very similar, except the other indicates a range index scan doing much more work than the first. The table is an IOT with deal_bucket_id and datetime as PK (in that order).

TKPROF output below:

select count(*) from deal_bucket_detail where deal_bucket_id

in

(815

,     816

,     817

,     818

...

,     997)

and datetime between to_date('01-JUL-08','dd-MON-rr') and to_date('01-JAN-09','dd-MON-rr')



call     count       cpu    elapsed       disk      query    current        rows

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

Parse        1      0.00       0.00          0          0          0           0

Execute      1      0.00       0.00          0          0          0           0

Fetch        2      0.79       2.24       2936       3551          0           1

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

total        4      0.79       2.24       2936       3551          0           1



Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: 43  



Rows     Row Source Operation

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

      1  SORT AGGREGATE (cr=3551 pr=2936 pw=2936 time=0 us)

1430928   FILTER  (cr=3551 pr=2936 pw=2936 time=380920 us)

1430928    INLIST ITERATOR  (cr=3551 pr=2936 pw=2936 time=372057 us)

1430928     INDEX RANGE SCAN PK_DEAL_BUCKET_DETAIL (cr=3551 pr=2936 pw=2936 time=8782 us cost=1203 size=4069596 card=339133)(object id 14199)





Elapsed times include waiting on following events:

  Event waited on                             Times   Max. Wait  Total Waited

  ----------------------------------------   Waited  ----------  ------------

  SQL*Net message to client                       2        0.00          0.00

  db file sequential read                      2936        0.02          1.49

  SQL*Net message from client                     2        0.00          0.00

********************************************************************************





select count(*) from deal_bucket_detail where deal_bucket_id

between 815 and 997

and datetime between to_date('01-JUL-08','dd-MON-rr') and to_date('01-JAN-09','dd-MON-rr')



call     count       cpu    elapsed       disk      query    current        rows

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

Parse        1      0.00       0.00          0          0          0           0

Execute      1      0.00       0.00          0          0          0           0

Fetch        2      3.70       8.86      29199      26986          0           1

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

total        4      3.70       8.86      29199      26986          0           1



Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: 43  



Rows     Row Source Operation

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

      1  SORT AGGREGATE (cr=26986 pr=29199 pw=29199 time=0 us)

1430928   FILTER  (cr=26986 pr=29199 pw=29199 time=6986078 us)

1430928    INDEX RANGE SCAN PK_DEAL_BUCKET_DETAIL (cr=26986 pr=29199 pw=29199 time=6977063 us cost=45208 size=5195748 card=432979)(object id 14199)



Elapsed times include waiting on following events:

  Event waited on                             Times   Max. Wait  Total Waited

  ----------------------------------------   Waited  ----------  ------------

  SQL*Net message to client                       2        0.00          0.00

  db file sequential read                       219        0.04          0.08

  db file parallel read                          35        0.04          0.32

  db file scattered read                        211        0.10          5.02

  SQL*Net message from client                     2        0.00          0.00

********************************************************************************

How can I work on why the second query is much more work than the first?

Published by: SamB on August 5, 2009 18:09

The two make an index range scan, but another index range scan.
Query 1: inlist iterator with range of index analysis for 1 value, because of the hard-coded values.
Query 2: analysis of range of index for all values, starting at the bottom, thanks to between.

-------------
Sybrand Bakker
Senior Oracle DBA

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

scan of the index systematic range

Hello
I read about the differences between the systematic index scan range, single scan, skip scan.
According to the docs, to how the CBO Evaluates in-list of iterators, http://docs.oracle.com/cd/B10500_01/server.920/a96533/opt_ops.htm
, I can see that

"The IN -list iterator is used when a query contains a IN clause with values." The execution plan is the same which would result for a statement of equality clause instead of IN with the exception of an extra step. This step occurs when the IN -list iterator feeds section of equality with the unique values of the IN -list. »

Of course, the doc is Oracle9i Database. (I do not find it in the docs of 11 g)
And the example 2-1 list iterators initial statement, shows that is used in the INDEX RANGE SCAN.

On my Oracle 11 GR 2 database, if I issue a statement similar to the example of the doc, so: select * from employees where employee_id in (7076, 7009, 7902), I see that it uses a SINGLE SCAN

On Oracle Performance Tuning: the Index access methods: Oracle Tuning Tip #11: Unique Index Scan , I read that

If Oracle should follow the Index Unique Scan, and then in SQL, equality operator (=) must be used. If any operator is used in other than op_Equality, then Oracle cannot impose this Unique Index Scan.

(and I think this sentence is somewhere in the docs also).
Thus, when using predicates in the list, why in my case Oracle used the unique scan on primary key column index? Because it wasn't a level playing field.
Thank you.

It is Internet... find us a lot of information a lot but don't know who to trust.

Exactly! It is thought, you should ALWAYS have in the back of your mind when you visit ANY site (no matter the author), read a book or document, listen to no matter WHAT presentation or read responses from forum (that's me included).

All sources of information can and will be errors, omissions and inaccuracies. An example which is used to illustrate a point can involve/suggest that it applies to the related points as well. It's just not possible to cover everything.

Your post doc 9i is a good example. The earliest records (even 7.3 always available online docs) often have a LOT of better explanations and examples of basic concepts. One of the reasons is that there were not nearly that many advanced concepts that explaining necessary; they did not exist.

michaelrozar17 just posted a link to a 12 c doc to refute my statement that the article you used was bad. No problem. Maybe this doc has been published because of these lines:

The database performs a unique sweep when the following conditions apply:
- A query predicate refers to all columns in a unique index using an equality operator key, such as WHERE prod_id=10 .
- A SQL statement contains a predicate of equality on a column referenced in an index created with the CREATE UNIQUE INDEX statement.
The authors mean that a single scan is ONLY performed for these conditions? We do not know. There could be several reasons that an INLIST ITERATOR has not been included in this list:

1. a LIST is NOT for this use case (what michaelrozar might suggest)

2. the authors were not aware that the CBO may also consider a unique analysis for a predicate INLIST

3. the authors WERE aware but forgot to include INLIST in the document

4. the authors were simply provide the conditions most common where a single sweep would be considered

We have no way of knowing what was the real reason. This does not mean that the document is not reliable.

In the other topic, I posted on the analysis of hard steps, site of BURLESON, and Jonathan contradicted me. If neither Burleson isn't reliable, do not know which author have sufficient credibility... of course, the two Burleson and Jonathan can say anything, it's true I can say anything, of course.

If site X is false, site is fake, Z site is fake... all people should read the documentation only and not other sites?

This is the BEST statement of reality to find the info I've seen displayed.

No matter who is the author, and what credibility that they could rely on the spent items you should ALWAYS keep these statements you comes to mind.

This means you need to do ' trust and verify. " You of 'trust', and then you "checked" and now have a conflict between WORDS and REALITY.

On those which is correct. If your reality is correct, the documentation is wrong. Ok. If your reality is wrong, then you know why.

Except that nobody has posted ANY REALITY that shows that your reality is wrong. IMHO, the reason for this is because the CBO probably MUCH, done a LOT of things that are not documented and that are never explored because there is never no reason to spend time exploring other than of curiosity.

You have not presented ANY reason to think that you are really concerned that a single scan is used.

Back to your original question:

Thus, when using predicates in the list, why in my case Oracle used the unique scan on primary key column index? Because it wasn't a level playing field.

1. why not use a single sweep?

2. what you want Oracle to use instead? A full table scan? A scan of the index systematic range? An index skip scan? A Full Scan index? An analysis of index full?

A full table scan? For three key values? When there is a unique index? I hope not.

A scan of the index systematic range? Look a the doc 12 c provided for those other types of indexes

How the Index range scans work
In general, the process is as follows:
1. Read the root block.
2. Read the bundle branch block.
3. Replacing the following steps until all data is retrieved:
  1. Read a block of sheets to get a rowid.
  2. Read a block to retrieve a table row.
. . .
For example, to analyze the index, the database moves backward or forward through the pads of sheets. For example, an analysis of identifications between 20 and 40 locates the first sheet block that has the lowest value of key that is 20 or more. The analysis produced horizontally through the linked list nodes until it finds a value greater than 40 and then stops.
If that '20' was the FIRST index value and the '40' was the LAST one who reads ALL of the terminal nodes. That doesn't look good for me.

How to index full scans of work

The database reads the root block and then sailed on the side of the index (right or left hand if do a descending full scan) until it reaches a block of sheets. The database then reads down the index, one block at a time, in a sorted order. The analysis uses single e/s rather than I/O diluvium.

Which is about as the last example is not?

How to index Fast Full Scans work

The database uses diluvium I/O to read the root block and all the blocks of leaf and branch. Databases don't know branch blocks and the root and reads the index on blocks of leaves entries.

Seems not much better than the last one for your use case.

Skip index scans

An index skip scan occurs when the first column of a composite index is "skipped" or not specified in the query.

. . .

How Index Skip scan work

An index skip scan logically divides a composite index in smaller subindex. The number of distinct values in the main columns of the index determines the number of logical subindex. The more the number, the less logical subindex, the optimizer should create, and becomes the most effective analysis. The scan reads each logical index separately and "jumps" index blocks that do not meet the condition of filter on the column no leader.

Which does not apply to your use cases; you do not have a composite index, and there is nothing to jump. If Oracle were to 'jump' between the values of the list in it would be still reads these blocks 'inbetween' and them to jump.

Which brings back us to the using a single scan, one at a time, for each of the values in the list in. The root index block will be in the cache after the first value lies, so it only needs to be read once. After that just Oracle detects that the entry of only ONE necessary index. Sounds better than any other variants for me if you are only dealing with a small number of values in the IN clause.

Index of Linguistics cannot SCAN ONE / RANGE 10.2, no work around?

Hello

Christian Antognini, in his book Troubleshooting Oracle Performance, when talking about clues language said:

"Until the database Oracle 10 g Release 2, another limitation is that in order to apply a LIKE
operator, the database engine is not able to take advantage of the linguistic clues. In other words, a
the full index scan or full table scan can be avoided. This limitation is no longer available as of
Oracle Database 11 g."

But it cannot use scan limited unique index also, it seems. This is my test scenario:

Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64 bit Production
With partitioning, OLAP and Data Mining options

SQL> create table test as select to_char(rownum) x,to_char(mod(rownum,1000)) y, cast(' ' as char(100)) z from dual connect by level <= 100000;

Tabla creada.

SQL> exec dbms_stats.gather_table_stats(ownname=>user, tabname=>'TEST', method_opt=>'for all columns size 1', cascade=>true);

Procedimiento PL/SQL terminado correctamente.

SQL> CREATE unique INDEX test_idx ON test(NLSSORT(x,'nls_sort=spanish'));

Índice creado.

SQL> CREATE INDEX test_idx2 ON test(NLSSORT(y,'nls_sort=spanish'));

Índice creado.

SQL> SELECT x FROM test WHERE x = '123';
X
----------------------------------------
123

SQL> @plan
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  5fbncq099nf9g, child number 0
-------------------------------------
SELECT x FROM test WHERE x = '123'

Plan hash value: 217508114

-------------------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------
|*  1 |  TABLE ACCESS FULL| TEST |      1 |      1 |   374   (4)|      1 |00:00:00.04 |    1619 |
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("X"='123')


17 filas seleccionadas.

SQL> SELECT y FROM test WHERE y = '123' order by y;
Y
----------------------------------------
123
.......
.......
123

100 filas seleccionadas.

SQL> @plan
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
SQL_ID  85mu6hvnrvd49, child number 0
-------------------------------------
SELECT y FROM test WHERE y = '123' order by y

Plan hash value: 217508114

-------------------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
-------------------------------------------------------------------------------------------------
|*  1 |  TABLE ACCESS FULL| TEST |      1 |    100 |   375   (4)|    100 |00:00:00.04 |    1625 |
-------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("Y"='123')


17 filas seleccionadas.

SQL> SELECT /*+index(test TEST_IDX) */ x FROM test WHERE x = '123';
X
----------------------------------------
123

SQL> @plan
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------
SQL_ID  1w53svu82whqn, child number 0
-------------------------------------
SELECT /*+index(test TEST_IDX) */ x FROM test WHERE x = '123'

Plan hash value: 4153930100

---------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name     | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
---------------------------------------------------------------------------------------------------------------
|*  1 |  TABLE ACCESS BY INDEX ROWID| TEST     |      1 |      1 | 20755   (1)|      1 |00:00:00.30 |   20683 |
|   2 |   INDEX FULL SCAN           | TEST_IDX |      1 |    100K|   328   (3)|    100K|00:00:00.01 |     320 |
---------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("X"='123')


18 filas seleccionadas.

SQL> SELECT /*+index(test TEST_IDX2) */ y FROM test WHERE y = '123';
Y
----------------------------------------
123
.......
.......
123

100 filas seleccionadas.

SQL> @plan
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------
SQL_ID  37yz5ufq7a3b4, child number 0
-------------------------------------
SELECT /*+index(test TEST_IDX2) */ y FROM test WHERE y = '123'

Plan hash value: 34309412

----------------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name      | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------------
|*  1 |  TABLE ACCESS BY INDEX ROWID| TEST      |      1 |    100 |   100K  (1)|    100 |00:00:00.71 |     100K|
|   2 |   INDEX FULL SCAN           | TEST_IDX2 |      1 |    100K|   286   (4)|    100K|00:00:00.10 |     284 |
----------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("Y"='123')


18 filas seleccionadas.

In the test, you can see that oracle does not use the indexes without suspicion. The reason is that the cost of the plan with FULL SCAN INDEX is higher.

Like Christian said he does not use RANGE SCAN, but it does not use UNIQUE INDEX SCAN also. Does anyone know the bug/Pals in Metalink on this problem? I can't find. No work around?

Thank you very much

Joaquin Gonzalez

Hi Joaquin

No, the reason is that you have not set the settings nls necessary to perform a linguistic operation rather than the binary search operation by default.

Run:

ALTER session set nls_comp = linguistic;

ALTER session set nls_sort = Spanish;

and try again...

See you soon

Richard Foote
http://richardfoote.WordPress.com/

Slow index by using the query. Fast with full table Scan.

Salvation;

(Thanks for the links)

Here's my question correctly formatted.

The query:

SELECT count(1)
from ehgeoconstru  ec 
where ec.TYPE='BAR'  
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') )   
and deathdate is null 
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'

Works on 32 seconds!

Same query, but with an extra where clause:

SELECT count(1)
from ehgeoconstru  ec 
where ec.TYPE='BAR'  
and  ( (ec.contextVersion = 'REALWORLD')     --- ADDED HERE
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) )  
and deathdate is null 
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'

This is 400 seconds.

It should return data from a table, given the conditions.

The database version is Oracle9i Release 9.2.0.7.0

These are the parameters relevant for the optimizer:

SQL> show parameter optimizer

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_dynamic_sampling           integer     1
optimizer_features_enable            string      9.2.0
optimizer_index_caching              integer     99
optimizer_index_cost_adj             integer     10
optimizer_max_permutations           integer     2000
optimizer_mode                       string      CHOOSE

SQL>

Here is the output of the PLAN to EXPLAIN for the first quick query:

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
| Id  | Operation                     |  Name               | Rows  | Bytes | Cost  |
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |                         |           |       |       |
|   1 |  SORT AGGREGATE       |                         |           |       |       |
|*  2 |   TABLE ACCESS FULL   | EHCONS            |       |       |       |
--------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------

   2 - filter(SUBSTR("EC"."strgfd",1,8)<>'[CIMText' AND "EC"."DEATHDATE"
              IS NULL AND "EC"."BIRTHDATE"<=TO_DATE('2009-10-06 11:52:12', 'yyyy
-mm-dd

              hh24:mi:ss') AND "EC"."TYPE"='BAR')

Note: rule based optimization

Here is the output of the EXPLAIN of PLAN for slow queries:

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
   |       |

|   1 |  SORT AGGREGATE              |                             |       |
   |       |

|*  2 |   TABLE ACCESS BY INDEX ROWID| ehgeoconstru      |       |
   |       |

|*  3 |    INDEX RANGE SCAN          | ehgeoconstru_VSN  |       |
   |       |


PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter(SUBSTR("EC"."strgfd",1,8)<>'[CIMText' AND "EC"."DEATHDATE" IS
 NULL AND "EC"."TYPE"='BAR')

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
   3 - access("EC"."CONTEXTVERSION"='REALWORLD' AND "EC"."BIRTHDATE"<=TO_DATE('2
009-10-06

              11:52:12', 'yyyy-mm-dd hh24:mi:ss'))
       filter("EC"."BIRTHDATE"<=TO_DATE('2009-10-06 11:52:12', 'yyyy-mm-dd hh24:
mi:ss'))


Note: rule based optimization

The TKPROF output for this slow statement is:

TKPROF: Release 9.2.0.7.0 - Production on Tue Nov 17 14:46:32 2009

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

Trace file: gen_ora_3120.trc
Sort options: prsela  exeela  fchela  
********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing 
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************

SELECT count(1)
from ehgeoconstru  ec
where ec.TYPE='BAR'
and  ( (ec.contextVersion = 'REALWORLD')
AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) )
and deathdate is null
and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.00     538.12     162221    1355323          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4      0.00     538.12     162221    1355323          0           1

Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 153  

Rows     Row Source Operation
-------  ---------------------------------------------------
      1  SORT AGGREGATE 
  27747   TABLE ACCESS BY INDEX ROWID OBJ#(73959) 
2134955    INDEX RANGE SCAN OBJ#(73962) (object id 73962)

********************************************************************************

alter session set sql_trace=true


call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      1      0.00       0.02          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        1      0.00       0.02          0          0          0           0

Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 153  



********************************************************************************

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      2      0.00       0.02          0          0          0           0
Fetch        2      0.00     538.12     162221    1355323          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        5      0.00     538.15     162221    1355323          0           1

Misses in library cache during parse: 0
Misses in library cache during execute: 1


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        0      0.00       0.00          0          0          0           0

Misses in library cache during parse: 0

    2  user  SQL statements in session.
    0  internal SQL statements in session.
    2  SQL statements in session.
********************************************************************************
Trace file: gen_ora_3120.trc
Trace file compatibility: 9.02.00
Sort options: prsela  exeela  fchela  
       2  sessions in tracefile.
       2  user  SQL statements in trace file.
       0  internal SQL statements in trace file.
       2  SQL statements in trace file.
       2  unique SQL statements in trace file.
      94  lines in trace file.

Published by: PauloSMO on November 17, 2009 04:21

Published by: PauloSMO on November 17, 2009 07:07

Published by: PauloSMO on November 17, 2009 07:38 - title changed to be more correct.

Although your optimizer_mode is choosing, it seems that there are no statistics collected on ehgeoconstru. The absence of estimated costs and estimated row counts of each of the stages of the plan and the "Note: optimization based on rules" at the end of these two plans would tend to confirm this.

Optimizer_mode choose means that if statistics are collected then it will use the CBO, but if no statistic is present in any of the tables in the query, the optimizer to rule will be used. The RBO tends to be happy in the best of the index case. I guess the index ehgeoconstru_VSN contextversion as the main column and also includes the date of birth.

You can either gather statistics on the table (if all other tables have statistics) using dbms_stats.gather_table_stats, or suggest the query to use a full scan instead of index. Another solution would be to apply a function or an operation against the contextversion to prevent the use of the index. something like this:

SELECT COUNT(*)
FROM ehgeoconstru  ec
WHERE ec.type='BAR' and
      ec.contextVersion||'' = 'REALWORLD'
      ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') and
      deathdate is null and
      SUBSTR(ec.strgfd, 1, LENGTH('[CIMText')) <> '[CIMText'

or maybe UPPER (ec.contextVersion) so that would not change the rows returned.

John

Path to XML index table is full table scan

Hi all
I have a version of oracle 11.2.0.4.6 database
Try to implement partitioning on XML indexes.
Creates a table and index partitioned by time stamp as below.
Whenever I'm trying to find the path table makes a full table scan.
I have applied the fix as indicated ( Doc ID 13522189.8 ).
So the recovery is quite slow and partition pruning does not not on XML indexes.
Wondering if anyone has experienced the same problem?
CREATE TABLE INCIDENT
(
INCIDENT_PK NUMBER (14.5).
INCIDENTGROUPING_PK NUMBER (14.5).
INCIDENTTYPE_PK NUMBER (14.5).
SECURITYCLASS_PK NUMBER (14.5).
STAMP OF INCIDENT_DATE,
SYS INCIDENT_DETAIL. XMLTYPE
)
TABLESPACE DATA_TBS_INCIDENT
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE)
64K INITIALS
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
DEFAULT USER_TABLES
)
LOGGING
NOCOMPRESS
PARTITION BY RANGE (INCIDENT_DATE)
(PARTITION SEP2013_WEEK1 VALUES LESS THAN (to_timestamp (' 00:00:00.00 2013-09-08 ',' YYYY-MM-DD HH24:MI:SS.))) FF2')),
PARTITION SEP2013_WEEK2 VALUES LESS THAN (to_timestamp ('2013-09-15 00:00:00.00 ',' YYYY-MM-DD HH24:MI:SS.)) FF2')),
PARTITION SEP2013_WEEK3 VALUES LESS THAN (to_timestamp ('2013-09-22 00:00:00.00 ',' YYYY-MM-DD HH24:MI:SS.)) FF2')),
..........);
CREATE the INDEX INCIDENTxdb_idx
ON corpaudlive. INCIDENT (INCIDENT_detail) INDEXTYPE IS XDB. LOCAL XMLINDEX 10 PARALLEL
PARAMETERS (' PATH TABLE INCIDENT_PATHTABLE (TABLESPACE DATA_TBS_INCIDENT))
PIKEY INDEX INCIDENT_PATHTABLE_PIKEY_IX (TABLESPACE IDX_TBS_INCIDENT)
PATH ID INDEX INCIDENT_PATHTABLE_ID_IX (TABLESPACE IDX_TBS_INCIDENT)
INCIDENT_PATHTABLE_VALUE_IX VALUE INDEX (TABLESPACE IDX_TBS_INCIDENT)
ORDER KEY INDEX INCIDENT_PATHTABLE_KEY_IX (TABLESPACE IDX_TBS_INCIDENT)
Paths (INCLUDE (//forename //surname //postcode //dateofbirth //street //town))');
SQL > explain the plan for
2 Select INCIDENT_pk in INCIDENT where XMLEXISTS ('/ / name [text () = 'john']' by the way of INCIDENT_detail)
3 and XMLEXISTS ("/ / name [text () 'clark' =]' by the way of INCIDENT_detail")
4 and a.INCIDENT_date between TO_TIMESTAMP (January 10, 2014 ',' DD/MM/YYYY "")
5 and TO_TIMESTAMP (September 10, 2014 ',' DD/MM/YYYY ');
He explained.
Elapsed time: 00:00:02.77
SQL > select * from table (dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 123057549
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation                                       | Name                           | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |    TQ | IN-OUT | PQ Distrib.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                                |     1.    70. 1803 (5) | 00:00:22 |       |       |        |      |            |
|   1. COORDINATOR OF PX |                                |       |       |            |          |       |       |        |      |            |
|   2.   PX SEND QC (RANDOM). : TQ10003 |     1.    70. 1803 (5) | 00:00:22 |       |       | Q1, 03 | P > S | QC (RAND) |
|   3.    SEMI NESTED LOOPS.                                |     1.    70. 1803 (5) | 00:00:22 |       |       | Q1, 03 | SVCP |            |
|   4.     NESTED LOOPS |                                |     1.    57. 1800 (5) | 00:00:22 |       |       | Q1, 03 | SVCP |            |
|   5.      VIEW                                       | VW_SQ_1                        |   239. 5975 | 1773 (5) | 00:00:22 |       |       | Q1, 03 | SVCP |            |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|   6.       UNIQUE HASH |                                |   239. 25334 |            |          |       |       | Q1, 03 | SVCP |            |
|   7.        RECEIVE PX |                                |   239. 25334 |            |          |       |       | Q1, 03 | SVCP |            |
|   8.         PX SEND HASH | : TQ10002 |   239. 25334 |            |          |       |       | Q1, 02 | P > P | HASH |
|   9.          UNIQUE HASH |                                |   239. 25334 |            |          |       |       | Q1, 02 | SVCP |            |
| * 10 |           HASH JOIN |                                |   239. 25334 | 1773 (5) | 00:00:22 |       |       | Q1, 02 | SVCP |            |
| 11.            KIND OF BUFFER.                                |       |       |            |          |       |       | Q1, 02 | ISSUE |            |
| 12.             RECEIVE PX |                                |     1.    22.     3 (0) | 00:00:01 |       |       | Q1, 02 | SVCP |            |
| 13.              PX SEND BROADCAST | : TQ10000 |     1.    22.     3 (0) | 00:00:01 |       |       |        | S > P | BROADCAST |
| 14.               TABLE ACCESS BY INDEX ROWID | X$ PT74MSS0WBH028JE0GUCLBK0LHM4 |     1.    22.     3 (0) | 00:00:01 |       |       |        |      |            |
| * 15 |                INDEX RANGE SCAN | X$ PR74MSS0WBH028JE0GUCLBK0LHM4 |     1.       |     2 (0) | 00:00:01 |       |       |        |      |            |
| * 16.            HASH JOIN |                                | 12077 |   990K | 1770 (5) | 00:00:22 |       |       | Q1, 02 | SVCP |            |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 17.             RECEIVE PX |                                |   250K |    10 M |    39 (0) | 00:00:01 |       |       | Q1, 02 | SVCP |            |
| 18.              PX SEND BROADCAST | : TQ10001 |   250K |    10 M |    39 (0) | 00:00:01 |       |       | Q1, 01 | P > P | BROADCAST |
| 19.               SYSTEM PARTITION ALL |                                |   250K |    10 M |    39 (0) | 00:00:01 |     1.   112. Q1, 01 | ISSUE |            |
| * 20.                TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |   250K |    10 M |    39 (0) | 00:00:01 |     1.   112. Q1, 01 | SVCP |            |
| * 21.                 INDEX RANGE SCAN | INCIDENT_PATHTABLE_VALUE_IX |   161.       |    25 (0) | 00:00:01 |     1.   112. Q1, 01 | SVCP |            |
| 22.             ITERATOR BLOCK PX |                                |   221 M | 8865M | 1671 (1) | 00:00:21 |    53.    54. Q1, 02 | ISSUE |            |
| * 23.              TABLE ACCESS FULL | INCIDENT_PATHTABLE |   221 M | 8865M | 1671 (1) | 00:00:21 |    53.    54. Q1, 02 | SVCP |            |
| * 24.      TABLE ACCESS BY ROWID USER | INCIDENT |     1.    32.     1 (0) | 00:00:01 | ROWID | ROWID | Q1, 03 | SVCP |            |
| * 25.     SEE PUSHED PREDICATE. VW_SQ_2                        |     1.    13.    20 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| 26.      NESTED LOOPS |                                |     1.   106.    20 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| 27.       NESTED LOOPS |                                |     4.   106.    20 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| 28.        NESTED LOOPS |                                |     4.   256.     8 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| 29.         TABLE ACCESS BY INDEX ROWID | X$ PT74MSS0WBH028JE0GUCLBK0LHM4 |     1.    22.     3 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| * 30 |          INDEX RANGE SCAN | X$ PR74MSS0WBH028JE0GUCLBK0LHM4 |     1.       |     2 (0) | 00:00:01 |       |       | Q1, 03 | SVCP |            |
| 31.         ITERATOR SYSTEM PARTITION.                                |     4.   168.     5 (0) | 00:00:01 |    53.    54. Q1, 03 | SVCP |            |
| * 32 |          TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |     4.   168.     5 (0) | 00:00:01 |    53.    54. Q1, 03 | SVCP |            |
| * 33 |           INDEX RANGE SCAN | INCIDENT_PATHTABLE_PIKEY_IX |     4.       |     4 (0) | 00:00:01 |    53.    54. Q1, 03 | SVCP |            |
| 34.        ITERATOR SYSTEM PARTITION.                                |     1.       |     2 (0) | 00:00:01 |   KEY |   KEY | Q1, 03 | SVCP |            |
| * 35 |         INDEX RANGE SCAN | INCIDENT_PATHTABLE_KEY_IX |     1.       |     2 (0) | 00:00:01 |   KEY |   KEY | Q1, 03 | SVCP |            |
| * 36 |       TABLE ACCESS BY LOCAL INDEX ROWID | INCIDENT_PATHTABLE |     1.    42.     3 (0) | 00:00:01 |     1.     1. Q1, 03 | SVCP |            |
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
10 - access("SYS_P9".") PATHID '=' ID')
Access (SYS_PATH_REVERSE ("PATH") 15 - > = HEXTORAW ('02582E') AND SYS_PATH_REVERSE ("PATH") < HEXTORAW ('02582EFF'))
16 - access("SYS_P11".") RID "IS 'SYS_P9'." GET RID OF"AND TBL$ OR$ IDX$ PART$ NUM ("CORPAUDLIVE". "THE INCIDENT", 0,7,65535, "SYS_P9" "." " "RID") = TBL$ OR$ IDX$ PART$ NUM ("CORPAUDLIVE". "INCIDENT_PATHTAB
THE', 0,7,65535, ROWID))
filter ("SYS_P9". "ORDER_KEY" < = 'SYS_P11' "." " ORDER_KEY' AND 'SYS_P11 '. "" ORDER_KEY "< SYS_ORDERKEY_MAXCHILD ("SYS_P9". "ORDER_KEY")) "
20 filter (SYS_XMLI_LOC_ISTEXT ("SYS_P11". "LOCATOR", "SYS_P11" "." " PATHID') = 1)
21 - access("SYS_P11".") The VALUE "= 'John')
23 filter (SYS_XMLI_LOC_ISNODE ("SYS_P9". "LOCATOR") = 1 AND SYS_OP_BLOOM_FILTER (: BF0000, "SYS_P9".) " PATHID'))
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
24 - filter("A".") INCIDENT_DATE' > = TIMESTAMP' 2014 - 10 - 01 00:00:00.000000000 "AND"A"". "" INCIDENT_DATE"< = TIMESTAMP' 2014 - 10 - 09 00:00:00.000000000' AND
"ITEM_2" = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT", 0,7,65535, "A". ROWID))
25 filter ("ITEM_4" = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT", 0,7,65535, "A".) ROWID))
30 - access (SYS_PATH_REVERSE ("PATH") > = HEXTORAW('027FF9') AND SYS_PATH_REVERSE ("PATH") < HEXTORAW ('027FF9FF'))
32 filter (SYS_XMLI_LOC_ISNODE ("SYS_P2". "LOCATOR") = 1) "
33 - access("SYS_P2".") GET RID OF"="A ". ROWID AND 'SYS_P2 '. ("' PATHID '=' ID ')
35 - access("SYS_P4".") GET RID OF"="A ". ROWID AND 'SYS_P2 '. "" ORDER_KEY "< ="SYS_P4. " "" ORDER_KEY "AND"SYS_P4 ". "" ORDER_KEY "< SYS_ORDERKEY_MAXCHILD ("SYS_P2". "ORDER_KEY")) "
filter ("SYS_P4". "RID"IS "SYS_P2"." GET RID OF"AND TBL$ OR$ IDX$ PART$ NUM("INCIDENT",0,7,65535,"SYS_P2".") "RID") = TBL$ OR$ IDX$ PART$ NUM ("INCIDENT_PATHTABL
E «(, 0,7,65535, ROWID)).
36 - filter("SYS_P4".") The VALUE '= 'clark' AND SYS_XMLI_LOC_ISTEXT ("SYS_P4".' LOCATOR', 'SYS_P4 '. (("" PATHID ') = 1).
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Note
-----
-dynamic sample used for this survey (level = 6)
69 selected lines.
Elapsed time: 00:00:00.47
SQL > spool off
Thank you
CenterB

You must create a XMLIndex with two groups:

create table actionnew)

number of action_pk

action_date timestamp

action_detail xmltype

)

partition by (range (action_date)

partition values before_2015 less (timestamp ' 2015-01-01 00:00:00 ')

, partition values jan_2015 less (timestamp ' 2015-02-01 00:00:00 ')

, partition values feb_2015 less (timestamp ' 2015-03-01 00:00:00 ')

);

create index actionnew_sxi on actionnew (action_detail)

indexType is xdb.xmlindex

local

parameters (q'~)

Group my_group_1

XMLTable actionnew_xt1

"/ audit/action_details/screen_data/tables/table/row.

path of varchar2 (100) the columns "name".

, path of surname varchar2 (100) "first name".

Group my_group_2

XMLTable actionnew_xt2

"/ audit/action_details/fields.

path of varchar2 (100) the columns "name".

, path of surname varchar2 (100) "first name".

~'

);

Select x.*

to actionnew t

xmltable)

"/ audit/action_details/screen_data/tables/table/row.

in passing t.action_detail

path of varchar2 (100) the columns "name".

, path of surname varchar2 (100) "first name".

) x

where t.action_date between timestamp ' 2015-02-01 00:00:00 '

and timestamp ' 2015-03-01 00:00:00 '

and x.forename = 'anwardo. '

and x.surname = 'gram '.

;

INDEX RANGE SCAN against INDEX SKIP SCAN

Similar Questions

How the Index range scans work

How to index full scans of work

How to index Fast Full Scans work

Skip index scans

How Index Skip scan work

Maybe you are looking for