[Book] 친절한 SQL 튜닝 - SQL 처리 과정과 I/0 - SQL 공유 및 재사용

1.2 SQL 공유 및 재사용

💡 SQL의 내부 최적화 과정의 복잡성을 알고 나면, 동시성이 높은 온라인 트랜잭션 처리 시스템에서는 바인드 변수가 중요하다.

 

라이브러리 캐시(Library Cache)

SQL파싱, 최적화, 로우 소스 생성 과정을 거쳐 생성한 내부 프로시저를 반복 재사용 할 수 있도록 캐싱해두는 메모리 공간. SGA의 구성요소다.

소프트 파싱 vs 하드 파싱

사용자가 SQL문 전달 → DBMS가 SQL을 파싱 후 → 해당 SQL이 라이브러리 캐시에 존재하는지 확인 → 캐시에 존재 ? Y실행 단계 : N최적화 단계

SQL을 캐시에서 찾아 곧바로 실행단계로 넘어가는 것을 ‘소프트 파싱(Soft Parsing)’
찾는데 실패해 최적화 및 로우 소스 생성 단계까지 모두 거치는 것을 ‘하드 파싱(Hard Parsing)’

SQL 최적화 과정은 왜 하드(Hard) 한가
하나의 쿼리를 수행하는 데 있어 많은 실행경로를 도출하고, 짧은 순간에 딕셔너리와 통계정보를 읽어 각각에 대한 효율성을 판단하는 과정은 결고 가벼울 수 없다. 데이터베이스에서 이루어지는 처리 과정은 대부분 I/O 작업에 집중되는 반면, 하드 파싱은 CPU를 많이 소비하는 몇 안 되는 작업 중 하나다. 

바인드 변수의 중요성

이름없는 SQL 문제

사용자 정의 함수/프로시저, 트리거, 패키지 등은 생성할 때부터 이름을 갖는다. 컴파일한 상태로 딕셔너리에 저장되며, 사용자가 삭제하지 않는 한 영구적으로 보관된다. 실행할 때 라이브러리 캐시에 적재함으로써 여러 사용자가 공유하면서 재사용한다.

반면, SQL은 이름이 따로 없다. 전체 SQL텍스트가 이름 역할을 한다. 딕셔너리에 저장하지도 않는다. 처음 실행할 때 최적화 과정을 거쳐 동적으로 생성한 내부 프로시저를 라이브러리 캐시에 적재함으로써 여러 사용자가 공유하면서 재사용한다.

DBMS에서 수행되는 SQL은 모두 완성된 SQL은 아니며, 특히 개발 과정에서 수시로 변경이 일어난다. 일회성(ad hoc) SQL도 많다. 일회성 또는 무효화된 SQL까지 모두 저장하려면 많은 공간이 필요하고, 그만큼 SQL을 찾는 속도도 느려진다. 오라클, SQL Server같은 DBMS가 SQL을 영구 저장하지 않는 쪽을 선택한 이유다.