실행/파싱고급Oracle 전용
Hard Parse
실행계획을 처음부터 새로 만드는 비싼 파싱
정의
SQL이 Library Cache에 없거나 재사용 불가능한 상태일 때 옵티마이저가 처음부터 실행계획을 만드는 과정. 구문 분석, 의미 분석, 권한 확인, 옵티마이저 비용 계산, 계획 생성 모든 단계를 거친다. 반대 개념은 Soft Parse — 캐시된 계획을 재사용한다. Hard Parse는 CPU와 Shared Pool 래치를 많이 소비한다.
왜 중요한가?
OLTP 시스템에서 Hard Parse 폭증은 즉시 CPU 100%로 이어진다. 원인은 보통 Bind Variable 미사용. 같은 패턴의 SQL이 리터럴 값만 다른 채로 수만 개 캐싱되면 Library Cache가 단편화되고 매번 Hard Parse가 발생한다.
틀리기 쉬운 포인트
- !Hard Parse 비율이 1% 이상이면 Bind Variable 미사용 의심.
- !CURSOR_SHARING=FORCE는 임시방편. 코드 수정이 정석.
- !SQL 텍스트가 한 글자라도 다르면 다른 SQL로 인식.
예시
SELECT name, value FROM v$sysstat WHERE name IN ('parse count (hard)', 'parse count (total)', 'execute count');
성능 포인트
!Hard Parse 비율이 1% 이상이면 Bind Variable 미사용 의심. 코드 수정으로 도입이 정석.