지난주에는 1주일동안 엔코아 컨설팅에서 새로쓴 대용량 데이터베이스 솔루션1 과정을 듣고 왔다.
개인적으로 오라클에서는 대용량 데이터를 핸들링할 일이 별로 없어서 아쉬웠는데, 교육을 통해 대용량 데이터 운용에 대해 많이 배운 느낌이다. 특히 온라인과 배치작업의 차이, 부분범위처리 개념, 다양한 힌트적용방법 등은 깊이 이해하지 못하였던 부분이라 꽤 유용할 거 같다.
강의에서 나왔던 주요 내용들을 정리해 보자.
- 자주 사용되는 코드성 테이블에서 좀더 성능개선이 필요하면 일체형테이블(IOT)을 고려하자.
변경사항은 거의 없고, 조회가 많은 데이터 크기가 작은 테이블
- RowID : 인덱스는 인덱스 칼럼 다음에 RowID로 소팅된다. RowID에는 Block No, Slot No 등이 포함되어 있다.
- 오라클8i에 나온 LMT(Locally Managed Tablespace)는 기존 Dictionary 관리방식에서 로컬 tablespace의 bitmap정보로 공간관리를 한다. 대용량 테이블일 경우 UNIFORM방식으로 하는게 좋다. SYSTEM으로 할 경우 병렬처리시(parallel힌트)에 64M Extent를 여러개 생성해서 넣는 등 공간 낭비가 있을 수 있다.
- temp성 테이블이나 update가 없는 로그성 테이블은 테이블 생성시 pctfree를 0으로 생성하자.
- table full scan은 multi block I/O로 수행되고, index range scan은 Single block I/O로 수행된다. 따라서 조회건이 10%이상이거나 건수가 많으면 full scan이 낫다.
cf) index full scan 은 single block I/O, index fast full scan 은 multi block I/O
- 대용량테이블에서 특정 구간을 temp 테이블로 가져올 때
create table /*+ parallel */ temp_01 as select /*+ parallel(a, 8) */ from table1 a where 일자 = ' ';
- workarea_size_policy 가 AUTO일 경우 소팅, 해쉬처리시에 사용되는 메모리를 pga_aggregate_taget 값으로 자동으로 할당한다. 2G이상 주자.
- 배치작업시에는 다음과 같이 메모리 수동할당으로 작업할 수 도 있다.
alter session set workarea_size_policy = manual;
alter session set sort_area_size = 200M
alter session set hash_area_size = 200M
배치작업때는 여러 배치를 같이 돌려서 자원경합을 일으키는 것보다는 스케줄링을 통해 분산시켜 작업하는게 낫다.
- 배치작업시 select 를 통한 insert 수행예
alter session enable parallel dml;
alter session set db_file_multiblock_read_count = 100;
insert /*+ parallel(a 4) */ into tab1 a
select /*+ parallel(b 4) */ * from tab2 b;
- Hard Parsing(dynamic)과 Soft Parsing(static) 개념을 이해하자. Library Cache에 있는 정보를 이용하는 Soft Parsing만 사용해도 10%정도 성능향상이 이뤄진다고 한다. 자바에서의 PreparedStatement나 php의 bind함수사용 등을 통해 기존 파싱 및 옵티마이징된 plan을 활용할 것.
Cursor_sharing 파라미터를 FORCE로 놓아 강제로 static으로 만들 수 있으나(상수값을 변수로 전환시켜 파싱) 경우에 따라 에러가 발생하는 경우가 있다고 한다. 그냥 EXACT를 쓰는게 나을듯.
- 대부분의 DBMS에서의 옵티마이져는 현재 CBO(Cost based Optimizer)방식으로 동작한다고 하고, 오라클에서도 RBO(Rule Based Optimizer)에 대한 지원을 중단한다고 발표했다고 한다. 9i이후에는 CBO를 쓰자.
- 실행계획을 봤을 때 인덱스를 타야될 상황인데 자꾸 hash join이나 sort merge로 빠질 때 조정
optimizer_index_cost_adj = 20 정도로 조정.(인덱스 사용시 cost)
optimizer_index_caching = 100 (index가 buffer cache에 있을 확률)
- 옵티마이져 모드 : First_Rows_n (OLTP성 온라인에 적합), ALL_ROWS(OLAP나 배치작업시 적합)
-- page 57까지 작성
개인적으로 오라클에서는 대용량 데이터를 핸들링할 일이 별로 없어서 아쉬웠는데, 교육을 통해 대용량 데이터 운용에 대해 많이 배운 느낌이다. 특히 온라인과 배치작업의 차이, 부분범위처리 개념, 다양한 힌트적용방법 등은 깊이 이해하지 못하였던 부분이라 꽤 유용할 거 같다.
강의에서 나왔던 주요 내용들을 정리해 보자.
- 자주 사용되는 코드성 테이블에서 좀더 성능개선이 필요하면 일체형테이블(IOT)을 고려하자.
변경사항은 거의 없고, 조회가 많은 데이터 크기가 작은 테이블
- RowID : 인덱스는 인덱스 칼럼 다음에 RowID로 소팅된다. RowID에는 Block No, Slot No 등이 포함되어 있다.
- 오라클8i에 나온 LMT(Locally Managed Tablespace)는 기존 Dictionary 관리방식에서 로컬 tablespace의 bitmap정보로 공간관리를 한다. 대용량 테이블일 경우 UNIFORM방식으로 하는게 좋다. SYSTEM으로 할 경우 병렬처리시(parallel힌트)에 64M Extent를 여러개 생성해서 넣는 등 공간 낭비가 있을 수 있다.
- temp성 테이블이나 update가 없는 로그성 테이블은 테이블 생성시 pctfree를 0으로 생성하자.
- table full scan은 multi block I/O로 수행되고, index range scan은 Single block I/O로 수행된다. 따라서 조회건이 10%이상이거나 건수가 많으면 full scan이 낫다.
cf) index full scan 은 single block I/O, index fast full scan 은 multi block I/O
- 대용량테이블에서 특정 구간을 temp 테이블로 가져올 때
create table /*+ parallel */ temp_01 as select /*+ parallel(a, 8) */ from table1 a where 일자 = ' ';
- workarea_size_policy 가 AUTO일 경우 소팅, 해쉬처리시에 사용되는 메모리를 pga_aggregate_taget 값으로 자동으로 할당한다. 2G이상 주자.
- 배치작업시에는 다음과 같이 메모리 수동할당으로 작업할 수 도 있다.
alter session set workarea_size_policy = manual;
alter session set sort_area_size = 200M
alter session set hash_area_size = 200M
배치작업때는 여러 배치를 같이 돌려서 자원경합을 일으키는 것보다는 스케줄링을 통해 분산시켜 작업하는게 낫다.
- 배치작업시 select 를 통한 insert 수행예
alter session enable parallel dml;
alter session set db_file_multiblock_read_count = 100;
insert /*+ parallel(a 4) */ into tab1 a
select /*+ parallel(b 4) */ * from tab2 b;
- Hard Parsing(dynamic)과 Soft Parsing(static) 개념을 이해하자. Library Cache에 있는 정보를 이용하는 Soft Parsing만 사용해도 10%정도 성능향상이 이뤄진다고 한다. 자바에서의 PreparedStatement나 php의 bind함수사용 등을 통해 기존 파싱 및 옵티마이징된 plan을 활용할 것.
Cursor_sharing 파라미터를 FORCE로 놓아 강제로 static으로 만들 수 있으나(상수값을 변수로 전환시켜 파싱) 경우에 따라 에러가 발생하는 경우가 있다고 한다. 그냥 EXACT를 쓰는게 나을듯.
- 대부분의 DBMS에서의 옵티마이져는 현재 CBO(Cost based Optimizer)방식으로 동작한다고 하고, 오라클에서도 RBO(Rule Based Optimizer)에 대한 지원을 중단한다고 발표했다고 한다. 9i이후에는 CBO를 쓰자.
- 실행계획을 봤을 때 인덱스를 타야될 상황인데 자꾸 hash join이나 sort merge로 빠질 때 조정
optimizer_index_cost_adj = 20 정도로 조정.(인덱스 사용시 cost)
optimizer_index_caching = 100 (index가 buffer cache에 있을 확률)
- 옵티마이져 모드 : First_Rows_n (OLTP성 온라인에 적합), ALL_ROWS(OLAP나 배치작업시 적합)
-- page 57까지 작성
반응형