1. SQL 처리 과정과 I/O [2/3]

1.2 SQL 공유 및 재사용

소프트 파싱과 하드 파싱의 차이점을 알아보고, 동시성이 높은 온라인 트랙잭션 처리 시스템에서 바인드 변수가 왜 중요한지 이해해보자.

1.2.1 소프트 파싱 vs 하드 파싱

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

 

사용자가 SQL문을 전달하면 DBMS는 SQL을 파싱 후 해당 SQL 라이브러리 캐시에 존재하는 지 확인한다. 캐시를 찾으면 바로 실행 단계로 넘어가지만, 찾지 못하면 최적한 단계를 거친다. 캐시를 찾아 바로 실행하는 것을 소프트 파싱

찾는 데 실패해 최적화 단계를 거치는 것을 하드 파싱이라고 한다.

 

1.2.2 바인드 변수의 중요성

* 이름없는 SQL 문제 

사용자 정의 함수/프로시저, 트리거 등은 생성할 때 부터 이름을 갖는다. 컴파일 상태로 딕셔너리에 저장되며 사용자가 제거하지 않는 이상 영구적 보관된다.

 

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

 

왜 SQL을 영구 저장하지 않을까? IBM DB2 같은 DBMS는 영구 저장하고 있다. 왜 오라클, SQL Server 같은 DBMS는 그렇게 하지 않을까?

 

요약하자면, SQL은 자체가 이름이기 때문에 작은 부분이라도 수정되면 다른 객체가 새로 탄생하는 구조이다.

DBMS에서 수행되는 SQL이 모두 완성된 SQL은 아니며, 개발 과정에서는 수시로 변경이 일어난다.

일회성 쿼리도 많다. 그 모두를 저장하려면 많은 공간이 필요하며, 그만큼 속도도 느려진다. 오라클 등의 DBMS가 영구 저장을 하지 않는 쪽을 선택한 이유이다.

 

아래는 의미적으로는 모두 같지만, 실행 시 각각 최적화를 진행하고 라이브러리 캐시에 별도 공간을 차지하게 된다.

SELECT * FROM emp WHERE empno = 7900;
select * from EMP where EMPNO = 7900;
select * from emp where empno = 7900;
select * FROM emp WHERE empno = 7900;
select * FROM emp where empno = 7900   ;
select * FROM scott.emp WHERE empno = 7900;

 

 

또한 이렇게 직성하면, 조회를 진행할 때마다 내부 프로시저를 하나씩만들어서 적재하는 셈이다. 

 

 

SELECT * FROM emp WHERE empno = 7900;
SELECT * FROM emp WHERE empno = 7500;
SELECT * FROM emp WHERE empno = 7400;
SELECT * FROM emp WHERE empno = 7680;
SELECT * FROM emp WHERE empno = 7980;
SELECT * FROM emp WHERE empno = 4400;

 

위 SQL의 프로시저 내부 처리 루틴은 모두 같다. 그렇다면 프로시저를 여러 개 생성할 것이 아니라 empno을 파라미터로 받는 프로시저 하나를 공유하면서 재사용하는 것이 더 마땅하다.

create proceduce Search (empno in int) {****}

 

위 처럼 파라미터 Driven 방식으로 SQL을 작성하는 방법이 바인드 변수이다.