티스토리 뷰

서 론

UPDATE GLOBAL INDEXES 를 사용하여 24*7 사용되는 Data Warehouse에서 1개월 주기로 파티셔닝을 자동화 했더랬다. 헌데; update global indexes가 퍼포먼스가 좋은 것도 아니고 단지 신텍스가 단순할 뿐이라는 사실에 허탈했다.
아울러, online 옵션이 없어 테이블 전체 락을 꽉잡고 하루종일 걸리는게 아닌가.
-_-; 오히려 오래걸릴 수도 있다는 말에 모든 파티셔닝을 수동으로 진행했다.
이게 무슨 삽인고.

본 론

1. UPDATE GLOBAL INDEXES절을 사용할 경우

1 이전 버전에서는 단순히 invalid 상태로 표시하고 종료되었던 작업이
인덱스 관리 작업까지 병행해 수행 되므로 partition DDL operation
작업 수행 시간이 더 오래 걸린다.
2 DROP, TRUNCATE, EXCHANGE 작업이 더 오래 걸린다. 이전에는 데이터
딕셔너리상의 정보만을 갱신하는데 반해, UPDATE GLOBAL INDEXES절을
사용할 경우, partition 내의 모든 row에 대한 scan 작업이 수행
되기 때문이다.  - 모든 row에 대한 scan 작업은 어차피 rebuild할때 다 하는것 아닌가.
3 GLOBAL INDEX에 대한 갱신 작업을 통한 변경 사항이 redo log 및 rollback에
남게 된다. - 어 그래서 느리다는거지. nologging 옵션좀 주면 안되나;
4 row의 갯수가 작을 경우, update global index절을 사용하여 작업하는 것이
편리하다. - 느리니 작은 사이즈에만 써라 -_- 진즉 얘기해주지
5 인덱스를 수동으로 rebuild 할 때 까지 애플리케이션 응답 속도가 현격
하게 저하되는 것을 피할 수 있다.(즉, select는 속도를 어느정도 유지할수 있다)
- select 가 문제가 아니라 테이블 락이 문제요...

2. INDEX REBUILD를 사용할 경우

1 전체 인덱스를 rebuild 하면, index가 좀더 효과적으로 구성된다.
2 인덱스를 rebuild 하면, 사용자가 인덱스에 대한 구성을 수동으로
변경할 수 있다.
3. online/nologging 을 사용할 수 있다(!!!!!!).

결 론


긴말이 필요없다. 24*7 사용되는 Database의 파티셔닝 관리는 update global index를 사용하지 말자. 그냥 얌전히 아래 커서를 이용하자.

cursor c_part_indexes
is
select 'alter index '||index_name||' rebuild partition '||partition_name||' online' indscript
  from user_ind_partitions
where status = 'UNUSABLE';

cursor c_nonpart_indexes
is
select 'alter index '||b.index_name||' rebuild online' nindscript
  from user_part_tables a, user_indexes b
 where a.table_name = b.table_name
   and b.PARTITIONED = 'NO'
   and b.status = 'UNUSABLE';

v_sql varchar2(4000);

begin
 for c_indx in c_part_indexes()
 loop

  v_sql := c_indx.indscript;
  execute immediate v_sql;
          
 end loop;

 for c_nindx in c_nonpart_indexes()
 loop

  v_sql := c_nindx.nindscript;
  execute immediate v_sql;
          
 end loop;

댓글
  • 프로필사진 니플하임 허나 rebuild보다는 drop후 recreate가 항상 더 빠르고 확실하더군요. online 역시 툴에서 사용할 땐 아주 가끔 응답이 없는등의 꼬이는 현상이 있습니다. 2007.07.12 14:06
댓글쓰기 폼