친절한 SQL 튜닝 02

소프트 파싱 vs 하드 파싱

1. SQL 파싱, 최적화, 로우 소스 생성 과정을 거쳐 생성한 내부 프로시저를 반복 재사용할 수 있도록 캐싱해 두는 메모리 공간을 라이브러리 캐시(Library Cache)라고 한다.

 

2. 라이브러리 캐시는 SGA(System Global Area)의 구성요소다. SGA는 서버 프로세스와 백그라운드 프로세스가 공통으로 액세스 하는 데이터와 제오 구조를 캐싱하는 메모리 공간이다.

 

3. SQL문을 전달하면 DBMS는 파싱 후 해당 SQL이 라이브러리 캐시에 있는지 확인한다. 캐시에 있으면 곧바로 실행 단계로 넘어가지만 캐시 미스가 발생하면 최적화 단계를 거친다.

 

소프트 파싱 --> 라이브러리 캐시에 SQL이 존재해서 바로 실행단계로 넘어가는 과정

하드 파싱 --> 라이브러리 캐시에 캐시 미스가 발생해서 최적화 및 로우 소스 생성 단계까지 모드 거치는 과정

라이브러리 캐시의 존재 이유

1. 하나의 쿼리를 수행하는데 가능한 모든 실행 경로를 도출하고 단시간에 딕셔너리와 통계정보를 이용해 효율성을 판단하는 작업은 무거운 작업이다.

2. 즉 DB에서의 대부분 처리 과정은 I/O이지만 이 하드 파싱 과정은 CPU 자원을 많이 소모하는 몇 안 되는 작업 중 하나이다.

3. 어려운 작업, 즉 자원을 많이 사용한 작업을 한 번만 사용하고 버리는 것은 매우 비효율적이기 때문에 라이브러리 캐시가 필요하다.

 

JAVA) PreparedStatement의 필요성

1. 단순 SELECT 작업마다 프로시저가 새로 생성된다면 과도한 I/O로 인해 성능 저하의 원인이 된다. 실제로 라이브러리 캐시에는 쿼리에 입력값으로 들어가는 특정 값(예를 들어서 SELECT * FROM STUDENT WHERE ID=? 의?)만 필요한 SQL이라면 사용자가 이 쿼리를 수행하는 서비스를 호출할 때마다 하드 파싱 해서 SQL을 실행한다.

 

2. 이런 과정을 막기 위해 프로시저 중 내부 루틴 처리가 모두 같은 경우에는 프로시저 하나를 공유하면서 재사용하는 것이 당연하다.

 

3. 실제로 PreparedStatement를 사용해서 Javs에서 DB 작업을 한다면 라이브러리 캐시에는 중복된 프로시저가 존재하지 않게 된다. 즉 하드 파싱이 최초 한번 일어나고, 캐싱된 SQL을 사용자가 공유하면서 재사용한다.

 

출처 및 참고문헌

친절한 SQL 튜닝 국내도서 저자 : 조시형 출판 : 디비안(주) (DBian) 2018.06.01 상세보기