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ç

Similar Messages

Local Index vs Global Index

Hi,
I am aware that Local Index and Global Index methods are attached with Partitions, like local is pertaining to a particular partition. We need to update global index while dropping a partition or using exchange partitions.
What I know is very little, please provide more details, thank you.

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_3001.htm#SQLRF01001
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_3001.htm#i2087440
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_3001.htm#i2131064
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_3001.htm#i2151566
http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_3001.htm#CIHCAAGD
Regards
Etbin
Edited by: Etbin on 13.3.2011 15:55
First two links added in order to start with alter table

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

Keeping stats up to date for partitioned tables

Hi,
Oracle version 10.2.0.4
I have a partioned table. I would like to keep stats up-to-date.
Can I just run a single command to update table stats, indexes and partitions please?
exec dbms_stats.gather_table_stats(user, 'TABLE', cascade=>true)or I also need to run exec dbms_stats.gather_table_stats(user, 'TABLE', granularity=>partition)
thanks,
Ashok
Edited by: 902986 on 27-Oct-2012 11:06
Edited by: 902986 on 27-Oct-2012 11:07

thanks
yes there were many indexes on the original non-partitioned table and I have created another table partitioned and now populating it with the data from the original table. the new table is partitioned on a date range column for all years before 2012, then for 2012, 2013 and so forth.
the indexes are all created locally bar a unique index (as per original table), created globally to enforce uniqueness across the table itself. the search will always look to year to date say 1st jan 2012 tilll today for risk analysis. the partition is on that date column and there is also a local index on that date column as well, to avoid table scan (tested with disabling that index, predictably did table scan and was less efficient).
in a DW environment, I don't see much value in having global index bar for primary key/unique constraint. I do realise that if the query crosses more than one partition, say 2 partitions, there will be two b-tree local index scans rather than one, but that would be rare (from the way they query the table).
therefore my plan is to perform a full table stats with cascade=>true and measure the time it takes and plan to do the same if the maintenance window allows it.
thanks again for your help
Edited by: 902986 on 28-Oct-2012 13:24

PARTITION TABLE 이란?

제품 : ORACLE SERVER
작성날짜 : 2004-08-13
PARTITION TABLE 이란?
=====================
PURPOSE
partition table에 대한 기본 개념입니다.
SCOPE
8~10g Standard Edition 에서는 Partitioning Option 은 지원하지 않습니다.
Explanation
ORACLE 8에서 제공하는 partition table 에 대해 알아보자.
1. Partitioned Table이란?
partitioning 이란 큰 object 를 작고 manage 가 가능하게 분리하는 것을 의미하며,
table 이나 index 에서만 가능하고 cluster, snapshot 은 불가능하다.
각 partition 은 별개의 segment 에 저장되어진다.
Oracle8에서 table 은 기본이 되는 key value 에 의해 partition 으로 분리되어진다.
각 partition은 독립적으로 운영된다.
예를 들어 table partition 은 DML (insert, update, delete) 문에 의한
transaction 을 다른 partition 에 영향을 주지 않고 복구가 가능하다.
DBA_TAB_PARTITIONS 에 각 partition 의 storage 정보 등을 갖는다.
2. 어떻게 partitioned Table을 생성하는가 ?
partition key(s)와 개개의 partition 에 범위를 주어 생성한다.
이 partition 이름은 주어질 수 있으며 만일 생략되면 ORACLE 이 SYS_Pn 으로
generate 한다.
예제 :
emp partition 을 EMPNO column을 partition key 로 하여 생성해 보자.
CREATE TABLE emp
(EMPNO NUMBER(5),
PARTITION BY RANGE(EMPNO)(
partition emp_p1 VALUES LESS THAN (2000),
partition emp_p2 VALUES LESS THAN (4000),
partition emp_p3 VALUES LESS THAN (MAXVALUE));
select * from emp partition (emp_p3);
ACCT_NO PERSON SALES_AMOUNT WEEK_NO
1000 abc 10 30
insert into emp partition (emp_p3) values (7000, 'bcd', 10, 30);
3. partition table 관련한 dictionary 정보
. storage parameters
--> DBA_TAB_PARTITIONS
. partiton table 의 upper partition bound
--> select high_value, partition_position from sys.dba_tab_partitions
where table_name = 'SALES';
4. Partitioned tables의 제약점은?
a) Datatype 제약
Partitioned table은 LONG 이나 LONG RAW datatype을 가질 수 없다.
또한 LOB datatypes (BLOB, CLOB, NCLOB, or BFILE), object types을 가질 수
없다. 이 LOB type 은 V8.1부터는 가능할 것으로 기대된다.
b) Clusters 는 partition 될 수 없다.
c) Bitmap 제한
bitmap 은 local partitioned table 에서만 가능하고 global indexes 로는
불가능하다.
d) Physical 제한
Partitioned table은 여러 개의 database에 걸쳐 있을 수 없다.
오직 1 instance 에서만 가능하다.
5. Local Prefixed와 Local Non-Prefixed index란?
Local index란 partitioned table 의 index로 이는 오로지 한 partition 의
row들을 나타내는 ROWID 를 갖는 index 이다.
이는 주로 partition table 의 partition key 로 사용되어진다.
이를 equi-partitioning 이라 한다.
Prefixed index는 partition key 에 대응하는 leading index key(s) 이다.
Non-Prefixed index 는 leading column 이 되는 partition key 를 포함하지 않는
index key 이다.
6. Global index란?
global index 는 prefix 만 제공하며 non-prefix 는 제공하지 않는다.
global Index 는 전체 table 의 ROWID 처럼 사용되어진다.
7. partitions을 사용하는 방법?
Partition-Extended Table Name을 사용한다.
즉 "schema.table PARTITION part_name" 를 사용하는데 schema 는 schema owner
이고 table은 base table 이름이며, PARTITION 은 써도 되고 안 써도 되는 용어이고,
partition_name은 partition 의 name 이다.
이 partition-extented table 이름은 다음 문장에서 사용되어진다.
INSERT
UPDATE
DELETE
LOCK TABLE
SELECT
Q) partition 에 insert 시:
SQL> insert into sales partition (p8) values (7000, 'bcd', 10, 30);
Q) partition을 delete시:
SQL> delete from sales partition (p8);
Q) partition을 update 시:
SQL> update sales partition (p8) set sales_amount = 20;
Q) partition을 select 시:
SQL> select * from sales PARTITION (Q4);
8. partition-extended table 이름의 제약?
. remote schema object를 포함할 수 없다.
partition-extended table name 은 dblink 를 포함할 수 없으며, dblink 를 통해
table 로 변환 가능한 synonym 을 포함할 수 없다.
만일 remote partition의 사용을 원할 때에는 remote site 에서
partitioned-extended table 이름을 사용하여 view 를 생성할 수 있다.
. partition-extended table 이름은 PL/SQL에서 사용되지 않는다.
partition-extended table 이름을 사용한 SQL 문은 DBMS_SQL package 를 통해
만일 사용하고자 한다면 view 를 사용하여야 한다.
. 오로지 base table 만 허용된다.
partition extension 은 base table 에만 허용되고 synonyms, views, 그외 schema
에서는 허용되지 않는다.
9. Export/Import 시 Table-Level 과 Partition-Level 의 차이점?
테이블 단위의 export에서는 partitioned or non-partitioned table 전체가 index
와 그 table 에 dependent 한 다른 모든 object 가 함께 export 된다.
즉 partitioned table 의 모든 partition 이 export 된다. (이는 direct path
export and conventional path export에 모두 적용.)
또한 모든 export 모드 (full, user, table) 가 테이블 단위의 export 를 support
한다.
partition 단위의 export에서는 사용자가 테이블의 하나 또는 그 이상의 partition
을 export 할 수 있다.
Full database 단위나 user mode 는 partition-level의 export 를 support 하지
않는다. 오직 table levle 만 가능하다.
또한 incremental export (incremental,cumulative, and complete) 가 full
database mode 에서만 가능하기 때문에 partition-level export는 incremental
exports를 지원하지 못한다.
Partition-level import는 export 되어진 non-partitioned table을 import 하지
못한다. 그러나, table-level 의 import로 non-partitioned table 로부터
partitioned table 이 import되어진다.
즉 partition-level import 는 export 되어진 table 이 partitioned 되어 있고
export file 에 있을 때에만 가능하다.
export file 의 partition name 이 valid 하지 않는 경우 import 시 경고
message 를 발생한다.
모든 경우 partitioned data 는 import 시 선택적으로 가능하게 export 되어 진다.
export 나 import 시 table name 을 지정 시는
TABLES=schema_name : tables_name : partition_name 으로 사용한다.
Partition 단위의 export 는 table 내의 특정 partition 을 한개 또는 그 이상을
export 가능하게 한다.
이 때 partition name 이 주어지지 않으면 table 전체가 사용된다.
다음은 partiotion level 의 export 예제이다.
exp system/manager FILE = export.dmp TABLES = (scott.b:px, scott.b:py,
mary.c, d:qb)
이 예제에서 scott.b 는 반드시 partitioned table이고 px ,py 는 2개의
partition 이다.
mary.c 는 partitioned 또는 non-partitioned table 이다. 그러나 d table 은
반드시 partitioned table 이며 qb 는 그 partioion 중의 하나이다.
만일 table-name이나 같은 table 의 partition-name이 중복 사용되어지면
export 는 error 를 발생한다. 예를 들어 다음 partition-level의 export 명령어는
table sc 와 partition px 가 중복 사용되어 error 를 발생한다.
exp system/manager FILE = export.dmp TABLES = (sc, sc:px, sc)
10. partiton table 또는 view를 어떻게 non-partitioned table로 변환시키는가?
table 을 변환하기 위해 dummy table 을 생성하고,
alter table EXCHANGE PARTITION 명령어를 통해 수행한다.
이 명령어는 매우 빨리 data dictionary 를 update 시킨다.
SPLIT PARTITION 은 매우 큰 partition table 이나 view 를 handling 하는 데
유용하다.
SQL:
1. partition을 갖는 dummy_t table 을 생성
2. alter table EXCHANGE partition T with dummy_T
3. drop table T
exp/imp:
1. export the table
2. drop the table .
3. partiton 을 갖는 table 을 다시 생성
4. table data 를 import 한다.
11. table partition을 결합하는 법?
export/import:
partition-level 의 export, import 를 통해 가능하다.
1. partition data 를 갖는 temporary table을 생성한다.
2. drop the partition to be merged
3. insert into table (select * from temporary table)
4. drop temp.
그러나, table partition 을 분할하는 방법은 export, import 를 통해 불가능하다.
Example
Reference Document
------------------

Before we go too far with this, if you manually query with TO_DATE on the variable instead of TO_CHAR on the column, does the query actually use the index?
The TO_CHAR on the column will definitely stop Oracle from using any index on the column. If the query will use the index if you TO_DATE the variable, as I see it, you have three options. First, fix the application problem that won't let you use TO_DATE from the application. Second, change the application to call a function returning a ref cursor, get the date string as a parameter to the function, and do the TO_DATE in the function.
Third, you could consider creating a function-based index on TO_CHAR(transaction_date, 'dd-Mon-yy'). This would be the least desirable option, particularly if you would also be selecting records based on a range of transaction_dates, since it loses a lot of information that the optimizer could use in devising an efficient query plan. It could also change your results for a range scan.
John

Delete global stats, leave partition level only in 10.2.0.3 .

Hi,
there is 10.2.0.3 4 node rac datawarehouse , most queries are with predicate related to partition key .
So there is a lot of partition prunning involved .
Currently data load is done via exchange partition and then only that partition stats is calculated.
We dont got global stats (global_stats = NO in dba_tables) .
Is that right way to deal with statistics in 10.2.0.3 ?
I know that 10.2.0.4 brings us copy stats solution, but what with 10.2.0.3 ?
How to deal with statistics update , related to exchanged partition .
As far as I know there is no way to incrementaly update global statistics, so granuality => partition seems
the only way .
If I got that correctly, Oracle calculates global statistics from partition level statistics if there is no 'true' global stats calculated .
The only issue I know is related to NDV estimation, but I think we can life with that.
Please advice .
Regards.
GregG

You really should collect both partition and global stats. If a query spans more than 1 partition then global stats are generally used. Partition stats are used when there is only a single partition access.
There is no way in 10g to get incremental global stats. That was introduced in 11g. Global stats are collected by a table scan, they are not aggregated on 10g, only 11g with incremental enabled.
However, there was a new granularity introduced in 10g called APPROX_GLOBAL AND PARTITION. This is part of patch 6526370.
I'd recommend that you either gather global or use the APPROX_GLOBAL AND PARTITION, but it is best to have some global stats.
More details on this here:
http://structureddata.org/2008/07/16/oracle-11g-incremental-global-statistics-on-partitioned-tables/
Regards,
Greg Rahn
http://structureddata.org

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.

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

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.

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

Creating Local partitioned index on Range-Partitioned table.

Hi All,
Database Version: Oracle 8i
OS Platform: Solaris
I need to create Local-Partitioned index on a column in Range-Partitioned table having 8 million records, is there any way to perform it in fastest way.
I think we can use Nologging, Parallel, Unrecoverable options.
But while considering Undo and Redo also mainly time required to perform this activity....Which is the best method ?
Please guide me to perform it in fastest way and also online !!!
-Yasser

YasserRACDBA wrote:
3. CREATE INDEX CSB_CLIENT_CODE ON CS_BILLING (CLIENT_CODE) LOCAL
NOLOGGING PARALLEL (DEGREE 14) online;
4. Analyze the table with cascade option.
Do you think this is the only method to perform operation in fastest way? As table contain 8 million records and its production database.Yasser,
if all partitions should go to the same tablespace then you don't need to specify it for each partition.
In addition you could use the "COMPUTE STATISTICS" clause then you don't need to analyze, if you want to do it only because of the added index.
If you want to do it separately, then analyze only the index. Of course, if you want to analyze the table, too, your approach is fine.
So this is how the statement could look like:
CREATE INDEX CSB_CLIENT_CODE ON CS_BILLING (CLIENT_CODE) TABLESPACE CS_BILLING LOCAL NOLOGGING PARALLEL (DEGREE 14) ONLINE COMPUTE STATISTICS;
If this operation exceeds particular time window....can i kill the process?...What worst will happen if i kill this process?Killing an ONLINE operation is a bit of a mess... You're already quite on the edge (parallel, online, possibly compute statistics) with this statement. The ONLINE operation creates an IOT table to record the changes to the underlying table during the build operation. All these things need to be cleaned up if the operation fails or the process dies/gets killed. This cleanup is supposed to be performed by the SMON process if I remember correctly. I remember that I once ran into trouble in 8i after such an operation failed, may be I got even an ORA-00600 when I tried to access the table afterwards.
It's not unlikely that your 8.1.7.2 makes your worries with this kind of statement, so be prepared.
How much time it may take? (Just to be on safer side)The time it takes to scan the whole table (if the information can't read from another index), the sorting operation, plus writing the segment, plus any wait time due to concurrent DML / locks, plus the time to process the table that holds the changes that were done to the table while building the index.
You can try to run an EXPLAIN PLAN on your create index statement which will give you a cost indication if you're using the cost based optimizer.
Please suggest me if any other way exists to perform in fastest way.Since you will need to sort 8 million rows, if you have sufficient memory you could bump up the SORT_AREA_SIZE for your session temporarily to sort as much as possible in RAM.
-- Use e.g. 100000000 to allow a 100M SORT_AREA_SIZE
ALTER SESSION SET SORT_AREA_SIZE = <something_large>;
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/

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.

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

Creating a bit map index on a partitioned table

Dear friends,
I am trying to create a bitmap index on a partitioned table but am receiving the following ORA error. Can you please let me know on how to create a local bit map index as the message suggests?
ERROR at line 1:
ORA-25122: Only LOCAL bitmap indexes are permitted on partitioned tables
Trying to use the keyword local in front leads to wrong syntax.
Thanks in advance !!
Somnath

ORA-25122 Only LOCAL bitmap indexes are permitted on partitioned tables
Cause: An attempt was made to create a global bitmap index on a partitioned table.
Action: Create a local bitmap index instead
Example of a Local Index Creation
CREATE INDEX employees_local_idx ON employees (employee_id) LOCAL;
Example is about btree and I think it will work for bitmap also.

Local index vs global index in partitioned tables

Similar Messages

Maybe you are looking for