1.2 SQL 공유 및 재사용

바인드 변수가 왜 중요한지 이해하자!

1.2.1 소프트 파싱 vs 하드 파싱

SQL 파싱, 최적화, 로우 소스 생성 과정을 거쳐 생성한 내부 프로시저를 반복 재사용할 수 있도록 캐싱해 두는 메모리 공간을 라이브러리 캐시(Library Cache)라고 한다. 라이브러리 캐시는 SGA(System Global Area)의 구성요소 이며 서버 프로세스와 백그라운드 프로세스가 공통으로 액세스하는 데이터와 제어 구조를 캐싱하는 메모리 공간이다.

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

SQL 최적화 과정은 왜 하드(Hard)한가

SQL 옵티마이저는 순식간에 엄청나게 많은 연산을 한다.

• 테이블, 컬럼, 인덱스 구조에 관한 기본 정보
• 오브젝트 통계 : 테이블 통계, 인덱스 통계, (히스토그램을 포함한) 컬럼 통계
• 옵티마이저 관련 파라미터

하나의 쿼리를 수행하는 데 있어 무수히 많은 실행경로를 도출하고, 짧은 순간에 딕셔너리와 통계정보를 읽어 각각에 대한 효율성을 판단하는 과정은 결고 가벼울 수 없다. 이렇게 하드한 작업을 거쳐 생성한 내부 프로시저를 한 번만 사용하고 버린다면 비효율이다. 따라서 라이브러리 캐시가 필요한 것이다.

---

1.2.2 바인드 변수의 중요성

이름없는 SQL 문제

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

공유가능 SQL

라이브러리 캐시에서 SQL을 찾기 위해 사용하는 키 값이 SQL문 그 자체이므로 아래는 모두 별도 공간을 사용한다.

 SELECT * FROM emp WHERE empno = 7900;
 select * from EMP where EMPNO = 7900;
 select /* comment */ * from  emp where empno = 7900;