by-nc-sa     개발자, DBA가 함께 만들어가는 구루비 지식창고!

Histogram을 둘러싼 오해




Histogram을 둘러싼 오해

1. 실행 계획의 변화

사람들이 Histogram을 싫어하는 이유

Histogram이 실행계획에 뜻하지 않은 변화를 줄 수 있다는 것


이러한 현상이 생기는 이유
  • Bind Peeking
  1. Histogram이 존재하는 경우에는 최초에 어떤 값이 Bind변수에 사용되느냐에 따라 실행계획이 결정된다.
  2. 또한 Hard Parse가 이루어질 때, 어떤 값이 주어졌느냐에 따라 실행계획이 매번 변할 수 있다.
    =>이런 이유로 많은 System에서 Bind Peeking을 비활성화한다.(_OPTIM_PEEK_USER_BINDS를 FALSE로 변경)
  • Density의 변화
    **Height-Balanced Histogram의 경우에는 Non Popular Value나 Bind변수로 이루어진 Predicate에 대해 Density를 사용
    => 즉 Density의 변화는 Cardinality의 변화를 초래하고 이는 곧 실행계획의 변화를 의미한다.
  • Join Cardinality의 변화
    • where절에 Join Predicate를 제외한 아무런 조건이 없는 경우에도 실행계획이 바뀔수 있다.


2. Distinct Count

  • Histogram에 대한 가장 흔한 오해 : Histogram은 Distinct Count가 낮은 Column에 대해서만 유용한것
    • Distinct Count는 Histogram과 전혀 무관하며, Histogram의 존재의 의의는 Data의 Skewness에 의해서만 결정된다.
    • Histogram의 생성 여부는 *Data가 얼마나 Skew 되어 있는가*로 판단


3. Index Scan vs. Table Full Scan

Index가 없는 Column에 대해 Histogram이 도대체 왜 필요한가?


  • Histogram의 존재의 목적은 Cardinality의 정확성을 높이는 것이다. Index를 경유하느냐 Table Full Scan을 하느냐는 Cardinality에 결정되는 결과일 뿐
예제
  select *
    from t1, t2
   where t1.c1 = t2.c2
     and t1.c2 = '서울' ;
     
  select *
    from t1, t2
   where t1.c1 = t2.c2
     and t1.c2 = '파주' ;   
  • t1.c2 = '서울' : 1000만건, t1.c2 = '파주' : 30만건 이면서 t1.c2에 인덱스가 없을 경우
    => 조건의 결과로 검색되는 row 수를 정확히 예측한다면 그 수에 따라서 Nested Loop 가 유리할 지 Hash Join 이 유리할 지 결정 할 수 있음.


4. Histogram은 전지 전능한가?

  • Histogram은 Bucket내에 존재하지 않는 값에 대한 Cardinality는 부정확하다.
  • Bind변수를 사용하면서 Bind Peeking을 비활성화 한경우에도 부정확하다.
  • Height-Balanced Histogram의 경우에는 특정 값이 Popular Value로 분류되는냐, Non Popular Value로 분류되느냐에 따라 Cardinality에서 큰 차이가 날 수 있다.
결론

Histogram은 많은 장점을 제공하나 많은 한계점도 존재하므로, 한계점을 명확히 인지하고 사용해야한다.

문서정보

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.