DBDBDEEP
3.2.3 배치 I/O 본문
인덱스를 이용한 테이블 랜덤 액세스는 고비용 구조임.
인덱스를 이용해 대량 데이터를 조회 시 디스크 I/O (Single Block I/O) 발생량이 증가함
Row가 많아질수록 버퍼캐시 경유 비용 + 래치 경합이 일어날 수 있어 고비용 구조다.
버퍼캐시에서 블록을 찾지 못하면 디스크 블록을 바로 읽는데 BATCH I/O 기능이 작동하면 블록에 대한 디스크 I/O Call을 미뤘다가 읽을 블록이 일정량 쌓이면 한꺼번에 처리함

Table Random Access 성능 개선을 위해 오라클 12c 이상부터 Batch I/O가 나왔다.
실행계획은 "TABLE ACCESS BY INDEX ROWID BATCHED"로 표시된다.
작동방식
기존 인덱스를 이용해 버퍼 캐시에서 찾지 못하면 Disk I/O를 수행하였던 Single I/O 방식과는 다르게, Batch I/O는 테이블 블록 Disk I/O를 잠시 미뤄두고 일정량 모은 뒤 일괄적으로 처리하게 되었다.
1. 리프 블록의 ROWID로 버퍼캐시 조회 → 실패 시 ROWID 저장
2. 실패한 ROWID 일정량 저장 시 블록 번호로 정렬하여 Multiblock I/O 수행
특징
기존 Single Block I/O 방식에서는 인덱스 만으로 결과 집합의 정렬이 보장되었지만,
Batch I/O 작동시 이러한 방식의 결과 집합을 보장하지 않게 되었다.
예시

emp_x01은 deptno, job, empno 으로 이루어져 있는데
소트 생략이 가능한 인덱스를 사용하더라도 I/O기능이 작동하면 데이터 정렬 순서를 보장할 수 없기 떄문에 옵티마이저가 SORT Operation을 추가하게 된다.
정리
데이터 정렬 순서를 보장하지 않는다.
버퍼캐시에서 읽는 블록 수는 동일하다. 디스크 I/O 미 발생시에는 성능차이 없다.
그러나 시스템 레벨에서 이를 비활성하는 경우가 있는데 ORDER BY를 생략한 SQL 패턴 때문이다.
ORDER BY가 없으면 정렬할 필요가 없으므로 좋은 선택지가 되겠지만,,
대량 배치 프로그램에서는 인덱스 보다 Full Scan이 효과적이지만, 초대용량 테이블을 Full Scan하면 상당히 오래 기다려야 하고 시스템에 주는 부담도 적지 않다.
따라서 배치 프로그램에서는 파티션 활용 전략이 매우 중요한 튜닝 요소이다.
병렬 처리까지 더할 수 있으면 더욱 좋다.

이와같은 쿼리가 있을 때 쿼리의 고객 변경 이력 테이블을 변경일시 기준으로 파티셔닝 하면
변경일시 조건(최근1년)에 해당하는 파티션만 골라서 Full Scan 할 수 있으므로 부담을 크게 줄일 수 있다.
'친절한 SQL 튜닝' 카테고리의 다른 글
| 3.3.5 인덱스 선행 컬럼이 등치(=) 조건이 아닐 때 (0) | 2026.05.18 |
|---|---|
| 3.3.3 액세스/필터 조건 (0) | 2026.05.18 |
| 3.1.5 인덱스만 읽고 처리 (0) | 2026.05.16 |
| 3.1.2 Index Clustering Factor (0) | 2026.05.16 |
| 2.3 인덱스 확장기능 (0) | 2026.05.16 |