Local Vs Global Index on partitioned table?

Hello All,
DESC PS_P1_EMP_QRYSCRTY
Name Null? Type
EMPLID NOT NULL VARCHAR2(11)
EMPL_RCD NOT NULL NUMBER(38)
ROWSECCLASS NOT NULL VARCHAR2(30)
ACCESS_CD CHAR(1)
MY SQL QUERY IS:-
SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY EMP
WHERE EMP.ROWSECCLASS=OPR.CLASSID
This query was taking around 15 mins to run at sql-prompt
I have created a partitioned table based on PS_P1_EMP_QRYSCRTY :-
CREATE TABLE PS_P1_EMP_QRYSCRTY_BAK
TABLESPACE PSNEWTAB
PARTITION BY HASH(ROWSECCLASS)
( PARTITION PART1 ,
PARTITION PART2 ,
PARTITION PART3 ,
PARTITION PART4 ,
PARTITION PART5 ,
PARTITION PART6 ,
PARTITION PART7 ,
PARTITION PART8 ,
PARTITION PART9 ,
PARTITION PART10 ,
PARTITION PART11 ,
PARTITION PART12 ,
PARTITION PART13 ,
PARTITION PART14 ,
PARTITION PART15 ,
PARTITION PART16
ENABLE ROW MOVEMENT
AS SELECT * FROM PS_P1_EMP_QRYSCRTY
I created a local index like on PS_P1_EMP_QRYSCRTY_BAK
CREATE INDEX PS_P1_EMP_QRYSCRTY_BAK
ON PS_P1_EMP_QRYSCRTY_BAK(ROWSECCLASS,EMPLID,EMPL_RCD)
TABLESPACE PSINDEX
LOCAL;
The Following is an extract From PS_P1_EMP_QRYSCRTY_BAK
1ST COLUMN =TABLE NAME
2ND COLUMN = PARTITION NAME
3RD COLUMN = NUM OF DISTINCT ROWSECCLASS IN THE PARTITION
4TH COLUMN = NUM OF TOTAL ROWS IN THE PARTITION
TABLE_NAME PARTITION_NAME NUM_OF_DISTINCT_ROWSECCLASS NUM_OF_ROWS
PS_P1_EMP_QRYSCRTY_BAK | PART1 | 25 | 289058
PS_P1_EMP_QRYSCRTY_BAK | PART2 | 25 | 154537
PS_P1_EMP_QRYSCRTY_BAK | PART3 | 27 | 364219
PS_P1_EMP_QRYSCRTY_BAK | PART4 | 33 | 204528
PS_P1_EMP_QRYSCRTY_BAK | PART5 | 23 | 527974
PS_P1_EMP_QRYSCRTY_BAK | PART6 | 22 | 277210
PS_P1_EMP_QRYSCRTY_BAK | PART7 | 23 | 517125
PS_P1_EMP_QRYSCRTY_BAK | PART8 | 30 | 307634
PS_P1_EMP_QRYSCRTY_BAK | PART9 | 28 | 523169
PS_P1_EMP_QRYSCRTY_BAK | PART10 | 38 | 192565
PS_P1_EMP_QRYSCRTY_BAK | PART11 | 27 | 120062
PS_P1_EMP_QRYSCRTY_BAK | PART12 | 33 | 407829
PS_P1_EMP_QRYSCRTY_BAK | PART13 | 37 | 522349
PS_P1_EMP_QRYSCRTY_BAK | PART14 | 25 | 275991
PS_P1_EMP_QRYSCRTY_BAK | PART15 | 21 | 259676
PS_P1_EMP_QRYSCRTY_BAK | PART16 | 23 | 468071
SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
WHERE EMP.ROWSECCLASS=OPR.CLASSID
Now when i run this query it gives result in around 5-6 mins
MY PS_P1_EMP_QRYSCRTY_BAK table contains sumwhat 6 million rows...
Now My Questions are:-
1) Is the number of partition done by me optimal under these circumstances...i mean can i get better performance By increasing or decreasing the number of partitions.
2) I created local index on PS_P1_EMP_QRYSCRTY_BAK.
Whether creating local or global index will be more beneficial keeping in mind the where clause and Select clause of the query....
SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
WHERE EMP.ROWSECCLASS=OPR.CLASSID
i mean in where clause rowsecclass is used thats why i partitioned my table on ROWSECCLASS.
And in select clause i m selecting EMPLID and EMPL_RCD
Thats y i made a local index on ROWSECCLASS,EMPLID ,EMPL_RCD .
Thanks
--Pradeep

1) Is the number of partition done by me optimal under these circumstances...i mean can i get better performance >By increasing or decreasing the number of partitions.
2) I created local index on PS_P1_EMP_QRYSCRTY_BAK.
Whether creating local or global index will be more beneficial keeping in mind the where clause and Select clause of >the query....You'll have to see for yourself what is optimal. Every system is different. Here are some ideas, though.
Your query
SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
WHERE EMP.ROWSECCLASS=OPR.CLASSIDappears to read all qualifying rows across all qualifying partitions. Since you are partitioning by an id that would appear to exclude range and list partitioning instead so the hash partition is probably the best for your application.
Regarding global vs local partitions, I have seen timings indicate that global indexes can improve cross-partition queries slighly. I have not worked with partitions for a while but remember that global partition maintenance is difficult; anything the partition structure changes the global index had to be rebuild. You can check the documentation to see if that has changed.
If possible creating a unique index should give better performance than using an index allowing duplicates.

Similar Messages

Local index vs global index in partitioned tables

Hi,
I want to know the differences between a global and a local index.
I'm working with partitioned tables about 10 millons rows and 40 partitions.
I know that when your table is partitioned and your index non-partitioned is possible that
some database operations make your index unusable and you have tu rebuid it, for example
when yo truncate a partition your global index results unusable, is there any other operation
that make the global index unusable??
I think that the advantage of a global index is that takes less space than a local and is easier to rebuild,
and the advantage of a local index is that is more effective resolving a query isn't it???
Any advice and help about local vs global index in partitioned tables will be greatly apreciatted.
Thanks in advance

here is the documentation -> http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#sthref2570
In general, you should use global indexes for OLTP applications and local indexes for data warehousing or DSS applications. Also, whenever possible, you should try to use local indexes because they are easier to manage. When deciding what kind of partitioned index to use, you should consider the following guidelines in order:
1. If the table partitioning column is a subset of the index keys, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 2.
2. If the index is unique, use a global index. If this is the case, you are finished. If this is not the case, continue to guideline 3.
3. If your priority is manageability, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 4.
4. If the application is an OLTP one and users need quick response times, use a global index. If the application is a DSS one and users are more interested in throughput, use a local index.
Kind regards,
Tonguç

How   to find global index in partition table

Hi guys ,
need one help
How to find global index on partition table
How to find local index on partition table
Need query
Thanks in advance
Edited by: nav on Feb 17, 2012 6:51 AM

nav wrote:
Hi Solomon,
so I have to identify partition & index are created or not,
also I have check the status of index ( both global and local)So what's the problem? Table/index partition is an object, so you can query DBA_OBJECTS:
SELECT SUBOBJECT_NAME,
        CREATED
FROM DBA_OBJECTS
WHERE OWNER = partitioned-table-owner
    AND OBJECT_NAME = partitioned-table-name
    AND CREATED >= TRUNC(SYSDATE)
/This will give you partitions created today. So if you run this right after your job (I hope your job doen't run too close to midnight), you'll get table partition name your job created. Same logic can be applied to indexes.
SY.

Preserving Global indexes on partitioned tables

Hello,
we have a 24x7 application where a large number of client processes (around 200) loads details of transactions performed onto an historycal, date partitioned table - Clients are transactional, so they use INSERT + COMMIT for every row.
We have the need to create an additional index with a unique constraint on a column where the partitioning key cannot be included, therefore this index has been declared global.
When an old partition is dropped, the global index usually gets unusable, and client processes gets an ORA-01502.
To avoid this, I have tried the following:
LOCK TABLE ... IN EXCLUSIVE MODE to make the script wait until there are no pending COMMIT
ALTER TABLE ... DROP PARTITION ... UPDATE GLOBAL INDEXES PARALLEL to avoin index to be marked UNUSABLE and release the table lock at the end of the operation.
It seems working fine, as the clients gets locked on their INSERTs for a limited amount of time (apparently just the DROP time) and after that they go on on their activities while the global index is still USABLE and the index updates proceeds for some minutes.
In the end, my perception is that the UPDATE GLOBAL INDEXES clause behave as an online rebuild, thus leaving other processes working on partition not affected by the DROP with the UNIQUE constraint still active.
Is there anybody who can confirm me tha my idea is right, and this UPDATE clause is a SAFE way to achieve pratition drop without service interruption or index corruption for transactional clients?
Many thanks,
Riccardo

Hi,
In fact, only the UPDATE GLOBAL INDEXES clause is pertinent here. here's what happens when you're doign the LOCK/ALTER:
LOCK TABLE ... IN EXCLUSIVE MODE
You wait till you get a table lock. All "clients" are enqueued till you acquire the lock, and then stay enqueued till you release it.
ALTER TABLE ... DROP PARTITION ... UPDATE GLOBAL INDEXES PARALLEL
You start a DDL statement. So the first thing Oracle does is to COMMIT the current transaction, hence releasing the LOCK you previously acquired explicitly.
The "clients" resume standard operations, meanwhile the partition is dropped and the global index updated. Once the drop is over, the DDL transaction is commited.Meaning simply: the explicit table locking is useless!
Yoann.

Can I create unpartitioned index on partitioned table??

Hi,
I am not clear about the concepts of partitioned and non partitioned index.I was under impression that If we create a index on partitioned table it will be automatically becomes a partitioned index.But I cheked in my DB there are many unpartitioned indexes on large partitioned tables.
Which one of these is efficient? wht is the concept of local and global related to these partitioned and unparitioned.I am bit confused.pls help me.
Thanks

There's nothing prevent you from creating a nonpartitioned index on partitioned table. The official name for it is Global Nonpartitioned Indexes
Global Nonpartitioned Indexes
Global nonpartitioned indexes behave just like a nonpartitioned index. They are commonly used in OLTP environments and offer efficient access to any individual record.
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#i461446

Indexing on partitioned tables

I was wondering if there are any good standards for indexing very large partitioned tables (i.e. what should I index). Also, if there are any good standards for indexing these partitioned tables when running queries that do not include the partitioned column in the query?

There's no real difference in what you would index, other than maybe a slightly lower requirement for indexing on tha partitioning key column(s).
You ought to be considering whether you need local or global indexes though, and you'll find a lot of information on that over at http://asktom.oracle.com and in the documentation -- to simplify, OLTP usually uses global indexes and DWH usually uses local indexes. You'll want to understand the pro's and con's or each before deciding on your own situation though.

Index on Partitioned Table with Some ReadOnly Tablespaces

We have a warehouse with fact tables range partitioned on date - daily partitions with each month worth of partitions put into a specific monthly tablespace. Each month, we set the prior month's tablespace to READONLY. So our table ends up having data in readonly and read-write tablespaces.
We now have a change we need to make to one of the fact tables - we need to add a new column AND add an index to that column. But because we have partitions in readonly state, Oracle doesn't let us create the index and it also doesn't let us update the local unique key (unique index).
Is there a way we can do this without having to put the tablespaces in read-write mode? As importantly, what happens when we offline or drop some of the older tablespaces (for archiving purposes)? We need to find a way to add the index on just the read-write partitions.
Thanks.

We have a warehouse with fact tables range
partitioned on date - daily partitions with each
month worth of partitions put into a specific monthly
tablespace. Each month, we set the prior month's
tablespace to READONLY. So our table ends up having
data in readonly and read-write tablespaces.
We now have a change we need to make to one of the
fact tables - we need to add a new column AND add an
index to that column. But because we have partitions
in readonly state, Oracle doesn't let us create the
index and it also doesn't let us update the local
unique key (unique index).
Is there a way we can do this without having to put
the tablespaces in read-write mode? As importantly,
what happens when we offline or drop some of the
older tablespaces (for archiving purposes)? We need
to find a way to add the index on just the read-write
partitions.
Thanks.Hi,
Improvements in Oracle 10g to maintain local-partitioned indexes when you use partition DDL commands:
add partition, split partition, merge partiton, move partition.
ALSO, the associated indexes NO LONGER have to be stored on the same tablespace as the table (i.e. answer to your question).
On Oracle 9i: Local indexes are recommended on data warehouse platforms. In an OLTP system, global indexes are more common. On a data data warehouse, problems can be isoloted to one partition, the partitions moved, made r/o (like yours), no local indexes need to be rebuilt
Regarding your issue:
We now have a change we need to make to one of the
fact tables - we need to add a new column AND add an
index to that columnTo maintain the simplicity + functionality of your DW configuration, I think you need to change the TS to R/W, update the objects, then alter to R/O.
fyi
http://www.oracle.com/technology/deploy/availability/htdocs/online_ops.html

Rebuild indexes on partitioned table

Hi
We have a very large table hh_advance which hold 1.5billion records and is partitioned by range
we a index (non parititioned) index on this table.
after adding partitions to hh_advance table the index has become unusable
the size of index is too huge and we need to rebuild the index in least possible time
what is the best used practice in this case
thanx
kb

KB.. wrote:
Hi
We have a very large table hh_advance which hold 1.5billion records and is partitioned by range
we a index (non parititioned) index on this table.
after adding partitions to hh_advance table the index has become unusable
the size of index is too huge and we need to rebuild the index in least possible time
what is the best used practice in this casekb,
you haven't mentioned your database version, but the best practice would be in many cases to use the "UPDATE \[GLOBAL\] INDEXES" clause of the ALTER TABLE command if you're at least on 9i or later to prevent any (global) indexes from becoming unusable.
By the way, adding a partition to a range partitioned table shouldn't invalidate neither a global nor a local index.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

When to create index on partitioned table ?

Hi,
The original table TEST1 contain one index called INDX_HIREDATE on field HIREDATE
CREATE TABLE TEST1(
COD NUMBER PRIMARY KEY,
HIREDATE DATE);
CREATE INDEX INDX_HIREDATE ON TEST1 (HIREDATE);
I created a example partitioned table as below:
CREATE TABLE TEST2_PART(
COD NUMBER PRIMARY KEY,
HIREDATE DATE)
PARTITION BY RANGE (HIREDATE)(
PARTITION P2003 VALUES LESS THAN (TO_DATE('01/01/2004','DD/MM/YYYY')),
PARTITION P2004 VALUES LESS THAN (TO_DATE('01/01/2005','DD/MM/YYYY')),
PARTITION P3000 VALUES LESS THAN (MAXVALUE));
INSERT /*+ APPEND */ INTO TEST2 SELECT * FROM TEST1;
Questions:
Need i to create the index on TEST2 table the same way done on the TEST1 table?
ex: CREATE INDEX INDX_HIREDATE ON TEST2 (HIREDATE);
or have i need to create the global/local index on each partition?
The Primary Key index is a global for partitions??
What is the best way?
Thanks

Index creation on partitioned tables is similar to the non-partitioned tables. There is no special syntax unless you need to create LOCAL indexes. For creating local indexes, add LOCAL key word at the end of the "create index...." command.
To create local primary key index you may need to use different syntax the one used in your create table command. Refer to SQL Reference manual for actual syntax. (remember manuals are the best place for getting quick answers). All the manuals are available online (at otn.oracle.com).

Cannot create text index in partition table on Oracle 10g

I try to create context index in a table with 15 millions records. The table is divided 5 partitions and each patition has 3 millions records. When I create the context index in the table, the same error always arised. The follow are my work:
--First create my own lexer
begin
ctx_ddl.createperference('my_chinese_lexer','chinese_lexer');
end;
--Second create index
create index idx_part_text3 on tb_test_part(text3)
indextype is ctxsys.context local (
partition p1_ix,
partition p2_ix,
partition p3_ix ,
partition p4_ix,
partition p5_ix)
parameters('lexer my_chinese_lexer') parallel;
--error message
create index idx_part_text3 on tb_test_part(text3)
Error in 1 line:
ORA-12801: Parellel Query Server P000 send error signal
ORA-29855: Error on execute ODCIINDEXCREATE program
ORA-06510: PL/SQL: User Defined Error
ORA-06512: In "CTXSYS.DRIDISP", line 244
ORA-04030: Try to alloc 65548 Bytes (CTX PRM heap,draccbx:message buffer) Out of memory
ORA-06512: In "CTXSYS.DRIPARX", line 10
ORA-06512: In "CTXSYS.TEXTINDEXMETHODS", line 359
ORA-04030: Try to alloc 65548 Bytes (CTX PRM heap,draccbx:message buffer) Out of memory
ORA-06512: In "CTXSYS.DRUE", line 191
ORA-06512: In "CTXSYS.DRUE", line 49
ORA-06512: In "CTXSYS.DRUE", line 24
ORA-06512: In "CTXSYS.DRUE", line 186
ORA-06512: In "CTXSYS.DRVDDL", line 682
ORA-04030: Try to alloc 65548 Bytes (CTX PRM heap,draccbx:message buffer) Out of memory
ORA-04030: Try to alloc 65548 Bytes (CTX PRM heap,draccbx:message buffer) Out of memory
ORA-06512: In "CTXSYS.DRUE", line 191
ORA-06512: In "CTXSYS.DRUE", line 49
ORA-06512: In "CTXSYS.DRUE", line 24
ORA-06512: In "CTXSYS.DRVDDL", line 452
ORA-06510: PL/SQL: User Defined Error
BTW:
My oracle 10g run on linux AS3 box with 4xP4 and 6G Mem.
I set pga_aggregate_target=2200M, and at the beginning of creating index, the max pga alloced is about 1100M, but when one patition finished, the error arised and the max pga alloced suddenly reached 3500M. So in every times, the index status is always like below:
P1_ix usable
P2_ix Inprogress
P3_ix Inprogress
P4_ix Inprogress
P5_ix Inprogress
Thx for any help!

Try to increase LARGE_POOL_SIZE.
PGA_AGGREGATE_TARGET is not only parameter that can meddle in parallel execution.
Looks like parallel execution parameters is not correctly set. Check it all, including PARALLEL_EXECUTION_MESSAGE_SIZE.

Bitmap Join Index on Partitioned Table

Are there any restrictions on creating a bitmap join index on a partition table (I think that the bitmap indexes can only be created as local on partitioned tables)?
Thanks in advance
Murthy.

Fair enough. I've included a cut-down set of SQL below.
CREATE TABLE DIMENSION_DATE
DATE_ID NUMBER,
CALENDAR_DATE DATE,
CONSTRAINT DATE_ID
PRIMARY KEY
(DATE_ID)
CREATE UNIQUE INDEX DATE_I1 ON DIMENSION_DATE
(CALENDAR_DATE, DATE_ID);
CREATE TABLE ORDER_F
ORDER_ID VARCHAR2(40 BYTE),
SUBMITTEDDATE_FK NUMBER,
COMPLETEDDATE_FK NUMBER,
-- Then I add the first bitmap index, which works:
CREATE BITMAP INDEX SUBMITTEDDATE_FK ON ORDER_F
(DIMENSION_DATE.DATE_ID)
FROM ORDER_F, DIMENSION_DATE
WHERE ORDER_F.SUBMITTEDDATE_FK = DIMENSION_DATE.DATE_ID;
-- Then attempt the next one:
CREATE BITMAP INDEX completeddate_fk
ON ORDER_F(b.date_id)
FROM ORDER_F, DIMENSION_DATE b
WHERE ORDER_F.completeddate_fk = b.date_id;
-- which results in:
-- ORA-01408: such column list already indexed

SQL Loader, direct path and indexes on partition tables

Hi,
I have a big partitioned table and I have two indexes on it.
When I use SQL Loader to upload data to my table with using OPTIONS (DIRECT=TRUE) UNRECOVERABLE , then it takes almost half hour to load just one record!!
When I remove OPTIONS (DIRECT=TRUE), then it takes just two seconds to upload the same one record.
Am I missing anything? Can I use direct path load on indexed partitioned tables and have reasonable load time ?
An scheduled external job loads almost 100,000 records into this table every hour and I am trying to make the sql*loader performance it as fast as possible.
Any help would be appreciated,
Alan

Hi Alan,
How big is this table and what sort of indexes are they?
An index update using SQL*Loader unrecoverable direct path load is achieved by an isolated sort followed by a nologging merge of the old index and the new mini-index into a new index segment (this according to seminar notes by Jonathan Lewis). This will conceivably take a long time for a large table / large index.
Performance improvements? Are you loading all records into a new partition?
Cheers,
Colin

Index on partitioned table

A table is partitioned. the table is range partitioned and the key for partition is order_date
Column Datatype
ID NUMBER
Order_date DATE
Status VARCHAR2
I have to create an unique index on the column order_date.Will the index need to be partitioned?Is ther any procedure i can create unpartitioned index.
Thanks in advance.

user5698021 wrote:
Will the index need to be partitioned?Is ther any procedure i can create unpartitioned index.You can create index as partitioned or as non-partitioned: Partitioned Index Examples.
SY.

Why don't be used composite index in partition table.

A table has done range list partition.
Then, I create a composite index named INDEX_N2(COLUMN_005, COLUMN_002). --COLUMN_005 AND COLUMN_002 ARE VARCHAR2
When I run the SQL
select 1
from table1 T1
where T1.COLUMN_005 = 'x'
and T1.COLUMN_002 = 'y'
And view the explain plan, INDEX_N2 has been used.
But when I join the COLUMN_005 to other column, the index will not be used.
The SQL is like below.
select 1
from table1 T1, table T2
where T1.COLUMN_005 = T2.COLUMN_002 --T2.COLUMN_002 IS VARCHAR2
and T1.COLUMN_002 = 'y'
The explain plan is like below
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 426 | 44730 | 65367 (1)| 00:13:05 | | |
|* 1 | HASH JOIN | | 426 | 44730 | 65367 (1)| 00:13:05 | | |
| 2 | PARTITION RANGE ALL| | 8 | 792 | 5 (0)| 00:00:01 | 1 | 32 |
| 3 | PARTITION LIST ALL| | 8 | 792 | 5 (0)| 00:00:01 | 1 | 8 |
|* 4 | TABLE ACCESS FULL| TABLE1 | 8 | 792 | 5 (0)| 00:00:01 | 1 | 256 |
| 5 | PARTITION RANGE ALL| | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | 34 |
| 6 | PARTITION LIST ALL| | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | LAST |
| 7 | TABLE ACCESS FULL| TABLE2 | 1112K| 6519K| 65355 (1)| 00:13:05 | 1 | 442 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
4 - SEL$1 / T1@SEL$1
7 - SEL$1 / T2@SEL$1
Predicate Information (identified by operation id):
1 - access("T1"."COLUMN_005"="T2"."COLUMN_002")
4 - filter("T1"."COLUMN_002"='y')
Column Projection Information (identified by operation id):
1 - (#keys=1)
2 - "T1"."COLUMN_005"[VARCHAR2,150]
3 - "T1"."COLUMN_005"[VARCHAR2,150]
4 - "T1"."COLUMN_005"[VARCHAR2,150]
5 - "T2"."COLUMN_002"[VARCHAR2,20]
6 - "T2"."COLUMN_002"[VARCHAR2,20]
7 - "T2"."COLUMN_002"[VARCHAR2,20]
Note
- dynamic sampling used for this statement
My Questin is:
Two columns are include the columns of index.
Why it can't be used?
Thanks

I create a new index on column2, (INDEX_N3)
and change SQL to
select 1 from table T1 where
T1.COLUMN_002 = '848K 36892'
This time INDEX_N3 will be used.
but change SQL to
select 1 from table T1 where
T1.COLUMN_002 = '848K 36892'
and T1.COLUMN_004 = '1000'
The explain plan will show full scan.
Why？
Thanks.

Dropping/Creating index for an individual partition on a partitioned table.

Hi,
I wanted to know how to create and drop index for a single individual partition on a partitioned table.
Thanks..

You are not allowed to create an index on a single partition. All the table, mean all the partitiones must be indexed. You can create local or global indexes on partitioned tables. Local indexes ,imho, are easier maintained. For more info refer to documentation http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_5010.htm#i2062403
Also, index partitions are maintained through corresponding table partitions. For example, if a table partition is truncated or is dropped, the corresponding index partition is also truncated or dropped (in case of locally partitioned indexes of course). In case of globally partitioned indexes, you will have to rebuild the index each time you truncate or drop a table partition.

Local Vs Global Index on partitioned table?

Similar Messages

Maybe you are looking for