Step 3) SQL 문장에 사용된 테이블 이름이나 컬럼 이름이 정확한지, 그리고 SQL 문장을 사용하는 사용자가 해당 테이블에 대한 권한이 충분한지 데이터 딕셔너리를 참조하여 확인하는 과정
Step 4) 내부적으로 복잡한 SQL 문장을 보다 효율적으로 수행할 수 있는 다른 SQL문장으로 변환시키는 과정
Step 5) 해당 SQL문장을 어떤 방식으로 실행할 것인지 최단 경로 선택
라이브러리 캐시
모든 파스 과정이 완료되면 파스된 SQL 문장들과 그들의 실행 계획들이 공유 풀의 한 영역인 라이브러리 캐시에 저장되고, 이들은 같은 인스턴스를 사용하는 사용자들에 의하여 이후에 지속적으로 공유될 수 있다.
라이브러리 캐시에 파스된 SQL 관련 정보를 저장하는 이유는 오라클 성능을 높여주는 역할을 하기 때문이다.
임의의 사용자가 라이브러리 캐시에 이미 저장되어있는 SQL 문장을 실행하는 경우 파스 과정을 다시 거치지 않고 바로 메모리에 저장된 파스 정보를 그대로 사용하게 된다. 이처럼 파스에 소요되는 자원을 최소화하여 속도를 높이게 된다.
오라클은 LRU(Least Recently Used)라는 알고리즘을 적용하여 SQL 문장들 가운데 가장 최근까지 자주 실행된 SQL 문장들만을 이곳에 보관하는 방법을 제공한다.
데이터 딕셔너리 캐시
SQL 문장에 대한 파싱이 시작되면 데이터 딕셔너리로부터 지속적으로 객체와 객체의 권한, 객체의 구조, 사용자가 정의한 테이블, 뷰, 인덱스 기타 데이터베이스 오브젝트 정보를 참조하게 된다. 이처럼 파싱 과정 가운데 참조된 데이터 딕셔너리 오브젝트 정보를 저장하는 공간을 데이터 딕셔너리 캐시라고 부른다.
데이터 딕셔너리 오브젝트들이 데이터 딕셔너리 캐시에 로딩되고 나면 그 후로는 디스크에 저장된 데이터 딕셔너리 오브젝트 정보를 다시 읽어들이는 것이 아니라 메모리 영역인 데이터 딕셔너리 캐시에 저장되어져 있는 정보를 바로 가져다가 사용하게 된다.
데이터 딕셔너리 오브젝트의 속성을 변경하고자 하는 프로세스는 그에 해당하는 데이터 딕셔너리 캐시 오브젝트에 대한 Row cache lock[각주:1]을 획득해야 한다.
Reserved pool
SQL 문장이나 PL/SQL 패키지가 파싱되고 나면 이들 오브젝트는 메모리 상에 저장되는데, 이때 오라클은 내부적으로 Chunk라는 메모리 조각으로 이들을 나누어 저장하게 된다. 기본적으로 1KB와 4KB 크기의 Chunk를 사용하는데 해당 오브젝트의 크기가 커서 4KB 이상의 Chunk를 사용해야 하는 상황이 발생하면 오라클은 라이브러리 캐시가 아닌 Reserved pool에 이들을 저장 관리한다.
