[SQLP] 1-2. SQL 공유 및 재사용

 

1. 소프트 파싱과 하드 파싱의 차이점

라이브러리 캐시 : SQL 최적화 과정을 거쳐 생성한 내부 프로시저를 반복 재사용할 수 있도록 캐싱해두는 메모리 공간

 

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

 

사용자가 SQL문 전달 -> DBMS가 SQL파싱 후 해당 SQL이 라이브러리 캐시에 존재하는지 확인

-> 캐시 찾으면 실행                           : 소프트 파싱

-> 캐시 못찾으면 최적화 단계를 거친다.  : 하드 파싱

 

 

최적화 과정이 필요하면 하드 파싱인 이유

: 조인 순서, 조인 방식, 테이블 스캔할지 인덱스 스캔할지, 인덱스 스캔시 스캔 방식 결정

 

옵티마이저가 사용하는 정보

: 테이블, 컬럼, 인덱스 구조에 대한 기본 정보

오브젝트 통계 : 테이블, 인덱스, 컬럼 통계

시스템 통계 : CPU, SINGLEBLOCK I/O, MULTIBLOCK I/O 속도 등

옵티마이저 관련 파라미터

 

따라서 하드 파싱은 CPU를 많이 소비하는 작업.

 

---

 

2. 바인드 변수의 중요성

 

이름없는 SQL 문제

: SQL은 전체 SQL 텍스트가 이름 역할을 하므로, 처음 실행시 최적화 과정을 거쳐 동적으로 생성한 내부 프로시저를 라이브러리 캐시에 적재

 

-> 여러 사용자가 공유하면서 재사용

-> 캐시 공간이 부족한 경우, 버린 후 재실행시 같은 최적화 과정을 거쳐 캐시에 적재 

 

DBMS에서 수행되는 SQL이 수시로 변경되거나 일회성인 경우가 많아서 저장을 하지 않는다.

 

공유 가능 SQL

: 라이브러리 캐시에서 SQL을 찾기 위해 사용하는 키 값이 'SQL 문 그 자체' 이므로 같은 의미인 경우에도 각각 최적화를 진행하고 라이브러리 캐시에서 별도 공간을 사용한다.

 

하드 파싱은 CPU 자원을 많이 소비하기 때문에, 동시다발적인 작업을 할 경우에는 제대로 된 처리가 불가능할 수 있다.

-> 프로시저를 여러 개 생성해 라이브러리 캐시에 적재하면 이러한 결과 가능

-> 파라미터로 받는 프로시저 하나를 공유하면서 재사용하는 것이 마땅하다.

 

--로그인 ID를 파라미터로 받는 프로시저

CREATE PROCEDURE LOGIN (LOGIN_ID IN VARCHAR2){
...
}

바인드 변수 : 파라미터 Driven 방식으로 작성한 SQL

 

-> 라이브러리 캐시에 하나의 SQL만 존재

즉, 한번의 하드파싱만 일어나고, 나머지는 캐싱된 SQL을 공유하면서 재사용