소프트 파싱 vs 하드 파싱, 라이브러리 캐시
사용자가 SQL문을 전달하면 DBMS는 SQL을 파싱한 후 해당 SQL이 SGA의 구성요소인 라이브러리 캐시에 존재하는지부터 확인한다.
SGA(System Global Area)는 서버프로세스와 백그라운드 프로세스가 공통으로 액세스하는 데이터를 캐싱하는 메모리공간인데, 여기안에 SQL파싱, 최적화, 로우소스 생성과정을 거쳐 생성된 내부 프로시저를 반복 재사용할 수 있도록 캐싱해두는 메모리공간인 라이브러리 캐시가 있다.

이 라이브러리 캐시에서 파싱한 SQL을 찾으면 바로 실행해버리지만 -> '소프트 파싱'
못찾으면 최적화단계를 거치게된다. -> '하드 파싱'
하나의 쿼리를 수행할 때 여러 실행경로를 만들고, 짧은 순간에 딕셔너리와 통계정보를 읽어 각각에 대한 효율성을 판단하는 과정은 hard하다. 이렇게 어려운(=hard)작업을 거쳐 생성한 내부 프로시저를 한 번만 사용하고 버린다면 엄청난 비효율이다. 라이브러리 캐시가 필요한 이유이다.
라이브러리 캐시에서 파싱한 SQL문을 찾는 key는 뭘까? ( 쿼리문은 함수처럼 별도로 이름이 없는데..)
전체 SQL 텍스트가 이름 역할을 한다. 즉 라이브러리 캐시에서 SQL을 찾기 위해 사용하는 키 값이
'SQL 문 그 자체'이므로 텍스트가 조금만 다르면 그 순간 다른 객체가 새로 탄생하는 구조다.
즉 아래 쿼리들은 의미는 같지만 실행할 때 각각 최적화를 진행하고 라이브러리 캐시에서 별도공간을 사용한다.
select * from cust where custno = 1;
select * FROM CUST WHERE Custno = 1;