Histogram을 둘러싼 오해

1. 실행 계획의 변화

이러한 현상이 생기는 이유

• 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에서 큰 차이가 날 수 있다.