Local index: prefix or no prefix

Hello

I understand that in order to effectively use the local index, WHERE the sql clause must have the partition column
as a predicate.

in general, the partition column will not be a very selective specific column to the individual partition (even at the level of the table).

in which case, with the local index prefix (where the partition column will be the leading index) will benefit?
in my case, I partitioned tables list with 2 partitions, 1) 2) obsolete current.

Thank you
Charles

Uwe Hesse wrote:

Uwe,

In short: If you manage to include the partition key of the table to your where condition, size of the partition to the level of the index for the index is possible. But maybe it's not always possible.

But if the where clause does not contain the partition key, then you need to visit each partition of the index (and, possibly, table) anyway - and the index cannot be used for high precision range scans because it begins with a column that is not in the where clause (you might get lucky with skip scans However).

There are four conditions to study once you have chosen a possible local index and think that you are supposed to decide whether or not the index should include:

When the clause includes partition key, index is not prefixed (even to the extent where the partition key is not part of the index)
Partition elimination can occur

When the clause includes partition key, the index is prefixed
Partition elimination can occur

When the clause does not partition key, index is not prefixed (even to the extent where the partition key is not part of the index)
Partition elimination cannot take place-, but the index could still be very accurate and very effective

When the clause does not partition key, the index is prefixed
Partition elimination cannot take place, and the index cannot be used by a jump search or complete analysis because it begins with a column that is not the case clause.

The first pair of options shows that there is no inherent advantage to the addition of the prefix, the second pair shows that there is a potential threat.

Since something like 8.1.6 the only factors including the key partitioning in all indexes them are that the standard ones - how does improve accuracy, where - in the index, the column order - is this is a most useful position. The concept of all prefix/non-prefixe has been buried years ago.

Concerning
Jonathan Lewis

Tags: Database

Similar Questions

Creating Local index on an existing partitioned table

I have an existing table partitioned by list. I'm supposed to create local indexes on this subject.
I'm using Oracle 11 g.

I have an existing table partitioned by list. I'm supposed to create local indexes on this subject.

I'm using Oracle 11 g.

The skill the MOST IMPORTANT you can learn, is at present, how to find information.

A search on the SIMPLE web for 'local index of oracle 11g' returns this as the FIRST link

https://docs.Oracle.com/CD/B28359_01/server.111/b28286/statements_5011.htm

The "local_partitioned_index" section has all the information you need and it has code example showing you how do it.

Partition key would exist in local index, if so it should be first or last or is not serious?

Hello

I'm trying to find the rule for:

-J' have a partitioned table every day and each partition has about 10 GB.

-J' need to keep the data in 3 months.

-I need to partition cutting happens.

I'm trying to find if I need to use the local index the partition key or not.

I am currently adding as the first column of the index.

In my research on the web and with colleagues, I find three different answers:

-It is not required to add local index the partition key.

-It is compulsory and must be the first position.
-It is necessary and should be the last position.

I share below the criation of table as an example:

CREATE TABLE MY_BIG_TABLE
(
  MY_SOURCE             VARCHAR2(50 CHAR)       NOT NULL,
  MY_FILENAME           VARCHAR2(255 CHAR)      NOT NULL,
  MY_DATE               DATE                    NOT NULL,
  MY_ID                 VARCHAR2(50 CHAR)       NOT NULL,
  MY_ORIG_GROUP         VARCHAR2(50 CHAR)       NOT NULL,
  MY_DEST_GROUP         VARCHAR2(50 CHAR)       NOT NULL,
  MY_DURATION           NUMBER,
  MY_NR_EVENT           NUMBER
)
TABLESPACE MY_BIG_TABLESPACE_1
PARTITION BY RANGE (MY_DATE)
INTERVAL (NUMTODSINTERVAL(1,'DAY'))
(  
  PARTITION P_FIRST VALUES LESS THAN (TO_DATE(' 2014-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
    LOGGING
    NOCOMPRESS 
    TABLESPACE MY_BIG_TABLESPACE_1
)
LOGGING 
NOCOMPRESS 
NOCACHE
NOPARALLEL
MONITORING
/
CREATE UNIQUE INDEX I_MY_BIG_TABLE
 ON MY_BIG_TABLE (
   MY_DATE,           
   MY_SOURCE,    
   MY_FILENAME,       
   MY_ID,             
   MY_ORIG_GROUP,     
   MY_DEST_GROUP     
 )
 TABLESPACE MY_BIG_IDX_TABLESPACE_1
 LOGGING
 NOCOMPRESS
 NOPARALLEL
 LOCAL
/

Best regards

Ricardo Tomas

Well, I don't like this example because I would tell you to use on your text string to_date and to_char on your column.

Let's say if you have a partition of the range with a value of one month of data in the partition and you want to select the data for a given day. Oracle must be able plum of the score, but then you have to complete the partition scanning unless there was an index containing the day (assuming it's the partition key)

Remove the local index partitions

Hello
How can I provide clues the only from a few partitions in oracle 10.2.0.4?

Index partitions a fall

You cannot explicitly delete a partition of a local index. Instead, the local index partitions are removed only when you delete a partition of the underlying table.

http://docs.Oracle.com/CD/E18283_01/server.112/e16541/part_admin002.htm#i1007542

What happens to the existing after the partition of table index and created with local index

Hi guys,.
/ / DESC part id name number, varchar2 (100), number of wage
In an existing table PART I add 1 column DATASEQ MORE. I wonder the part of table based on dataseq.now, the table is created with this logic of partition
create the part table partition (identification number, name varchar2 (100), number of salary, number DATASEQ) in list (dataseq) (values partition PART_INITIAL (1));
Suggestionn necessary. given that the table is partitioned based on DATASEQ I wonder to add local indexes on dataseq. to dataseq, I have added a local index create index idx on share (dataseq) LOCAL; Now my question is, already, there are the existing index is the column ID and salary.
(1) IDX for dataseq is created locally so that it will be partition on each partition on the main table. Please tell me what is happening to the index on the column ID and salary... it will create again in local?
Please suggest
S

Hello

first of all, in reality 'a partition table' means create a new table a migration of existing data it (although, theoretically, you can use dbms_redefinition to partition an existing table - however, it's just doing the same thing behind the scenes). This means that you also get to decide what to do with the index - index will be local, who will be global (you can also reassess some of existing indexes and decide that they are not really necessary).

Second of all, the choice of the partitioning key seems weird. Partitioning is a data management technique more that anything else, in order to be eligible, you must find a good partitioning key. A column recently added, named "data_seq" is not a good candidate. Can you give us more details about this column and why it was chosen as a partitioning key?

I suspect that the person who proposed this partitioning scheme made a huge mistake. A non-partitioned table is much better in all aspects (including the ease of management and performance) that divided one wrongly.

Best regards

Nikolai

How do I know it's global index or local index?
Hi all

How will I know if it's overall index or local index?

Thank you!

Dan.
Salvation;

Check defination of index? Overall index below has defination

CREATE INDEX month_ix ON sales (sales_month)
GLOBAL PARTITION BY RANGE (sales_month)

For more information, please visit:

http://download.Oracle.com/docs/CD/B13789_01/server.101/b10739/partiti.htm

Respect of
HELIOS

index of output table and show what LOCAL indexes and who are
I read the view of ALL_INDEXES here:
http://www.Stanford.edu/dept/ITSS/docs/Oracle/10G/server.101/b10755/statviews_1061.htm
But I still don't know how to query follows:

1. display the name of the table, the index name and flag Y/N 'Is the local index' and a flag "is the overall index.

The application should output table index and show what indexes are LOCAL and which are not.

How to write this query?

My original request:
```
select table_name, Index_Name, Uniqueness, Partitioned, decode(Partitioned, 'NO', 'Global','Local') GlobalOrLocal from all_indexes
where table_name = 'MyTABLE'
```
2 I understand that global index for partitioned tables is a chunk of data referencing all the partitions table in the single room, but Local index is partitioned itself there are several parts each one or more partitions to reference table?

Published by: CharlesRoos on October 6, 2010 12:45 AM
CharlesRoos wrote:
I read the view of ALL_INDEXES here:
http://www.Stanford.edu/dept/ITSS/docs/Oracle/10G/server.101/b10755/statviews_1061.htm
But I still don't know how to query follows:

1. display the name of the table, the index name and flag Y/N 'Is the local index' and a flag "is the overall index.

The application should output table index and show what indexes are LOCAL and which are not.

How to write this query?

My original request:
```
select table_name, Index_Name, Uniqueness, Partitioned, decode(Partitioned, 'NO', 'Global','Local') GlobalOrLocal from all_indexes
where table_name = 'MyTABLE'
```
That seems Ok to me.

2 I understand that for partitioned tables index global is a big piece of data referencing all the partitions table in the single room,

Yes.

but the Local index is partitioned itself there several pieces for each reference one or several partitions table?

Almost right: each refers to score exactly one table. I.e. index partitioning is 'aligned' with the partitioning of the table.

How to assign the tablespace name local index when converted to INTERVAL
Hello
I'm converting a range partition table in the table to partition INTERVAL. The storage space for the tables is GIVEN. After this operation, all the indexes the world and are valid and usable. However, when the next interval partition is created, the local index is also created in the tablespace DATA. How can I make sure that new partitions of the interval for the index will be created them within the existing Index table?

Thank you
Murali
Change the index to specify the desired storage space, and new partitions will be created there.
```
ALTER INDEX my_index MODIFY DEFAULT ATTRIBUTES TABLESPACE my_preferred_tablespace;
```

Rebuild the range-Hash partitioned local index
Hi all

We have a table with 400 million records in our dataware House environment. It is partitioned using range-Hash Partitioning composit. He used a global Indexes previously. Last month the global indices have been changed to the index the. Since then, Exchange and index rebuild partition takes twice against the take used previously. From my understanding local index should provide availability high and more usable in the warehouse environment. Please correct me if I'm wrong and give me your suggestion. Also, I'm looking for a good material for the exchange of the partition and Index rebild with locally manage the range-hash partitioned index. Let me know if you know a good link for this...

Thanks in advance...
Dear krmreddy,

Carefully read the following link and I hope this will guide you;

http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:223318100346512896

Kind regards.

Ogan

How to improve the performance of the Local index?
I need to store the telecom CDR Data, that having more fields

CDR_DATE = > Date
Telephone_Num = > Varchar2 (20)
A = > Varchar2 (40)
B = > Varchar2 (10)

The volume of input data is very high... To 100 million/day

So I created the Table to Partition Oracle with Date Range Partition.

The application will always run a query of type

Select * from CDR where Telephone_Num = '& TNUM' AND CDR_DATE between JAN09 AND MAR09;

Question1
What will be the best way to create indexes? Which can provide better performance and not degrade the daily data loading.

Question2 - for this I created the LOCAL Index
Create Index ABCS ON LOCAL of CDR (CDR_DATE, Telephone_Num);

Data recovery uses the index but I see in the Trace, County GETS COMPLIANT & PHYSICAL READINGS are very high.

Then please suggest, creating a LOCAL INDEX is wise decision or not. Or in any other way.

Thanks in advance.
Sumit

Published by: Sumit2 on July 31, 2010 18:27

Global and local index with respect to table partitioned
Hello
I am very confused about local and global index in a partitioned table.
In addition, local index can be partitioned and unpartitioned.
In addition, what is the difference between global partitioned and unpartitioned
the index?

As far as I know,
If there is local index then there will be as many partitions as the partition table
and local parition will index contains the index of only the lines of their corresponding scores.
In addition, the local index maintananence is easier because drop us or create a partition, only index corresponding partition is affected then that in the case of the overall index,
If we create a new partition of the table, to rebuild the global index.
Am I wrong?

Concerning
Hello

This means that when you add/drop/split/merge table any partition (maintaiance) lying below, its corresponding partition in index is automatically added/deleted/split/merged. Oracle takes care of it internally without user intervention.

Concerning
Anurag

local indexing in ODI
I want to make INUTILISABLES INDEX LOCAL based on the scores of I$ table (intermediate table).
When I use this method of substitution < % = snpRef.getTable ("L", "INT_NAME", "W") % > to get the name of intermediate table
It generates. I have$ _ < TARGET_TABLE >, but I I want $_ < TARGET_TABLE > only (there are not any prefix as.)

Any help is appreciated.

Thank you
RD
The last argument in the odiRef.getTable takes three arguments:

(1) ' W': Returns the display name of the object in the physical catalog, and the schema of physical work that is the tuple (context, logical schema) object
(2) "D": Returns the display name of the object in the physical catalog, and the physical data schema that corresponds to the tuple (context, logical schema) object.
(3) ' a': odi is used to determine the default location of the object. This value is used if please is not specified.

You have used 'W' for ODI attempts to retrieve the full name of the table in the physical catalog and schema of physical work.

Now you must decide what parameter you need.

The error is because in the physical schema that you have used the scheme of work is not defined that is why you get a point before the name of the table.

Hope it helps and I'm supposed to. :-)

Kind regards
Amit

Creating partitioned local index

Hi all

Planing to run the range-partitioned on a table and creating Local partitioned index, but in the table is seen forced composite primary key thought to previously create Composite Unique Local partitioned index.

Problem is when creating index its error ORA-14039 giving, of course it is not possible as partitioning column is not a subset of columns in a UNIQUE index key.

Is there no workaround solution to create Local partitioned indexes... otherwise I'll be forced to create the overall index part?

Y at - it no drawback if I create Composite Unique Local partitioned indexes including the columns of partitioning on purpose?

There will be no impact if I create the index Composite Unique Local partitioned by including the columns voluntarily on the SQL QUERIES, access this table partitioning?

Please suggest me a workaround solution.

CREATE TABLE YASIR.CS_RESEARCH (ORDER_NBR NUMBER NOT NULL,
                      ORDER_DETAIL_NBR NUMBER NOT NULL,
                      SESSION_ID VARCHAR2(40),
                      PRODUCT_GROUP VARCHAR2(16) NOT NULL,
                      PRODUCT_SUBGROUP VARCHAR2(16) DEFAULT 'N/A',
                      FORMAT_TYPE VARCHAR2(10) NOT NULL,
                      CONTRIBUTOR VARCHAR2(60) NOT NULL,
                      DOCUMENT_NUMBER VARCHAR2(15) NOT NULL,
                      DOCUMENT_DATE DATE,
                      BILLABLE_PAGES NUMBER,
                      NON_BILLABLE_PAGES VARCHAR2(512),
                      PURCHASED_UNITS VARCHAR2(2000),
                      DELIVERY_METHOD VARCHAR2(6) DEFAULT 'ONLINE',
                      COMPANY_NAME VARCHAR2(120),
                      STATUS VARCHAR2(10) DEFAULT 'NEW',
                      CONTENT_CODE VARCHAR2(15) NOT NULL, 
                      CONTENT_CODE_DESC VARCHAR2(60),
                      ITEM_PRICE NUMBER NOT NULL,
                      PAGES_ORDERED NUMBER,
                      LAST_MNT_DATE_TIME DATE NOT NULL,
                      LAST_MNT_OPID VARCHAR2(120) NOT NULL,
                      CREATE_DATE DATE NOT NULL,
                      DML_FLAG CHAR(1) NOT NULL)
     PARTITION BY RANGE (CREATE_DATE) 
     (PARTITION CS_RESEARCH_2009_Q2 VALUES LESS THAN (MAXVALUE));

###Split partitions:
ALTER TABLE YASIR.cs_research
  SPLIT PARTITION CS_RESEARCH_2009_Q2 AT (TO_DATE('30-SEP-2007 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
  INTO (PARTITION CS_RESEARCH_2007_Q3,
        PARTITION CS_RESEARCH_2009_Q2);

ALTER TABLE YASIR.cs_research
  SPLIT PARTITION CS_RESEARCH_2009_Q2 AT (TO_DATE('31-DEC-2007 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
  INTO (PARTITION CS_RESEARCH_2007_Q4,
        PARTITION CS_RESEARCH_2009_Q2);

ALTER TABLE YASIR.cs_research
  SPLIT PARTITION CS_RESEARCH_2009_Q2 AT (TO_DATE('31-MAR-2008 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
  INTO (PARTITION CS_RESEARCH_2008_Q1,
        PARTITION CS_RESEARCH_2009_Q2);

ALTER TABLE YASIR.cs_research
  SPLIT PARTITION CS_RESEARCH_2009_Q2 AT (TO_DATE('30-JUN-2008 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
  INTO (PARTITION CS_RESEARCH_2008_Q2,
        PARTITION CS_RESEARCH_2009_Q2);

ALTER TABLE YASIR.cs_research
  SPLIT PARTITION CS_RESEARCH_2009_Q2 AT (TO_DATE('30-SEP-2008 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
  INTO (PARTITION CS_RESEARCH_2008_Q3,
        PARTITION CS_RESEARCH_2009_Q2);

ALTER TABLE YASIR.cs_research
  SPLIT PARTITION CS_RESEARCH_2009_Q2 AT (TO_DATE('31-DEC-2008 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
  INTO (PARTITION CS_RESEARCH_2008_Q4,
        PARTITION CS_RESEARCH_2009_Q2);

ALTER TABLE YASIR.cs_research
  SPLIT PARTITION CS_RESEARCH_2009_Q2 AT (TO_DATE('31-MAR-2009 23:59:59', 'DD-MON-YYYY HH24:MI:SS'))
  INTO (PARTITION CS_RESEARCH_2009_Q1,
        PARTITION CS_RESEARCH_2009_Q2);

###Create indexes on cs_research except primary key index CSR_PKEY:
alter session set sort_area_size=262144000; -----(250MB Total will be 1GB for 4 parallel process)
create index YASIR.CSR_DETAIL_NBR on YASIR.CS_RESEARCH(TO_NUMBER(REPLACE(TO_CHAR(ORDER_NBR,'999999999')||TO_CHAR(ORDER_DETAIL_NBR,'999999999'),' ',''),'999999999999')) LOCAL
          (PARTITION CS_RESEARCH_2007_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2007_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q2 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q2 TABLESPACE USERS)
     nologging parallel (degree 4);
Index created.

create index YASIR.CSR_SESSION on YASIR.CS_RESEARCH(SESSION_ID,ORDER_NBR) LOCAL
          (PARTITION CS_RESEARCH_2007_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2007_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q2 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q2 TABLESPACE USERS)
     nologging parallel (degree 4);
Index created.

create index YASIR.CSR_CREATED on YASIR.CS_RESEARCH(CREATE_DATE) LOCAL
          (PARTITION CS_RESEARCH_2007_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2007_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q2 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q2 TABLESPACE USERS)
     nologging parallel (degree 4); 
Index created.

create index YASIR.CSR_DOCUMENT_NUMBER on YASIR.CS_RESEARCH(DOCUMENT_NUMBER) LOCAL
          (PARTITION CS_RESEARCH_2007_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2007_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q2 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q2 TABLESPACE USERS)
     nologging parallel (degree 4); 
Index created.

create index YASIR.CSR_STATUS on YASIR.CS_RESEARCH(STATUS) LOCAL
          (PARTITION CS_RESEARCH_2007_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2007_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q2 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q2 TABLESPACE USERS)
     nologging parallel (degree 4);
Index created.
 
create unique index CSR_PRKEY_IND on YASIR.CS_RESEARCH(ORDER_NBR,ORDER_DETAIL_NBR) LOCAL
     (PARTITION CS_RESEARCH_2007_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2007_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q2 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q3 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2008_Q4 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q1 TABLESPACE USERS,
          PARTITION CS_RESEARCH_2009_Q2 TABLESPACE USERS)
     nologging parallel (degree 4);
ERROR at line 1:
ORA-14039: partitioning columns must form a subset of key columns of a UNIQUE
index

Thank you
Yasser

YasserRACDBA wrote:
I want to create a unique partitioned index Local and use this primary key index.

But my main question is if this create_date column will affect all sql queries that are not used in where clause?

Yasser,

your main question should not be about performance queries, but the consequence of adding the CREATE_DATE to the local unique index:

1. you change the meaning of the primary key: adding the CREATE_DATE means that the unique character of ORDER_NBR, ORDER_DETAIL_NBR is only applied by CREATE_DATE. I guess that does not match the business experience that this primary key is supposed to enforce and defeated the original purpose of the uniqueness that is unique values of ORDER_NBR, ORDER_DETAIL_NBR across the table.

2. If you want to use as a key in other tables you must add the CREATE_DATE to all child tables, because you need to refer to the primary key complete a relationship of key foreign primary key.

So the only 'right' way to do this is to use a unique comprehensive index on ORDER_NBR, ORDER_DETAIL_NBR. Of course, this means you must rebuild whenever a partition maintenance is carried out which invalidates the overall index since you use 8i and you cannot use the UPDATE GLOBAL INDEXES clause.

Kind regards
Randolf

Oracle related blog stuff:
http://Oracle-Randolf.blogspot.com/

SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676 /.
http://sourceforge.NET/projects/SQLT-pp/

Too many IOs logical on a partition locally index!

Hi all.

The database is 11.2.0.3 on a linux machine.

I have issued a request and concluded that the 0 row was extract but logic ios on index 'IN_BPMDNPMTACT_DX1' is more than 25000 blocks.

I would like to know whence 25006 block e/s on the index. (Operation ID = 12)

-the partition number is 6.

-----------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name               | Starts | E-Time   | Pstart| Pstop | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |
-----------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                    |      1 |          |       |       |      0 |00:00:00.08 |   25006 |       |       |      |
|   1 |  NESTED LOOPS                 |                    |      1 | 00:07:35 |       |       |      0 |00:00:00.08 |   25006 |       |       |      |
|   2 |   VIEW                        | VW_NSO_1           |      1 | 00:07:34 |       |       |      0 |00:00:00.08 |   25006 |       |       |      |
|   3 |    HASH UNIQUE                |                    |      1 | 00:07:34 |       |       |      0 |00:00:00.08 |   25006 |  1036K|  1036K|      |
|   4 |     HASH GROUP BY             |                    |      1 | 00:07:34 |       |       |      0 |00:00:00.08 |   25006 |   792K|   792K|      |
|*  5 |      FILTER                   |                    |      1 |          |       |       |      0 |00:00:00.08 |   25006 |       |       |      |
|   6 |       VIEW                    |                    |      1 | 00:06:16 |       |       |      0 |00:00:00.08 |   25006 |       |       |      |
|*  7 |        COUNT STOPKEY          |                    |      1 |          |       |       |      0 |00:00:00.08 |   25006 |       |       |      |
|   8 |         VIEW                  |                    |      1 | 00:06:16 |       |       |      0 |00:00:00.08 |   25006 |       |       |      |
|*  9 |          SORT ORDER BY STOPKEY|                    |      1 | 00:06:16 |       |       |      0 |00:00:00.08 |   25006 |  1024 |  1024 |      |
|  10 |           PARTITION RANGE ALL |                    |      1 | 00:02:10 |     1 |     6 |      0 |00:00:00.08 |   25006 |       |       |      |
|* 11 |            COUNT STOPKEY      |                    |      6 |          |       |       |      0 |00:00:00.08 |   25006 |       |       |      |
|* 12 |             INDEX RANGE SCAN  | IN_BPMDNPMTACT_DX1 |      6 | 00:02:10 |     1 |     6 |      0 |00:00:00.08 |   25006 |       |       |      |
|  13 |       PARTITION RANGE ALL     |                    |      0 | 00:00:01 |     1 |     6 |      0 |00:00:00.01 |       0 |       |       |      |
|* 14 |        INDEX RANGE SCAN       | IN_BPMDNPMTACT_DX2 |      0 | 00:00:01 |     1 |     6 |      0 |00:00:00.01 |       0 |       |       |      |
|  15 |   TABLE ACCESS BY USER ROWID  | IN_BPMDNPMTACT     |      0 | 00:00:01 | ROWID | ROWID |      0 |00:00:00.01 |       0 |       |       |      |
-----------------------------------------------------------------------------------------------------------------------------------------------------------

The following is the result of analyze index validate structure.

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


HEIGHT     BLOCKS     NAME     PARTITION_NAME     LF_ROWS     LF_BLKS     BR_ROWS     BR_BLKS     DEL_LF_ROWS
4     182424     IN_BPMDNPMTACT_DX1     P201208     21655066     173118     173117     592     1790326
3     28304     IN_BPMDNPMTACT_DX1     P201209     4019084     27256     27255     73     0
3     29304     IN_BPMDNPMTACT_DX1     P201210     4186481     28465     28464     74     0
3     32704     IN_BPMDNPMTACT_DX1     P201211     2813299     32019     32018     121     0

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

Thanks in advance.

Best regards.

869578 wrote:
Thanks for your reply.

I've done the dump of tree of index, and the trace file has 107309 lines.

The result of dump tree index is too large.

However, as you name, I found a lot of "rrow:0". "in the middle of the trace file.

I think the Index rebuild could solve this excessive logical IOs on the index.

I just wonder why more than 20,000 block io is required in the row of retriving '0' on the index analysis.

I would like to know how oracle handle b * tree index structure in update has occurred.

I greped the total output trace file with "St: 0".
The total number of "Saint: 0" is 27156.

-- *************

The leafs in this index of the average 27 156 block is empty due to the update?

And "proc_rslt = 1" predicate scanned near the pads of sheets "rrow:0". » ?

When an index entry is "updated", basically a delete and insert operation is performed. This is to keep the index entries still in order. Thus, after the update all entries with a value '1', they are all logically deleted and reinserted elsewhere within the structure of the index. If these updates are all done in a single transaction, the deleted index entries space can not claimed in the transaction and all the entries are simply marked as deleted.

However, the industry still blocks reference these locations as new data with a value of '1' may be restored later. These blocks actually empty sheets can be recycled to reintegrate later, but until then, they remain in the index structure and because they can contain a value '1', must be analysed on a case where by your query.

This is a classic example of when an index rebuild (or coalesce) could indeed be beneficial because you deleted effectively many entries index without re - insert a similar volume and you have questions which analyzes the part of the index that contains these many deleted entries.

See you soon

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

with no prefixes local prefix index a huge difference

Hello world

I have a little problem on the partitioning and I didn't understand why. Here is my scenario:

I created a partitioned table, partition is a date column range partition ona, then I created 2 index a prefix, a non pre-fixed and both of them is local. When I run a query based on the partition column and another (that I've indexed) execution plans are really different. as an example:

  CREATE TABLE PART_HAREKET_TABLE (
    ISLEM_TAR DATE, -- MY PARTITION COLUMN
    ISLEM_REF VARCHAR2(10), -- INDEX COLUMN
    ... -- OTHER COLUMNS HERE
  );
  
-- load data to the table from one of my prod table...

  CREATE INDEX I_PART_HAREKET_1 ON PART_HAREKET_TABLE(ISLEM_TAR, ISLEM_REF) LOCAL;
  
  CREATE INDEX I_PART_HAREKET_2 ON PART_HAREKET_TABLE(ISLEM_REF) LOCAL;
  
  EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'PART_HAREKET_TABLE', ESTIMATE_PERCENT => 100, CASCADE => TRUE);

After this, I run these queries:

  EXPLAIN PLAN FOR
  select /*+ INDEX(PART_HAREKET_TABLE, I_PART_HAREKET_1 ) */ * 
  from   part_hareket_table 
  where islem_tar = to_Date('22/01/2012','dd/mm/yyyy') and islem_ref like 'KN%';

execution plan:

-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name               | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                    |  1243 |   195K|    19   (0)| 00:00:01 |       |       |
|   1 |  PARTITION RANGE SINGLE            |                    |  1243 |   195K|    19   (0)| 00:00:01 |    62 |    62 |
|   2 |   TABLE ACCESS BY LOCAL INDEX ROWID| PART_HAREKET_TABLE |  1243 |   195K|    19   (0)| 00:00:01 |    62 |    62 |
|*  3 |    INDEX RANGE SCAN                | I_PART_HAREKET_1   |  1243 |       |     5   (0)| 00:00:01 |    62 |    62 |
-------------------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   3 - access("ISLEM_TAR"=TO_DATE(' 2012-01-22 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "ISLEM_REF" LIKE 'KN%')
       filter("ISLEM_REF" LIKE 'KN%')

It is a good cost I think also as predicate info I see ISLEM_TAR and ISLEM_REF.

When I use this:

  EXPLAIN PLAN FOR
  select /*+ INDEX(PART_HAREKET_TABLE, I_PART_HAREKET_2 ) */ * 
  from   part_hareket_table 
  where islem_tar = to_Date('22/01/2012','dd/mm/yyyy') and islem_ref like 'KN%';

-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name               | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                    |  1243 |   195K|  8209   (1)| 00:01:55 |       |       |
|   1 |  PARTITION RANGE SINGLE            |                    |  1243 |   195K|  8209   (1)| 00:01:55 |    62 |    62 |
|*  2 |   TABLE ACCESS BY LOCAL INDEX ROWID| PART_HAREKET_TABLE |  1243 |   195K|  8209   (1)| 00:01:55 |    62 |    62 |
|*  3 |    INDEX RANGE SCAN                | I_PART_HAREKET_2   |   141K|       |   218   (1)| 00:00:04 |    62 |    62 |
-------------------------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   2 - filter("ISLEM_TAR"=TO_DATE(' 2012-01-22 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
   3 - access("ISLEM_REF" LIKE 'KN%')
       filter("ISLEM_REF" LIKE 'KN%')

as you can see here, there is a huge cost difference and ISLEM_TAR (partitioned column) is also used as a filter not access. These indices are LOCAL

so I expect that second index (non-prefixed) would be more effective. because oracle already know which partition which must be read and this index is smaller (just a column a) so I thought, Oracle will find appropriate part partition index and will read just this score (for the index and table) thus rows.

even the time of the request are different, first we (prefix) brings data ms 0.031, second 0.375ms (no prefixes).

but it's not? what Miss me?

You may say that ' AS' operator cause than on the ISLEM_REF column. I also use it as equal "=",
for the first query costs 4, for a second, now cost 8. 2 again...

the partition size is approximately 440 MB

an example of similer is also here exist: index Local: prefix or no prefix

Jonathan Lewis made an example and it works very well...

My db:

Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
"CORE     11.2.0.2.0     Production"
TNS for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production

find the appropriate index part partition

Who is 62 of Partition of Index in both cases.

In both cases, there is a one-to-one correspondence between the partition table and the index partition.

However, in the second case, he expects to have to browse through the index entries 141thousand against only 1243 index entries in the first case. Oracle expects to have to read several index blocks in the second case.

I guess your partitions are per month and not per day. So an index that is located on ISLEM_TAR + ISLEM_REF of columns is a more 'fine' (i.e. more accurate) because it only reads the entries for that one day of the index.
In the second case, Oracle expects that it returns rowid for several days (which means more ROWID returned from the index) and will filter the lines that do not match the date target when he reads the table. You'll notice that the use of the second filter on date against the table - read more lines of the table (because more ROWID is returned by the index).

Hemant K Collette

Published by: Hemant K Collette on 10 July 2012 15:17
--Added clarification that 'fine' are "more accurate".

Local index: prefix or no prefix

Similar Questions

Index partitions a fall

Maybe you are looking for