Creation of Hash Partitioned Global Index

Hash Partion Index creation
Hi friends,
Could you suggest me whether we can create a hash partitioned index by using syntax as below in 9i.
CREATE INDEX hgidx ON tab (c1,c2,c3) GLOBAL
PARTITION BY HASH (c1,c2)
(PARTITION p1 TABLESPACE tbs_1,
PARTITION p2 TABLESPACE tbs_2,
PARTITION p3 TABLESPACE tbs_3,
PARTITION p4 TABLESPACE tbs_4);
I am getting error ORA-14005 Missing Key word Range.
Thanks in advance for your help.

Yaseer,
Is it possible to create Non-Partitioned and Global Index on Range-Partitioned Table?
Yes
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
You got local index and 3 non-partitioned "NORMAL" b-tree tyep indexes
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Above staement will create non-partitioned index
Here is an example of creating global partitioned indexes
CREATE INDEX month_ix ON sales(sales_month)
   GLOBAL PARTITION BY RANGE(sales_month)
      (PARTITION pm1_ix VALUES LESS THAN (2)
       PARTITION pm2_ix VALUES LESS THAN (3)
       PARTITION pm3_ix VALUES LESS THAN (4)
        PARTITION pm12_ix VALUES LESS THAN (MAXVALUE));Regards

Similar Messages

Non-Partitioned Global Index on Range-Partitioned Table.

Hi All,
Is it possible to create Non-Partitioned Global Index on Range-Partitioned Table?
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Please help me in identifying other 3 indexes types by referring below ouputs!!!
select INDEX_NAME,TABLE_NAME,PARTITIONING_TYPE,LOCALITY from dba_part_indexes where TABLE_NAME='CS_BILLING';
INDEX_NAME TABLE_NAME PARTITI LOCALI
CSB_CLIENT_CODE CS_BILLING RANGE LOCAL
select index_name,index_type,table_name,table_type,PARTITIONED from dba_indexes where table_name='CS_BILLING';
INDEX_NAME INDEX_TYPE TABLE_NAME TABLE_TYPE PAR
CSB_CREATE_DATE NORMAL CS_BILLING TABLE NO
CSB_SUBMIT_ORDER NORMAL CS_BILLING TABLE NO
CSB_CLIENT_CODE NORMAL CS_BILLING TABLE YES
CSB_ORDER_NBR NORMAL CS_BILLING TABLE NO
select INDEX_OWNER,INDEX_NAME,TABLE_NAME,COLUMN_NAME from dba_ind_columns where TABLE_NAME='CS_BILLING';
INDEX_OWNER INDEX_NAME TABLE_NAME COLUMN_NAME
RPADMIN CSB_CREATE_DATE CS_BILLING CREATE_DATE
RPADMIN CSB_SUBMIT_ORDER CS_BILLING SUBMIT_TO_INVOICE
RPADMIN CSB_SUBMIT_ORDER CS_BILLING ORDER_NBR
RPADMIN CSB_CLIENT_CODE CS_BILLING CLIENT_CODE
RPADMIN CSB_ORDER_NBR CS_BILLING ORDER_NBR
select dip.index_name, dpi.locality, dip.partition_name, dip.status
from dba_part_indexes dpi, dba_ind_partitions dip
where dpi.table_name ='CS_BILLING'
and dpi.index_name = dip.index_name;
INDEX_NAME LOCALI PARTITION_NAME STATUS
CSB_CLIENT_CODE LOCAL CSB_2006_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2006_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2007_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2008_4Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_1Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_2Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_3Q USABLE
CSB_CLIENT_CODE LOCAL CSB_2009_4Q USABLE
select * from dba_part_indexes
where table_name ='CS_BILLING'
and locality = 'GLOBAL';
no rows selected
-Yasser
Edited by: YasserRACDBA on Mar 5, 2009 11:45 PM

Yaseer,
Is it possible to create Non-Partitioned and Global Index on Range-Partitioned Table?
Yes
We have 4 indexes on CS_BILLING range-partitioned table, in which one is CBS_CLIENT_CODE(*local partitioned index*) and others are unknown types of index to me??
Means other 3 indexes are what type indexes ...either non-partitioned global index OR non-partitioned normal index??
You got local index and 3 non-partitioned "NORMAL" b-tree tyep indexes
Also if we create index as :(create index i_name on t_name(c_name)) By default it will create Global index. Please correct me......
Above staement will create non-partitioned index
Here is an example of creating global partitioned indexes
CREATE INDEX month_ix ON sales(sales_month)
   GLOBAL PARTITION BY RANGE(sales_month)
      (PARTITION pm1_ix VALUES LESS THAN (2)
       PARTITION pm2_ix VALUES LESS THAN (3)
       PARTITION pm3_ix VALUES LESS THAN (4)
        PARTITION pm12_ix VALUES LESS THAN (MAXVALUE));Regards

Question about Global index and Table Partitions

I have created a global index for a partitioned table now in the future the partitions will be dropped in the table. Do I need to do anything to the global index? Does it need to be rebuilt or would it be ok if partitions get dropped in the table?

>
I have created a global index for a partitioned table now in the future the partitions will be dropped in the table. Do I need to do anything to the global index? Does it need to be rebuilt or would it be ok if partitions get dropped in the table?
>
You can use the UPDATE INDEXES clause. That allows users to keep using the table and Oracle will keep the global indexes updated.
Otherwise, as already stated all global indexes will be marked UNUSABLE.
See 'Dropping Partitions' in the VLDB and Partitioning Guide
http://docs.oracle.com/cd/E11882_01/server.112/e25523/part_admin002.htm#i1007479
>
If local indexes are defined for the table, then this statement also drops the matching partition or subpartitions from the local index. All global indexes, or all partitions of partitioned global indexes, are marked UNUSABLE unless either of the following is true:
You specify UPDATE INDEXES (Cannot be specified for index-organized tables. Use UPDATE GLOBAL INDEXES instead.)
The partition being dropped or its subpartitions are empty

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.

11g interval partitioning and global index maintenance

hi gurus,
in 11g interval partitioning system can automatically manage the creation of new partitions based on data.
in this case do we need to manage global indexes?
in earlier versions, we have to update global indexes whenever there is a partition maintenance operation.
please suggest.
thanks,
charles

user570138 wrote:
in earlier versions, we have to update global indexes whenever there is a partition maintenance operation.In 10gR2 you don't need to update/rebuild a global index after adding a partition to the base table.
So it should be the same when using interval partitioning.
Regards
Maurice

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.

Global Index on several partitions with each partition on different servers

Hi,
I have a table divided into 4 partitions. Each partition is on a different server. Currenlty the indexes are set per partition. I would like to create a global index which would work on all partitions. How could I create global index which will work on all 4 partitions/servers ? (My support team is telling me that it is not possible with different servers. It only works for several partitions on 1 physical server. Is it true ?)
Thanks,
Nicolas

harry76 wrote:
Hi,
Are you sure this is an Oracle database. I think SQL Server has this kind of architecture in some cases?
Not quite - in SQL Server a single instance can control multiple databases and a partitioned object can have different partitions in different databases; but the SQL Server partitioning strategy is always the equivalent of "local partitioned indexes".
Maybe this system is using partitioned views. It is possible to create clone table structures with disjoint data sets across multiple databases and then create a UNION ALL view of the tables with a predicate on each query block identifying the data in each database. The optimizer can then do "partition elimination" if your query specifies the column(s) used in the defining predicates.
Regards
Jonathan Lewis

Table partitioning and global indexing

hello all,
the requirement is to do table partitioning with global indexing! & also thr r almost 60 crores of rows are there! so can you tell me the way which can be done better and also please provide me the procedure with documents?
thanks in advance!

Hi,
have a look at online redefinition of a table, see Oracle Manual (10.2): http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/tables.htm#ADMIN01514
The steps are described in the manual.
Herald ten Dam
Superconsult.nl

Drop Partition update Global Indexes

hello Gurus,
what will happen internally when issue a command
alter table tab_name drop partition part_name update global indexes;
why my insert statement waiting to complete this task on " cursor: pin S wait on X "
thanks in advance ..

Several times i also noticed that wait event for some jobs on 10 2 0 4 on hpux.
I didn't found out what was the reason.
It seems this wait event can be easly related to some bugs.
http://karenmorton.blogspot.com/2008/08/strange-parsing-behavior.html
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/waitevents003.htm#sthref3012

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.

Uneven distribution in Hash Partitioning

Version :11.1.0.7.0 - 64bit Production
OS :RHEL 5.3
I have a range partitioning on ACCOUNTING_DATE column and have 24 monthly partitions.
To get rid of buffer busy waits on index, i have created global partitioned index using below ddl
DDL :
CREATE INDEX IDX_GL_BATCH_ID ON SL_JOURNAL_ENTRY_LINES(GL_BATCH_ID)
GLOBAL PARTITION BY HASH (GL_BATCH_ID) PARTITIONS 16 TABLESPACE OTC_IDX PARALLEL 8 INITRANS 8 MAXTRANS 8 PCTFREE 0 ONLINE;After index creation, i realized that only one index hash partition got all rows.
select partition_name,num_rows from dba_ind_partitions where index_name='IDX_GL_BATCH_ID';
PARTITION_NAME                   NUM_ROWS
SYS_P77                                 0
SYS_P79                                 0
SYS_P80                                 0
SYS_P81                                 0
SYS_P83                                 0
SYS_P84                                 0
SYS_P85                                 0
SYS_P87                                 0
SYS_P88                                 0
SYS_P89                                 0
SYS_P91                                 0
SYS_P92                                 0
SYS_P78                                 0
SYS_P82                                 0
SYS_P86                                 0
SYS_P90                         256905355As far as i understand, HASH partitioning will distribute evenly. By looking at above distribution, i think, i did not benefit of having multiple insert points using HASH partitioning as well.
Here is index column statistics :
select TABLE_NAME,COLUMN_NAME,NUM_DISTINCT,NUM_NULLS,LAST_ANALYZED,SAMPLE_SIZE,HISTOGRAM,AVG_COL_LEN from dba_tab_col_statistics where table_name='SL_JOURNAL_ENTRY_LINES' and COLUMN_NAME='GL_BATCH_ID';
TABLE_NAME                     COLUMN_NAME          NUM_DISTINCT NUM_NULLS LAST_ANALYZED        SAMPLE_SIZE HISTOGRAM       AVG_COL_LEN
SL_JOURNAL_ENTRY_LINES         GL_BATCH_ID                     1          0 2010/12/28 22:00:51    259218636 NONE                      4

It looks like that inserted data has always the same value for the partitioning key: it is expected that in this case the same partition is used because
>
For optimal data distribution, the following requirements should be satisfied:
Choose a column or combination of columns that is unique or almost unique.
Create multiple partitions and subpartitions for each partition that is a power of two. For example, 2, 4, 8, 16, 32, 64, 128, and so on.
>
See http://download.oracle.com/docs/cd/E11882_01/server.112/e16541/part_avail.htm#VLDBG1270.
Edited by: P. Forstmann on 29 déc. 2010 09:06

Accessing Tables using global index rowid is taking too long.

I am using Oracle 10.2.0.4.0. I am having tables which are ~100+GB in size which is range partitioned on a date column and hash subpartitioned on primary key column. And accessing these tables using global index row id using idex range scan( size of those indexes are ~7+ GB) taking ~5+ mins which results in ~1000 rows as out put. So is this means there is some structural problem with tables/indexes or its something issue at block level? How to dig more into this issue?

Hi,
930254 wrote:
I am using Oracle 10.2.0.4.0. I am having tables which are ~100+GB in size which is range partitioned on a date column and hash subpartitioned on primary key column. And accessing these tables using global index row id using idex range scan( size of those indexes are ~7+ GB) taking ~5+ mins which results in ~1000 rows as out put. So is this means there is some structural problem with tables/indexes or its something issue at block level? How to dig more into this issue?once you get a chance to run the query and collect some diagnostic info, here are the questions that you should ask yourself:
1) where is the 5 mins spent? doing index range scan itself, doing table index access by global rowid, waiting for something, doing something else?
2) how many reads are there and what kind (logical, physical, direct path)? per the entire query and per index range scan
3) is there any aggregation in the query? if there is, then 1000 rows output doesn't mean anything -- you could have to access millions or billions of rows to produce a 1000 row output in an aggregate query
The best tool to answer these questions is dbms_xplan.
Best regards,
Nikolay

"UPDATE GLOBAL INDEXES"를 사용하여, DDL 처리와 동시에 GLOBAL INDEX를 자동 관리하는 방안

제품 : ORACLE SERVER
작성날짜 :
"UPDATE GLOBAL INDEXES"를 사용하여, DDL 처리와 동시에 GLOBAL INDEX를 자동 관리하는 방안
==========================================================================================
PURPOSE
이 문서에서는 다음과 같은 사항을 기술한다.
1. 새로 추가된 기능으로, 테이블 파티션에 대한 DDL 수행시
지정 가능한 "UPDATE GLOBAL INDEXES" 절에 대한 설명
2. UPDATE GLOBAL INDEXES를 사용하는 것 보다는 REBUILD INDEX를
사용하여야 하는 성능상의 고려사항.
SCOPE
Oracle Partitioning Option은 8~10g Standard Edition에서는 지원하지
않는다.
Explanation
테스트를 위해 먼저 4개의 테이블을 생성한다.
1. RANGE partitioned table을 생성한 후 GLOBAL index를 만든다:
SQL> create table orders (
2 order_no number,
3 part_no varchar2(40),
4 ord_date date
5 )
6 partition by range (ord_date)
7 (partition Q1 values less than (TO_DATE('01-APR-1999','DD-MON-YYYY')),
8 partition Q2 values less than (TO_DATE('01-JUL-1999','DD-MON-YYYY')),
9 partition Q3 values less than (TO_DATE('01-OCT-1999','DD-MON-YYYY')),
10 partition Q4 values less than (TO_DATE('03-JAN-2000','DD-MON-YYYY'))
11 );
Table created.
SQL> create index orders_global_idx
2 on orders(ord_date)
3 global partition by range (ord_date)
4 (partition GLOBAL1 values less than (TO_DATE('01-APR-1999','DD-MON-YYYY')
5 partition GLOBAL2 values less than (TO_DATE('01-SEP-1999','DD-MON-YYYY')
6 partition GLOBAL3 values less than (TO_DATE('01-DEC-2000','DD-MON-YYYY')
7 partition GLOBAL4 values less than (MAXVALUE)
8 );
Index created.
SQL> select substr(index_name,1,20) index_name,
2 substr(partition_name,1,20) part_name,
3 status
4 from dba_ind_partitions
5 where index_name= 'ORDERS_GLOBAL_IDX' order by partition_name;
INDEX_NAME PART_NAME STATUS
ORDERS_GLOBAL_IDX GLOBAL1 USABLE
ORDERS_GLOBAL_IDX GLOBAL2 USABLE
ORDERS_GLOBAL_IDX GLOBAL3 USABLE
ORDERS_GLOBAL_IDX GLOBAL4 USABLE
SQL> insert into orders values (1,100,TO_DATE('02-FEB-1999','DD-MON-YYYY'));
2. HASH partitioned table을 생성 한 후 GLOBAL index를 만든다:
SQL> CREATE TABLE emp_hpart(
2 empno NUMBER(4) NOT NULL,
3 ename VARCHAR2(10),
4 sal NUMBER(7,2))
5 PARTITION BY HASH(sal)
6 (PARTITION H1, PARTITION H2, PARTITION H3, PARTITION H4);
Table created.
SQL> CREATE INDEX emp_global_HASH_idx ON emp_hpart(ename)
2 GLOBAL PARTITION BY RANGE (ename)
3 (PARTITION p1 VALUES LESS THAN ('N') ,
4 PARTITION p2 VALUES LESS THAN (MAXVALUE));
Index created.
SQL> select substr(index_name,1,20) index_name,
2 substr(partition_name,1,20) part_name,status
3 from dba_ind_partitions
4 where index_name= 'EMP_GLOBAL_HASH_IDX' order by partition_name;
INDEX_NAME PART_NAME STATUS
EMP_GLOBAL_HASH_IDX P1 USABLE
EMP_GLOBAL_HASH_IDX P2 USABLE
SQL> insert into emp_hpart values (1,'AAA',100);
3. COMPOSITE partitioned table을 생성한 후 GLOBAL index를 만든다:
SQL> CREATE TABLE emp_composite(
2 empno NUMBER(4) NOT NULL,
3 ename VARCHAR2(10),
4 sal NUMBER(6))
5 PARTITION BY RANGE(empno)
6 SUBPARTITION BY HASH(sal) SUBPARTITIONS 4
7 (PARTITION p1 VALUES LESS THAN (50),
8 PARTITION p2 VALUES LESS THAN (100),
9 PARTITION p3 VALUES LESS THAN (150),
10 PARTITION p4 VALUES LESS THAN (MAXVALUE));
Table created.
SQL> CREATE INDEX emp_global_composite_idx ON emp_composite(ename)
2 GLOBAL PARTITION BY RANGE (ename)
3 (PARTITION p1 VALUES LESS THAN ('N') ,
4 PARTITION p2 VALUES LESS THAN (MAXVALUE));
Index created.
SQL> select substr(index_name,1,20) index_name,
2 substr(partition_name,1,20) part_name,status
3 from dba_ind_partitions
4 where index_name= 'EMP_GLOBAL_COMPOSITE_IDX' order by
partition_name;
INDEX_NAME PART_NAME STATUS
EMP_GLOBAL_COMPOSITE P1 USABLE
EMP_GLOBAL_COMPOSITE P2 USABLE
SQL> insert into emp_composite values (1,'AAA',100);
4. LIST partitioned table을 생성 한 후 GLOBAL index를 만든다:
SQL> CREATE TABLE locations (
2 location_id NUMBER, street_address VARCHAR2(80), postal_code
CHAR(12),
3 city VARCHAR2(80), state_province CHAR(2), country_id
VARCHAR2(20))
4 PARTITION BY LIST (state_province)
5 (PARTITION region_east
6 VALUES ('MA','NY','CT','NH','ME','MD','VA','PA','NJ'),
7 PARTITION region_west
8 VALUES ('CA','AZ','NM','OR','WA','UT','NV','CO'),
9 PARTITION region_south
10 VALUES ('TX','KY','TN','LA','MS','AR','AL','GA'),
11 PARTITION region_central
12 VALUES ('OH','ND','SD','MO','IL','MI',NULL,'IA'));
Table created.
SQL> create index loc_global_idx
2 on locations (state_province)
3 global partition by range (state_province)
4 (partition p1 values less than ('NV'),
5 partition p2 values less than (maxvalue));
Index created.
SQL> INSERT INTO locations VALUES
2 ( 1000,'1297 Via Cola di Rie','00989','Roma',NULL,'IT');
1 row created.
SQL> select substr(index_name,1,20) index_name,
substr(partition_name,1,20)
2 part_name , status
3 from dba_ind_partitions
4 where index_name= 'LOC_GLOBAL_IDX' order by partition_name;
INDEX_NAME PART_NAME STATUS
LOC_GLOBAL_IDX P1 USABLE
LOC_GLOBAL_IDX P2 USABLE
*** 오라클 8/8i : UPDATE GLOBAL INDEXES 절을 사용하지 않았을 때
SQL> select substr(index_name,1,20) index_name,
2 substr(partition_name,1,20) part_name,status
3 from dba_ind_partitions
4 where index_name= 'ORDERS_GLOBAL_IDX' order by partition_name;
INDEX_NAME PART_NAME STATUS
ORDERS_GLOBAL_IDX GLOBAL1 USABLE
ORDERS_GLOBAL_IDX GLOBAL2 USABLE
ORDERS_GLOBAL_IDX GLOBAL3 USABLE
ORDERS_GLOBAL_IDX GLOBAL4 USABLE
SQL> ALTER TABLE orders DROP PARTITION q2;
Table altered.
SQL> select substr(index_name,1,20) index_name,
substr(partition_name,1,20)
2 part_name, status
3 from dba_ind_partitions
4 where index_name= 'ORDERS_GLOBAL_IDX' order by partition_name;
INDEX_NAME PART_NAME STATUS
ORDERS_GLOBAL_IDX GLOBAL1 UNUSABLE
ORDERS_GLOBAL_IDX GLOBAL2 UNUSABLE
ORDERS_GLOBAL_IDX GLOBAL3 UNUSABLE
ORDERS_GLOBAL_IDX GLOBAL4 UNUSABLE
=> Oracle 9i 이전 버젼에서는, partitioned table의 특정 파티션에 대해
DDL을 수행하면, 해당 파티션이 비어있는 상태가 아니라면,
GLOBAL index에 대한 상태를 invalidate 시킨다.
=> Oracle 9i에서 UPDATE GLOBAL INDEXES 절을 수행하면, 테이블의
파티션에 대한 DDL 작업을 수행하는 동안 GLOBAL INDEX에
대한 관리 작업을 자동으로 수행하게 된다.
그러나 일부 작업에 대해서는, 위와 같은 작업이 허용되지
않는다.
*** UPDATE GLOBAL INDEXES 절과 ADD PARTITION 절의 동시 사용
1. RANGE partitioned table:
SQL> ALTER TABLE orders ADD PARTITION q5
2 values less than (TO_DATE('03-JUN-2000','DD-MON-YYYY'))
3 UPDATE GLOBAL INDEXES;
ALTER TABLE orders ADD PARTITION q5
ERROR at line 1:
ORA-30564: Index maintainence clause not allowed for ADD partition to
RANGE
partitioned tables
UPDATE GLOBAL INDEXES 절은 다음 경우에만 사용할 수 있다.
=> HASH partitioned table에 partition 추가
=> Composite partitioned table에 subpartition 추가
| RANGE partitioned table에 일반적인 방식으로 작업 수행 |
SQL> ALTER TABLE orders ADD PARTITION q5
2 values less than (TO_DATE('03-JUN-2000','DD-MON-YYYY'));
Table altered.
SQL> @sel
INDEX_NAME PART_NAME STATUS
ORDERS_GLOBAL_IDX GLOBAL1 USABLE
ORDERS_GLOBAL_IDX GLOBAL2 USABLE
ORDERS_GLOBAL_IDX GLOBAL3 USABLE
ORDERS_GLOBAL_IDX GLOBAL4 USABLE
2. HASH partitioned table:
| UPDATE GLOBAL INDEXES절을 HASH partitioned table 에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_hpart ADD PARTITION q5
2 UPDATE GLOBAL INDEXES;
Table altered.
SQL> @sel
INDEX_NAME PART_NAME STATUS
EMP_GLOBAL_HASH_IDX P1 USABLE
EMP_GLOBAL_HASH_IDX P2 USABLE
3. COMPOSITE partitioned table:
| UPDATE GLOBAL INDEXES 절을 COMPOSITE partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_composite MODIFY PARTITION p1 add subpartition h5
2 UPDATE GLOBAL INDEXES;
Table altered.
SQL> @sel
INDEX_NAME PART_NAME STATUS
EMP_GLOBAL_COMPOSITE P1 USABLE
EMP_GLOBAL_COMPOSITE P2 USABLE
4. LIST partitioned table
| LIST partitioned table에 대해서는 일반적인 방법 사용 |
SQL> alter table locations ADD
2 partition nomansland values ('XX');
Table altered.
SQL> @sel
INDEX_NAME PART_NAME STATUS
LOC_GLOBAL_IDX P1 USABLE
LOC_GLOBAL_IDX P2 USABLE
*** UPDATE GLOBAL INDEXES 절과 DROP PARTITION절의 동시사용
1. RANGE partitioned table:
| UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE orders DROP PARTITION q2 UPDATE GLOBAL INDEXES;
Table altered.
2. HASH partitioned table:
HASH partitioned table에서는 DROP 명령을 수행할 수 없으며,
COALESCE를 대신 사용함 (문서 마지막 부분을 참조)
3. COMPOSITE partitioned table:
| UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_composite DROP PARTITION p2
2 UPDATE GLOBAL INDEXES;
Table altered.
4. LIST partitioned table:
| UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> alter table locations DROP PARTITION
2 region_south
3 UPDATE GLOBAL INDEXES;
Table altered.
*** UPDATE GLOBAL INDEXES 절과 SPLIT PARTITION 절의 동시 사용
1. RANGE partitioned table
| UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE orders SPLIT PARTITION q3 AT
2 (TO_DATE('15-SEP-1999','DD-MON-YYYY'))
3 INTO (PARTITION q3_1, PARTITION q3_2)
4 UPDATE GLOBAL INDEXES;
Table altered.
2. HASH partitioned table
HASH partitioned table에서는 SPLIT 명령을 수행할 수 없으며,
ADD를 대신 사용함 (윗 부분에 기술하였음)
3. COMPOSITE partitioned table
| UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_composite SPLIT PARTITION p2 AT (80)
2 INTO (PARTITION p2_1, PARTITION p2_2)
3 UPDATE GLOBAL INDEXES;
Table altered.
4. LIST partitioned tables:
| UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> alter table locations SPLIT PARTITION region_east
2 VALUES ('MA','NJ')
3 INTO (PARTITION region_east_1, PARTITION region_east_2)
4 UPDATE GLOBAL INDEXES;
Table altered.
*** UPDATE GLOBAL INDEXES 절과 MERGE PARTITION 절의 동시 사용
1. RANGE partitioned table
| UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE orders MERGE PARTITIONS q2, q3 INTO PARTITION q3
2 UPDATE GLOBAL INDEXES;
Table altered.
2. HASH partitioned table
HASH partitioned table에서는 MERGE 명령을 수행할 수 없으며,
COALESCE를 대신 사용함 (문서 마지막 부분을 참조)
3. COMPOSITE partitioned table
| UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_composite MERGE PARTITIONS p1, p2
2 INTO PARTITION p2
3 UPDATE GLOBAL INDEXES;
Table altered.
4. LIST partitioned table:
| UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> alter table locations MERGE PARTITIONS region_east,region_west
2 INTO PARTITION region_north
3 UPDATE GLOBAL INDEXES;
Table altered.
*** UPDATE GLOBAL INDEXES 절과 EXCHANGE PARTITION 절의 동시사용
1. RANGE partitioned tables
| UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE orders EXCHANGE PARTITION q3 WITH TABLE t_orders
2 UPDATE GLOBAL INDEXES;
Table altered.
If GLOBAL indexes exist on the TABLE of exchange, they are left UNUSABLE:
SQL> create index t_orders_global_idx
2 on t_orders(ord_date)
3 global partition by range (ord_date)
4 (partition GLOBAL1 values less than (TO_DATE('01-APR-1999','DD-MON-YYY
Y')),
5 partition GLOBAL2 values less than (TO_DATE('01-SEP-1999','DD-MON-YYY
Y')),
6 partition GLOBAL3 values less than (TO_DATE('01-DEC-1999','DD-MON-YYY
Y')),
7 partition GLOBAL4 values less than (MAXVALUE) );
Index created.
SQL> ALTER TABLE orders EXCHANGE PARTITION q3 WITH TABLE t_orders
2 UPDATE GLOBAL INDEXES;
Table altered.
SQL> @sel
INDEX_NAME PART_NAME STATUS
T_ORDERS_GLOBAL_IDX GLOBAL1 UNUSABLE
T_ORDERS_GLOBAL_IDX GLOBAL2 UNUSABLE
T_ORDERS_GLOBAL_IDX GLOBAL3 UNUSABLE
T_ORDERS_GLOBAL_IDX GLOBAL4 UNUSABLE
ORDERS_GLOBAL_IDX GLOBAL1 USABLE
ORDERS_GLOBAL_IDX GLOBAL2 USABLE
ORDERS_GLOBAL_IDX GLOBAL3 USABLE
ORDERS_GLOBAL_IDX GLOBAL4 USABLE
2. HASH partitioned tables
| UPDATE GLOBAL INDEXES를 HASH partitioned table에서 사용하 |
| 지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_hpart EXCHANGE PARTITION H1 WITH TABLE t_emp_hpart
2 UPDATE GLOBAL INDEXES;
Table altered.
3. COMPOSITE partitioned tables
SQL> ALTER TABLE emp_composite EXCHANGE PARTITION p1 WITH TABLE t_emp_composi
te;
ALTER TABLE emp_composite EXCHANGE PARTITION p1 WITH TABLE t_emp_composite
ERROR at line 1:
ORA-14291: cannot EXCHANGE a composite partition with a non-partitioned table
| UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_composite EXCHANGE SUBPARTITION SYS_SUBP286
2 WITH TABLE t_emp_composite
3 UPDATE GLOBAL INDEXES;
Table altered.
4. LIST partitioned tables:
| UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE locations EXCHANGE PARTITION region_east
2 WITH TABLE t_locations
3 UPDATE GLOBAL INDEXES;
Table altered.
*** UPDATE GLOBAL INDEXES절과 MOVE PARTITION 절의 동시사용
1. RANGE partitioned table
| UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE orders MOVE PARTITION q3 TABLESPACE example
2 UPDATE GLOBAL INDEXES;
Table altered.
2. HASH partitioned table
| UPDATE GLOBAL INDEXES를 HASH partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_hpart MOVE PARTITION H1 TABLESPACE example
2 UPDATE GLOBAL INDEXES;
Table altered.
3. COMPOSITE partitioned table
SQL> ALTER TABLE emp_composite MOVE PARTITION p1 TABLESPACE example;
ALTER TABLE emp_composite MOVE PARTITION p1 TABLESPACE example
ERROR at line 1:
ORA-14257: cannot move partition other than a Range or Hash partition
SQL> ALTER TABLE emp_composite MOVE PARTITION p1 TABLESPACE example
2 UPDATE GLOBAL INDEXES;
ALTER TABLE emp_composite MOVE PARTITION p1 TABLESPACE example
ERROR at line 1:
ORA-14257: cannot move partition other than a Range or Hash partition
4. LIST partitioned table
| UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE locations MOVE PARTITION region_east
2 TABLESPACE TS_DATA1
3 UPDATE GLOBAL INDEXES;
Table altered.
*** UPDATE GLOBAL INDEXES 절과 TRUNCATE PARTITION 절의 동시 사용
1. RANGE partitioned tables
| UPDATE GLOBAL INDEXES를 RANGE partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE orders TRUNCATE PARTITION q3
2 UPDATE GLOBAL INDEXES;
Table truncated.
2. HASH partitioned tables
| UPDATE GLOBAL INDEXES를 HASH partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_hpart TRUNCATE PARTITION H1
2 UPDATE GLOBAL INDEXES;
Table truncated.
3. COMPOSITE partitioned table
| UPDATE GLOBAL INDEXES를 COMPOSITE partitioned table에서 사용하지|
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_composite TRUNCATE PARTITION p1
2 UPDATE GLOBAL INDEXES;
Table truncated.
4. LIST partitioned table
| UPDATE GLOBAL INDEXES를 LIST partitioned table에서 사용하지 |
| 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE locations TRUNCATE PARTITION region_east
2 UPDATE GLOBAL INDEXES;
Table truncated.
*** UPDATE GLOBAL INDEXES 절과 COALESCE PARTITION 절의 동시사용
1. RANGE partitioned table
Range partitioned table에는 coalesce 기능이 지원되지 않음.
2. HASH partitioned table
| UPDATE GLOBAL INDEXES를 HASH partitioned table에서 사용 |
| 하지 않을 경우 global index가 UNUSABLE 상태로 남음 |
SQL> ALTER TABLE emp_hpart COALESCE PARTITION
2 UPDATE GLOBAL INDEXES;
Table altered.
3. COMPOSITE partitioned table
Composite partitioned table에 대해서는 coalesce 기능이 지원되지 않음.
4. LIST partitioned table
List partitioned table에 대해서는 coalesce 기능이 지원되지 않음.
*** 성능상의 문제로 인해 UPDATE GLOBAL INDEXES 절을 사용하는 대신
*** REBUILD INDEX를 사용하여야 할 경우
UPDATE GLOBAL INDEXES절을 사용할 경우
1 이전 버전에서는 단순히 invalid 상태로 표시하고 종료되었던 작업이
인덱스 관리 작업까지 병행해 수행 되므로 partition DDL operation
작업 수행 시간이 더 오래 걸린다.
2 DROP, TRUNCATE, EXCHANGE 작업이 더 오래 걸린다. 이전에는 데이터
딕셔너리상의 정보만을 갱신하는데 반해, UPDATE GLOBAL INDEXES절을
사용할 경우, partition 내의 모든 row에 대한 scan 작업이 수행
되기 때문이다.
3 GLOBAL INDEX에 대한 갱신 작업을 통한 변경 사항이 redo log 및 rollback에
남게 된다.
4 row의 갯수가 작을 경우, update global index절을 사용하여 작업하는 것이
편리하다.
5 인덱스를 수동으로 rebuild 할 때 까지 애플리케이션 응답 속도가 현격
하게 저하되는 것을 피할 수 있다.
INDEX REBUILD를 사용할 경우
1 전체 인덱스를 rebuild 하면, index가 좀더 효과적으로 구성된다.
2 인덱스를 rebuild 하면, 사용자가 인덱스에 대한 구성을 수동으로
변경할 수 있다.
Example
Reference Documents
<Note:139707.1>

Hash Partitioning

Hi All,
Does hash partitioning always use the same hashing function, and will it always produce the same result if a new table is created with the same number of hash partitions hashed on the same field?
For example, I have to join a multi-million record data set to table1 this morning. table1 is hash partitioned on row_id into 32 partitions.
If I create a temp table to hold the data I want to join and hash partition it likewise into 32 partitions on row_id, will any given record from partition number N in my new table find its match in partition number N of table?
If so, that would allow us to join one partition at a time which performs exponentially better in the resource-contested environment.
I hope you can help.

Using 10gR2
Partition pruning does occur when joined to a global temporary table with hash partitioning. Providing the parimary key on the global temp table is the key used for hashing the relational table:
SQL> create table t (
2    a number)
3    partition by hash(a) (
4      partition p1 ,
5      partition p2 ,
6      partition p3 ,
7      partition p4
8    )
9 /
Table created.
SQL>
SQL> alter table t add (constraint t_pk primary key (a)
2 using index local (partition p1_idx
3                   , partition p2_idx
4                   , partition P3_idx
5                   , partition p4_idx)
6 )
7 /
Table altered.
SQL> insert into t (a) values (1);
1 row created.
SQL> insert into t (a) values (2);
1 row created.
SQL> insert into t (a) values (3);
1 row created.
SQL> insert into t (a) values (4);
1 row created.
SQL> commit;
Commit complete.
SQL>
SQL> create global temporary table tm (a number)
2 /
Table created.
SQL> insert into tm (a) values (2);
1 row created.
SQL> set autotrace traceonly explain
SQL> select tm.a from tm, t
2 where tm.a = t.a
3 /
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=26)
   1    0   NESTED LOOPS (Cost=2 Card=1 Bytes=26)
   2    1     TABLE ACCESS (FULL) OF 'TM' (TABLE (TEMP)) (Cost=2 Card=
          1 Bytes=13)
   3    1     PARTITION HASH (ITERATOR) (Cost=0 Card=1 Bytes=13)
   4    3       INDEX (UNIQUE SCAN) OF 'T_PK' (INDEX (UNIQUE)) (Cost=0
           Card=1 Bytes=13)As you can see from the above, a full scan was performed on the global temp table, but partition pruning occured on TM. So, in theory, whatever data you load the global temp table with, will be matched to the partition.
P;

Creation of Hash Partitioned Global Index

Similar Messages

Maybe you are looking for