DATOR


튜닝-OLTP에서 전체적인 I/O을 줄일수 있는 방안-2

튜닝을 나가다 보면 가끔 아주 중요한 테이블이고 해당 부분에 데이터를 가져오는것이
1,000건 정도이지만 소스테이블의 데이터가 2억건이 넘고 컬럼의 수가 200개가 넘는다고 했을경우에
튜닝 요청이 들어오면 사실 튜닝할수 있는 포인트가 많이 있지는 않다.

 

예를 들면 고객의 주문내역을 가져오는 SQL이 있다고 하자

 

주문테이블(2억건)

SELECT 컬럼1~컬럼50
  FROM 주문테이블
  WHERE 고객번호 = :고객번호
   AND 주문일시 BETWEEN :시작일 AND :종료일
    
현 인덱스: 고객번호+주문일시
 
고객번호별로 해당 테이블의 컬러스터링팩터는 엄청 안좋을 것이다.
이유는? 등록일자 별로 데이터는 적재가 되어 있고 고객은 가끔 주문을 하는 경우이다.
인덱스를 SCAN하지만 2억건의 주문테이블의 클러스터링 팩터는 엄청 엄청 안좋을 것이다.

 

어떻게 튜닝을 해야 원하는 속도가 나올것인가?

크게 보면 두가지 튜닝 방법이 있다.

 

1.시스템 PM작업이 있을때 데이터를 고객번호+주문일시로 다시 데이터를 생성한다.

 

CREATE TABLE 새로운주문테이블
AS
SELECT *
  FROM 주문테이블
ORDER BY 고객번호,주문일시;

단점)
해당 인덱스의 클러스터링 팩터를 좋게 하는 방법이지만 다른 인덱스는 클러스터링 팩트가 안좋아 질수가 있다.
즉 정말 많이 사용하는 유형을 분석해서 처리 해야 한다.무조건 절대 하면 안된다.


2.생각의 전환이다..어떻게? ^^
  인덱스를 메모리에 KEEP한다.
 
우리가 생각하기에 인덱스를 KEEP한다고 생각을 거의 하지 못했을 것이다.
결론은 I/O을 줄이는 것인데 2억건의 인덱스 또한 스캔하는것은 부담스러운 일이다.

메모리가 여유가 있다면 주요 인덱스는 메모리에 KEEP을 하면 당연 I/O가 좋아 질 것이다.

 

예제)
alter INDEX 인덱스명 storage (buffer_pool keep);

 

결론)
 1,2의 방법은 상황에 따라서 잘 활용을 해야 한다.
 튜닝은 100% 답이 있는것이 아니다.
 시스템,환경,여러가지 상황에 따라서 방법은 틀려 질수가 있다.
 
도움이 되시기를 바랍니다.

 

Tag

Leave Comments