|
|
|
![]()
| [일반] 파티션테이블 인덱스의 관리적인 부분에 대해서 |
|
| 호석 님께서 쓴 글입니다 - 121.♡.39.7 |
읽음:4042 |
|
|
지금까지 파티션 및 파티션 인덱스의 개념과 특성에 대해서 알아 보았으므로 이제 파티션과 파티션 인덱스의 관리적인 부분에 대해서 알아보자.
파티션은 파티션 테이블 전체가 하나의 오브젝트로 등록되어 관리되며 개별 파티션도 역시 하나의 오브젝트로 관리됨으로 일반 테이블과 인덱스와는 약간 다른 처리가 발생 하게 된다.
파티션 테이블의 일반적인 백업과 복구에서는 파티션 특성을 제외하면 일반 테이블의 백업과 복구와 특별한 차이가 없다.
하지만 파티션 인덱스에서는 로컬인덱스와 글로벌 인덱스에 따라서 다른 처리가 발생하게 되며 관리상의 부하도 클 수 있으므로 주의해야 한다.
파티션의 관리는 크게 다음과 같이 나눌 수 있다.
파티션 추가/삭제/병합
파티션 변환(파티션 테이블과 일반테이블의 변환)
기타 관리
파티션의 종류에 따라 가능한 작업이 정해져 있으며 이는 종류에 따른 파티션의 특성에 기인한다. 파티션의 종류별로 가능한 ALTER 명령은 오라클 매뉴얼을 참고하기 바란다.
(http://otn.oracle.com/docs/products/oracle9i/
doc_library/901_doc/server.901/a90117/partiti.htm#1311)
파티션의 관리는 실제적인 방법과 명령의 사례가 필요하므로 테스트를 위해서 오라클 9i에서 추가된 데모 데이터베이스 Sales History를 예로 든다.
테스트 환경 설정
오라클 9i에 접속 가능한 경우에는 sh 유저의 데이터 베이스에서 확인이 가능한다. 없는 경우를 위해서 간단히 다음과 같이 작업한다.
테스트를 위해서 먼저 partition table을 다음과 같이 생성한다. 테스트를 위해서 파티션의 데이터 타입을 DD-MON-YYYY 에서 YYYYMMDD로 하였다.
CREATE TABLE sales
(prod_id NUMBER(6) CONSTRAINT sales_product_nn NOT NULL,
cust_id NUMBER CONSTRAINT sales_customer_nn NOT NULL,
time_id DATE CONSTRAINT sales_time_nn NOT NULL,
channel_id CHAR(1) CONSTRAINT sales_channel_nn NOT NULL,
promo_id NUMBER(6) ,
quantity_sold NUMBER(3) CONSTRAINT sales_quantity_nn NOT NULL,
amount NUMBER(10,2) CONSTRAINT sales_amount_nn NOT NULL,
cost NUMBER(10,2) CONSTRAINT sales_cost_nn NOT NULL)
PARTITION BY RANGE (time_id)
(PARTITION Q1_1998 VALUES LESS THAN (TO_DATE('19980401','YYYYMMDD')),
PARTITION Q2_1998 VALUES LESS THAN (TO_DATE('19980701','YYYYMMDD')),
PARTITION Q3_1998 VALUES LESS THAN (TO_DATE('19981001','YYYYMMDD')),
PARTITION Q4_1998 VALUES LESS THAN (TO_DATE('19990101','YYYYMMDD')),
PARTITION Q1_1999 VALUES LESS THAN (TO_DATE('19990401','YYYYMMDD')),
PARTITION Q2_1999 VALUES LESS THAN (TO_DATE('19990701','YYYYMMDD')),
PARTITION Q3_1999 VALUES LESS THAN (TO_DATE('19991001','YYYYMMDD')),
PARTITION Q4_1999 VALUES LESS THAN (TO_DATE('20000101','YYYYMMDD')),
PARTITION Q1_2000 VALUES LESS THAN (TO_DATE('20000401','YYYYMMDD')),
PARTITION Q2_2000 VALUES LESS THAN (TO_DATE('20000701','YYYYMMDD')),
PARTITION Q3_2000 VALUES LESS THAN (TO_DATE('20001001','YYYYMMDD')),
PARTITION Q4_9999 VALUES LESS THAN (MAXVALUE));
INSERT INTO SALES
SELECT PROD_ID, CUST_ID,
ADD_MONTHS(TIME_ID,(ROWNUM-1)*3)+1 TIME_ID,
CHANNEL_ID, PROMO_ID, QUANTITY_SOLD, AMOUNT_SOLD, ROWNUM
FROM SH.SALES
WHERE ROWNUM <= 20 ;
COMMIT ;
위 테이블은 time_id를 partition key로 한 range partition table이다. 다음엔 이 sales table에 SQL*Loader를 이용하여 데이터를 loading한다. 해당 control 화일 및 데이터 화일은 다음 디렉토리에 있다. 이 디렉토리로 이동해서 작업을 하면 된다.
$ORACLE_HOME/demo/schema/sales_history
Note :
Oracle 9i부터는 $ORACLE_HOME/demo/schema 서브 디렉토리에 HR(human resource), OE(order entry), PM(product media), SH(sales history), QS(Queued Shipping) 등의 샘플 스키마 및 데이터들이 있다.
가장 일반적인 RANGE PARTITION을 기준으로 설명하며 COMPOSITE PARTITION의 경우 서브파티션만 HASH로 추가된 경우이므로 RANGE PARTITITON 과 같다고 보면 되며 HASH와 LIST 파티션의 경우에는 따로 설명하였다.
1. 파티션의 추가/삭제/분할/병합
1.1. 추가
기존에 존재하는 파티션에 새로운 파티션을 추가하려는 경우 (예:리스트 파티션에서 2001년 1분기 데이터를 추가하려는 경우 등) 예제처럼 MAXVALUE로 지정한 파티션처럼 기존 파티션안에 대상이 포함되어 있다면 아래의 분할(SPLIT)을 이용하여 처리하고 MAXVALUE가 없는 경우처럼 기존 파티션의 범위 밖으로 새로이 추가되는 경우라면 다음과 같이 한다.
SQL>alter table sales add partition Q1_2001
values less than ('20010101') tablespace pts_2001Q1 ;
MAXVALUE로 지정한 파티션이 있는데 위와 같이 추가(add)하면 다음과 같은 에러가 발생한다.
"ORA-14120:DATE열에 파티션 바운드가 불완전하게 지정되었습니다."
1.2. 삭제
해당 단위 파티션을 삭제하는 경우 1998년 1분기 및 이전 데이터를 더 이상 관리하지 않아 해당 파티션 Q1_1998을 없애고 싶은 경우는 다음과 같이 실행한다.
SQL>alter table sales drop partition Q1_1998 ;
해당 파티션 및 파티션 안의 모든 데이터가 같이 삭제 된다. drop된 후에 새로 1998년 1분기 및 이전 데이타가 입력되면 Q2_1998 partition이 less then ('19980701') 으로 되어 있으므로 Q2_1998 partition에 저장된다.
1.3. 분할
하나의 파티션을 분할하여 여러 개의 파티션으로 재 생성시 MAXVALUE를 이용한 경우에 경계값으로 새로 추가되는 경우, MAXVALUE로 바운드를 지정하지 않은경우 새로운 최대값을 지정하는, 기존 하나의 파티션을 둘 이상의 파티션으로 나누는 경우 등이 해당된다.
새로 추가될 데이터 2001년 1분기 데이터를 저장할 파티션을 추가하려는 경우 기존 MAXVALUE 파티션에 이 조건이 포함되어 있으므로 이 파티션을 분할하면 된다.
SQL>alter table sales split partition Q4_9999 at (TO_DATE('20010101','YYYYMMDD'))
into (partition Q4_2000 tablespace pts_2000Q4, partition Q4_9999 tablespace pts_9999Q4)
분할되는 기존 파티션을 그대로 사용할 경우에는 기존 파티션 정보를 그대로 기술해 주면 된다.
SPLIT PARTITION은 매우 큰 partition table이나 view를 handling 하는데 유용하다.
1.4. 병합
파티션을 병합하는 방법은 MERGE명령을 이용하는 방법과 SQL로 임시테이블에 옮기는 방법과 Export/Import를 이용하는 방법이 있다.
MERGE를 이용하는 방법이 빠르고 단순하게 처리 가능한다.
MERGE를 이용하는 방법
SQL> ALTER TABLE SALES MERGE PARTITIONS Q2_1999, Q3_1999 INTO PARTITION Q3_1999 ;
1.5. 이름 변경
partition name 을 바꾸고 싶다면 다음과 같이 실행한다.
SQL>alter table sales rename partition Q4_9999 to Q4_Max ;
1.6. 테이블 스페이스 이동
partition Q4_9999을 저장하는 tablespace를 pts_9999Q4 에서 pts_maxQ4로 바꾸고 싶은 경우아래와 같은 command를 사용한다.
SQL>alter table sales move partition Q4_9999 tablespace pts_maxQ4 nologging ;
1.7. Truncate
partition의 data를 모두 삭제하려면 truncate하는 방법을 사용할 수 있는 데, truncate는 rollback 이 불가능하며 특정 partition 전체를 삭제하므로 주의하여 사용해야 한다.
SQL>alter table sales truncate partition Q4_9999 ;
1.8. 속성 변경
partition table은 특정 partition의 속성만 변경할 수도 있고, table의 속성을 변경 하여 전체 partition에 대해 동일한 변경을 할 수 있다.
SQL>alter table sales storage(next 10M);
sales 의 모든 partition의 next 값이 변경된다.
SQL>alter table part_tbl modify partition Q4_9999 storage(maxextents 100);
Q4_9999 partition의 maxextents 값만 변경한다.
1.9. 인덱스 관리
파티션은 파티션별로 RowID를 다르게 갖게 됨으로 파티션의 변경이 발생하게 되면 RowID의 변경이 발생하게 된다.
그래서 실제 파티션 테이블의 RowID와 변경된 파티션 로컬 인덱스와 글로벌 인덱스의 RowID와 가 일치하지 않게 되어 인덱스 사용 중지 즉, IU상태(INDEX UNUSABLE)가 발생하게 되어 인덱스의 사용 불가 및 재 성성에 따른 운영 및 관리상의 부하 및 재 생성에 따른 시스템의 부하가 발생하게 된다.
partition index가 IU 상태가 되었을때 그 partition index을 사용 하게 되면 다음과 같은 에러가 발생하게 된다.
SQL>SELECT /*+ INDEX(SALES SALES_GPNK1) */ *
FROM SALES WHERE PROD_ID >= 10000
ORA-01502: 인덱스 'SALES_GPNK1'또는 인덱스 분할영역은 사용할 수없는 상태이다
이와 같은 에러가 발생시 해당 파티션을 해당 인덱스를 통해서 엑세스 할 수 없게 됨으로 해당 어플리케이션의 수행을 유지 할 수 없는 상황이 발생하게 된다.
물론 인덱스를 사용하지 않고 해당 파티션을 TABLE FULL SCAN 하면 에러가 발생 하지 않는다.
하지만 옵티마이져가 실행계획 수립시에 INDEX UNUSABLE 상태 여부를 체크하지 않으므로 해당 인덱스를 사용하는 실행계획이 수립되고 실제 수행시 오류가 발생하게 됨으로 이미 운용중인 어플리케이션이나 SQL이 정상 수행되지 않는다.
이런 경우에는 skip_unusable_indexes = TRUE 파라메터를 지정하면 수행시에 해당 인덱스가 UNUSABLE이면 이를 사용하지 않고 TABLE FULL SCAN 등을 한다. 경우에 따라서 유용하게 사용 가능하므로 고려 해 볼 수 있다.
어떤 partition이 IU 상태가 되면 그 partition을 사용하기 전에 재생성(rebuild)해야 한다. 그러나 IU partition을 제외한 다른 partition만을 읽거나 DML을 수행하는 작업은 IU partition을 access하지 않는 한 오류가 발생하지 않는다. 단, IU partition을 rebuild하기 전에 split이나 rename이 가능하며, IU상태인 global index를 drop하는 것도 가능하다. 관리상으로 IU상태인 인덱스를 다시 수행 가능하게 하는 작업은 경우에 따라 업무적인 부하가 큰 경우가 발생 할 수 있다.
파티션은 원래 대용량 데이터에 대한 처리이므로 인덱스 재생성 작업은 부하가 큰 작업인 경우가 많다. 또한 로컬파티션 인덱스의 경우에는 해당 로컬인덱스만 재 생성해주면 되지만 글로벌 파티션 인덱스의 경우 글로벌 인덱스를 한번에 재 생성할 수 없고 개별 파티션 단위로만 재생성이 가능하므로 글로벌 인덱스의 파티션 수 만큼 나누어서 지정하여 재생성 해야 한다.
이와 같은 관리상의 문제점을 해결하기 위한 여러가지 방법이 있으며 가장 큰 원인은 파티션의 변경과 파티션 데이터의 RowID가 변경되는 경우이다.
RowID가 변경되는 경우는 자주 발생하지 않고 어쩔수 없는 경우가 대부분일 것이므로 그렇다고 하여도 파티션의 변경은 가능한 발생하지 않게 유도할 수 있다.
특정 파티션의 데이터를 파티션에서 제외시키는(백업으로 이동 등) 경우에는 실제 데이터를 로우 단위로 Delete 하는것이 아니라면 파티션에 대한 명령에서는 실제 데이터의 RowID 변경이 일어난다면 어떤 방법을 써도 Global Index의 Unusable을 피할 수는 없다.
Partition Index를 Unusable상태로 만들 수 있는 명령.(Oracle9i 기준).
작업 대상
작업유형
인덱스
Unusable 상태 변경
파티션 테이블
ADD
LOCAL
새로 생성되므로 상관없다.
GLOBAL
파티션만 추가되므로 상관없다.
DROP
LOCAL
같이 삭제되므로 상관없다.
GLOBAL
모든 GLOBAL INDEX가 Unusable
SPLIT
LOCAL
SPLIT된 파티션 인덱스 Unusable
GLOBAL
모든 GLOBAL INDEX가 Unusable
MERGE
LOCAL
머지되어 남는 파티션 인덱스 Unusable
GLOBAL
모든 GLOBAL INDEX가 Unusable
RENAME
LOCAL
실제 변경이 없으므로 상관없다.
GLOBAL
실제 변경이 없으므로 상관없다.
MOVE
LOCAL
MOVE된 파티션 인덱스 Unusable
GLOBAL
모든 GLOBAL INDEX가 Unusable
TRUNCATE
LOCAL
남은 로우가 없으므로 상관없다.
GLOBAL
모든 GLOBAL INDEX가 Unusable
EXCHANGE
LOCAL
EXCHANGE한 파티션 인덱스 Unusable
GLOBAL
모든 GLOBAL INDEX가 Unusable
(표를 보면 알겠지만 Unusable상태가 되는 것은 실제 파티션 테이블 데이터의 RowID를 변경시킨 경우(파티션 단위의 변경이 발생시에도 해당 파티션에 실제 로우 데이터가 있어서 RowID 변경이 발생된 경우)에 해당된다.)
인덱스 재생성(Rebuild)
partition table관련 작업을 한 후에는 table에 걸려 있는 local(partitioned) index 나 global index를 반드시 rebuild해 주어야 한다.
특정 partition의 index를 rebuild 하려면
SQL>alter index idx01_sales rebuild partition idx_Q4_9999 ;
global index를 rebuild하려면 non-partition index 인덱스인 경우는
SQL>alter index sales_idx01 rebuild;
와 같이 처리하면 되지만 global partition index 인덱스는 인덱스 전체를 한번에 재생성 할 수 없다.
SQL>alter index SALES_GPNK1 rebuild
"ORA-14086:분할영역된 인덱스는 전체를 다시 만들 수 없습니다." 와 같은 에러를 발생하게 된다.
SQL>alter index SALES_GPNK1 rebuild partition SALES_GPI01 ;
위와 같이 인덱스 파티션 단위로 재 생성 해주어야만 한다.
global partition index의 경우 non-partition index 이든 partition index 이든 파티션 테이블 관련 작업인 경우 재 생성이 필수 이므로 파티션 테이블별로 global index의 rebuild 작업용의 스크립트를 작성해 놓아야 빠른 시간안에 관련 인덱스를 재 생성 할 수 있다.
1.10. Index Unusable 상태 예방
특히 Range Partition의 경우 대개 날짜를 키로 하여 파티션되며 시간의 경과에 따라 관리하는 데이터의 날짜값도 증가하여 새로운 파티션으로 관리해야 하는 경우가 많다.
오라클에서 NULL 데이터는 정렬에서 마지막에 위치하게 되어 파티션 키의 값이 NULL인 경우 MAXVALUE 파티션에 존재하게 된다.
즉 키에 NULL인 데이터가 존재시에는 MAXVALUE에 실제로 데이터가 위치하게 되며 이 경우 최신의 데이터를 위해서 파티션을 추가시 MAXVALUE를 SPLIT하게 되면 실제 데이터 로우가 있는 파티션에서 변경 작업이 일어났으므로 Global Index 의 Unusable를 피할 수 없게 된다.
이를 방지 하기 위해서는 실제 운영데이터의 최종 파티션과 MAXVALUE 파티션 사이에 dummy 파티션을 하나 두어 NULL값이 위치한 MAXVALUE 파티션을 분리하는 것이 좋다.
예를 들어 날짜가 키인 경우 '20021001'인 현재 파티션과 MAXVALUE 사이에 '21000101' 이나 '99990101' 과 같은 dummy 파티션을 유지 하여 실무에서 유용하게 사용하는 방법이다.
1.11. 파티션 키 데이터의 변경
파티션을 운영 중에 키 컬럼의 데이터가 변경되어 파티션을 이동 시에 다음과 같은 에러를 발생시킨다.
"ORA-14402: 분할영역 키 열을 수정하는 것은 분할영역 변경이 생깁니다."
이 문제를 해결하기 위해 잘못하면 프로그램 상에서 Delete & Insert 방식으로 코딩을 하기도 하지만 Oracle8i부터 SQL의 Syntax에 이 문제에 대한 옵션이 존재한다.
ENABLE ROW MOVEMENT 또는 DISABLE ROW MOVEMENT
디폴트로 DISABLE ROW MOVEMENT 가 셋팅 되어 있다. 즉 파티션간 로우의 이동이 금지되어 있었기 때문에 위와 같은 에러를 만나게 된 것이다.
CREATE TABLE시 이 옵션을 주거나, ALTER TABLE 명령어로 설정 값을 바꿀 수 있다.
ALTER TABLE SALES ENABLE ROW MOVEMENT;
2. 파티션 테이블의 변환 (파티션과 일반테이블의 변환)
파티션 테이블과 일반 테이블을 직접 변환시키는 명령은 EXCHANGE 명령이 있으며 다른 데이터베이스에의 이전이라면 Export/Import를 이용하는 방법이 있다.
EXCHANGE 명령은 특정 partition을 non partitioned table로, non partitioned table을 특정 partition으로 변환시켜 주는 역할을 한다.
내부적으로는 data(index) segment를 교환(data dictionary의 변경)하는 것이지 실제로 각각의 row들을 옮기는 것은 아니다.
Export/Import를 이하는 방법은 다른 데이터 베이스에서의 이전 등이나 재생성 등에 유용하며 일반 테이블의 Import와 동일한 절차로 수행된다.
table-level import시 우선 table creation 문장을 수행하고 row insert문을 수행 하는 것과 마찬가지로, partition-level import도 우선 partitioned table의 생성문장을 수행하고 row insert문을 수행하게 된다.
따라서 ignore=y option등을 적절히 사용하면, non-partitioned table과 partitioned table간의 변경, partitioned table의 구조 변경 등을 수행할 수 있게 된다.
2.1. EXCHANGE 이용 시
파티션 => 일반 테이블의 변환
table을 변환하기 위해 dummy table을 생성하고, alter table EXCHANGE PARTITION 명령어를 통해 수행한다. 이 명령어는 매우 빨리 data dictionary 를 update 시킨다
i) 변경하려는 파티션과 동일한 구조를 같는 테이블을 생성한다.
SQL>create table sales_EXCH as select * from sales where 1 = 2 ;
ii) alter table EXCHANGE을 이용하여 변경한다.
SQL>ALTER TABLE sales EXCHANGE PARTITION Q4_9999 WITH TABLE
sales_EXCH WITHOUT VALIDATION ;
EXCHANGE 으로 변경시에 파티션 테이블의 해당 파티션의 구조는 그대로 유지된다.(기존 파티션은 데이터 로우는 없는 빈 파티션이 된다) 즉 EXCHANGE를 사용하면 실제 데이터가 파티션에서는 더 이상 유지되지 못하므로 해당 경우에만 사용할 수 있는 단점이 있다.
WITHOUT VALIDATION 을 사용하면 유일성 조건 등의 기존 테이블에 걸린 제약 조건을 체크하지 않으므로 변환 전에 미리 체크 하는 것이 좋다.
일반 테이블 => 파티션 의 변환
alter table EXCHANGE을 이용하여 변경한다.
SQL>ALTER TABLE sales EXCHANGE PARTITION Q3_1999 WITH TABLE
sales_EXCH WITHOUT VALIDATION ;
변환될 파티션테이블의 인덱스와 완전히 매치되는 인덱스 구조를 가지고 있다면 INCLUDING INDEX 옵션을 추가하여 로컬인덱스 생성에 대한 시간을 줄일 수 있다.
EXCHANGE는 전체적으로 가장 빠르게 파티션 관련 데이터를 변경할 수 있는 방법이다.
2.2. CTAS 이용 시
파티션 테이블의 특정 테이블을 일반 테이블로 변경시에 EXCHANGE를 사용시에는 실 데이터의 변경이 발생하므로 또 다른 방법으로 CTAS(CREATE TABLE .. NOLOGGING AS SELECT ..)가 있다.
적당한 SORT_AREA_SIZE의 지정과 NOLOGGING옵션으로 원하는 성능을 얻을 수 있다.
3. 기타 관리
파티션의 관리에서 발생하게 되는 몇 가지 중요한 실례를 살펴보기로 한다.
3.1. 파티션 데이터 파일 삭제시의 처리
Partitioned table의 partition이 포함되어 있는 datafile이 OS level에서 삭제된 경우, 해당 datafile을 offline drop하고 open한 후 해당 table을 access하고자 하는 경우, 또는 해당 TableSpace를 Drop하고자 하면 에러가 발생한다. 다음과 같은 error가 유발된다.
ORA-00376: (File cannot be read at this time) ,
ORA-14404: (Partitioned table contains partitions in a different tablespace)
파일 삭제에 대한 처리는 일반 데이터 파일 삭제의 처리와 같다.
이때 파티션의 복구에 대해서는 다음과 같이 3가지로 조치 가능 한다.
1) 해당 partitioned table전체를 drop한 후 recreate한다.
drop table sales ;
drop tablespace pts_9999Q4 including contents ;
tablespace recreate.
table rebuild .
문제점은 전체 partitioned table을 복구해야 하므로 시간이 오래 소요된다.
2) 해당 partition만을 drop후 재 생성 한다.
alter table sales drop partition Q4_9999 ;
drop tablespace pts_9999Q4 including contents ;
tablespace recreate.
add partition or split partition.
해당 partition만의 data를 reload한다.
partitioned table전체 data를 reload하는 것 보다 짧은 시간이 소요된다.
3) temporary table을 생성하여 exchange한다.
sales table과 동일한 구조의 dummy table을 다른 tablespace에 생성한다.
create table dummy_sales as select * from sales where 1=2;
이 table을 문제의 partition과 exchange한다.
alter table sales exchange partition Q4_9999 with table dummy_sales without validation ;
drop tablespace pts_9999Q4 including contents ;
새로운 partition에 필요한 data를 load한다.
3.2. INDEX UNUSABLE 상태 예방 (9iR1 기준)
Oracle 9i에서는 base table에 대한 DDL 수행 시 UPDATE GLOBAL INDEXES라는 option을 사용해서 global index에 대해서도 ONLINE으로 update할 수 있는 기능을 제공한다.
이 기능으로 Global index가 base table과 동시에 변경이 되어 Global index에 대한 rebuild를 관리하지 않아도 된다.
가능한 DDL 명령
: SPLIT, MERGE, ADD, MOVE, COALESCE, DROP, TRUNCATE, EXCHANGE UPDATE GLOBAL INDEXES라는 option을 partition specification 바로 뒤, 그리고 PARALLEL clause 바로 앞에 기술해 두면 ONLINE으로 base table에 대한 DDL을 수행 하면서 global index를 그에 맞춰 변경시킬 수 있다.
SQL>ALTER TABLE sales DROP PARTITION sales1 UPDATE GLOBAL INDEXES
PARALLEL (DEGREE 4);
OnLine 변경은 전체적인 처리의 부하가 Rebuild보다 크며 트랜젝션에 대한 처리 시간이 증가 하므로 이 방법은 처리해야 할 row의 양이 적을 때 유용하다.
변경하려는 데이터에 대한 처리와 재생성의 부하를 비교하여 적정한 방법을 선택하는 것이 좋다. (즉 전체 글로벌 인덱스를 재 생성하는 시간보다 ONLINE update 하는 시간이 적을 때 유리하며 다량의 데이터의 경우에는 오히려 전체 시간이 더 걸릴 수 도 있으므로 테스트하여 운영 시스템마다 적정선의 처리 한계를 정하는 것이 좋다.)
3.3. 파티션 추가시 로컬인덱스의 속성 관리
ALTER TABLE ADD PARTITION을 할 경우 table partition의 경우 table partition, tablespace, physical storage attribute를 지정할 수 있으나, local index partition의 경우 관련 syntax를 지원하지 않는다.
오라클은 자동으로 index partition, tablespace, physical storage attribute를 지정한다. (ALTER TABLE SPLIT PARTITION도 마찬가지)
new index partition의 이름은 new table partition과 같은 이름이 할당되고, tablespace, physical storage attribute는 local index에 지정된 default값이 사용되고, local index에 지정된 default값이 없으면 user의 default tablespace가 사용된다. 그러므로 PARTITION을 추가하여 사용하는 경우 index partition 관리에 주의가 요구된다.
지금까지 파티션 테이블 및 인덱스의 관리에서 발생할 수 있는 문제점들을 살펴보았다.
실무에서 파티션의 INDEX UNUSABLE 상태를 일으킬 수 있는 상황들에 대해서 특히 주의 깊게 보고 운영 버전별로 테스트 해보아 각 시스템에 맞는 관리 지침을 수립 하여 숙지 하는 것이 중요하다.
이상으로 Partition table 및 인덱스의 관리에 대한 일반적인 사례 중심으로 알아보았으며 다음 연재에서는 Partition table 활용 및 제한 사항에 대하여 다루게 될 것이다.
|
|
|
|
|
|
