Clustering Factor

• 순서가 비슷할수록 Good Clustering Factor, 순서가 맞지 않을수록 Bad Clustering Factor
• Clustering Factor는 Index를 Scan하는 동안 방문(access)하게 되는 Table의 Data Block의 개수

전제조건

• 단 하나의 Table Data Block만 Memory에 Cache할 수 있다.
• Clustering Factor는 Physical Reads할 경우만 증가한다.

• 과거에 읽언던 Block인지의 여부는 중요하지 않고, 바로 직전에 읽었던 Block인지가 중요한 요소\!\!
• Clustering Factor값이 클수록 성능에 악영향을 미친다.

Good Clustering Factor

• Clustering Factor의 최소값은 Table의 Data Block의 수
• Sequence Key나 Date Type을 사용하는 Index는 Clustering Factor가 매우 양호
  • 단, FLM을 사용하는 경우 FREELISTS값이 1이상이고 동시에 여러개의 Process가 Insert를 수행하면 Clustering Factor가 높아질 수 있음
  • ASSM을 사용하는 경우 Free Block이 다차원적으로 사용되기 때문에 Clustering Factor가 높아지는 경향이 있음.
  • 그래서 위의 추론이 항상 적용되는 것은 아님.

Bad Clustering Factor

• Clustering Factor의 최대값은 Table의 Row의 수
• Index Key값이 Random하게 할당되거나, Reverse Index의 경우 Clustering Factor가 불량할 것임.
• Composite Index는 Key의 조합방식에 따라 Clustering Factor값의 변화가 생김

Clustering Factor and Performance

Index Scan의 Cost에 큰 영향을 준다.

• (예제) 동일한 통계정보를 가진 두 컬럼에 대하여, Clustering Factor의 차이를 두도록 Data를 생성한 후, Cost를 비교(page 125~)
• => 동일한 통계정보를 가진 두 컬럼에 대하여, Clustering Factor에 따라서 Cost는 큰 차이를 가진다.

Index Lookup을 통해 Data를 읽는 일의 양을 결정한다.

• 예제) Good/Bad Clustering Factor, Table Full Sacn에 대해 실제 일의 양을 계산해보면, 왜 Clustering Factor가 불량하면 Physical Read뿐만 아니라 Logical Reads도 큰 차이를 보이는가?(그림 참조)
• => Buffer Pinning 때문*

Manual Clustering Factor

• Clustering Factor는 통계정보 수집시에 계산되며 DBA_INDEXES.CLUSTERING_FACTOR값을 통해 확인가능
• 통계정보를 수집하는 위험을 감수하지 않고 Clustering Factor를 구하고 싶다면?
  • Index Key에 해당하는 컬럼들에 대해 정렬된 순서로 Table를 읽으면서 ROWID에 해당하는 DBA(Data Block Address)
  • 이전 ROWID의 DBA와 현재 ROWID의 DBA가 바뀔때마다 값을 1씩 증가.
  • SYS_OP_COUNTING Function을 사용