SQLP
시험 직전 요약장
판단 기준과 헷갈리는 개념, 대표 예제를 짧게 확인하세요.
Hash Join 고급 튜닝: Data Skew·Bloom Filter·Build Input 제어
원래 이론 →판단 기준
Build Input은 원본 Row 수가 작은 Table이 아니라 실제 Hash Table Memory Footprint가 작은 Row Source가 유리합니다.
예시·텍스트좌우로 이동해 전체 내용을 확인하세요. 키보드: ←·→, Home·End
Input A
100만 행 × 20Byte
≈ 20MB + Overhead
Input B
30만 행 × 500Byte
≈ 150MB + Overhead
Input B는 Row 수가 적지만 더 큰 Build가 될 수 있습니다.
Build Input은 다음일 수 있습니다.
- Base Table Filter 결과
- Partition Pruning 결과
- Inline View·
CTE - 선집계 결과
- 이전 Join 결과
- Transformation 이후 Row Source
Build에 필요한 정보입니다.
- Join Key
- 최종 결과에 필요한 Build Column
- 상위 Operation에 전달할 식별자·표현식
- Null·
Outer Join 처리를 위한 정보
따라서 불필요한 Column 전달은 Build Memory와 TEMP Write Byte를 증가시킬 수 있습니다.
헷갈리는 개념
표를 좌우로 밀어 나머지 열을 확인하세요. 키보드: ←·→, Home·End
| 혼동 | 정확한 기준 |
|---|---|
| Collision과 Duplicate는 같다 | Collision은 다른 Key의 같은 Bucket, Duplicate는 같은 Key 반복 |
| Histogram이 Skew를 제거 | 추정을 개선할 뿐 실행 시 Skew는 남음 |
| Bloom 통과는 실제 Match | False Positive 가능, 실제 Key 비교 필요 |
| Bloom Plan이면 항상 효과 큼 | Probe·PX Row 감소량으로 검증 |
| V$SQL_JOIN_FILTER의 FILTERED가 항상 제거 Row | Version Reference와 Plan·Monitor 통계를 교차 확인 |
| USE_HASH가 Build Input까지 고정 | Join Order·Swap·Transformation도 작용 |
| Row 수가 작은 입력이 항상 작은 Build | Row 폭·Overhead 포함 Memory로 비교 |
| PGA만 늘리면 Spill 해결 | 입력·Projection·Skew·Join Order를 먼저 개선 |
| Input Swap Hint를 먼저 사용 | Statistics·Predicate·Order·폭을 먼저 수정 |
| Hash Join이면 결과 순서 보장 | ORDER BY만 결과 순서 보장 |
내 최근 연습 오답
현재 브라우저의 연습 채점 기록에서 공개된 단원과 연결된 오답을 확인합니다.
오답 기록을 확인하고 있습니다.