1-1. SQL 파싱(Parsing) - 인스턴스 환경편

Shared Pool은 동일한 문장이 반복적으로 들어왔을 때 Parse작업을 하지 않고 바로 사용할 수 있도록 공유의 목적으로 사용된다.

유저 프로세스에서 SELECT문을 요청하여 Listenser를 통해 Connection까지 완료되었다면, 서버 프로세스가 해당 SELECT문을 처리한다. 

결과를 반환하기까지 Parse – Execute – Fetch 단계를 거친다. Shared Pool은 Parse 단계에서 사용된다.

 

1. 사용자가 SQL문장(select)을 실행

- 사용자가 SELECT 쿼리를 요청하면 리스너가 요청을 받아 서버 프로세스로 SQL 문장을 전달한다. 다만, 최초 연결 시점이 아니라 연결이 이미 성립된 후라면 쿼리 실행은 유저 프로세스와 서버 프로세스 간 직접 통신으로 진행된다.

 

2. SQL 파싱

- 서버 프로세스는 전달받은 SQL 구문을 PGA 내부의 ‘Private SQL Area’에서 문법 검사(Syntax Check)를 우선 진행하고, 테이블 및 컬럼이 있는지, 해당 사용자가 테이블 및 컬럼을 SELECT 할 권한이 있는지(Semantic Check)를 Data Dictionary Cache를 통해 확인한다.

-  SQL 구문이 Syntax, Semantic 체크를 모두 통과하였다면 이 SQL 구문은 오류가 없는 문장이 된다. 문장에 해싱 알고리즘을 적용하여 해시 키를 만들고 해시 키를 이용하여 라이브러리 캐시 내의 ‘Shared SQL Area’에서 동일한 해시 키 값을 가지는 SQL 문장이 존재하는지를 확인한다.

-  라이브러리 캐시를 조회해서 동일한 SQL 문장이 있는지 확인하는데 공백, 대소문자까지 비교하여 동일한 SQL 문장을 찾으면, 라이브러리 캐시에 이미 존재하는 파싱 트리와 쿼리 실행계획을 가지고 와서 실행한다(=Soft Parsing).

-  일치하는 SQL 커서가 존재하지 않을 경우, 체크를 끝낸 SQL 문장을 옵티마이저에게 전달하는데 이를 하드 파싱이라고 한다. 하드 파싱의 경우, 옵티마이저가 생성한 실행계획(ex. index/full scan)을 기반으로 데이터 접근 경로를 결정한 후, 나중에 소프트 파싱이 가능하도록 실행계획을 라이브러리 캐시에 저장한다. 다만 하드 파싱은 필요한 오브젝트의 래치를 획득 후 파싱 트리를 만들기 위해 빈번히 라이브러리 캐시 및 데이터 딕셔너리 캐시를 탐색하게 되어 성능이 떨어지게 된다.

 

3. SQL 실행(Execute) 단계

-   서버 프로세스는 DB 버퍼 캐시에서 필요한 데이터 블록을 탐색한다. 필요한 블록이 캐시에 없는 경우 디스크(데이터 파일)에서 블록을 읽어 DB 버퍼 캐시에 적재한 후에 데이터를 가져온다.

-   만약 SELECT(조회 문)이 아닌 데이터 변경(DML 문)의 경우 리두 로그 버퍼에 변경 사항을 기록하고 undo 세그먼트에 이전 데이터의 백업 이미지를 저장하여 롤백이 가능하도록 한다.

-   정렬 작업이나 해시 조인이 필요한 경우 해당 작업은 PGA의 ‘SQL Work Area’에서 수행하게 된다.

 

4. SQL 결과 조회(Fetch) 단계

-   DB 버퍼 캐시에서 가져온 결과 데이터를 전달받는 단계로써, Result 캐시가 활성화 되어있는 경우에는 SGA 내 Result 캐시에 저장되고 캐시를 통해 유저 프로세스로 결과가 전달된다.

-   Result 캐시가 활성화 되어있지 않은 경우에, 데이터는 응답 큐에 저장되고 결과는 응답 큐를 통해 유저 프로세스로 직접 전달된다(공유 서버 방식).

-   대량의 데이터가 필요한 경우, 여러 번의 Fetch 단계를 거쳐 데이터를 가져온다.

 

5. 결과 반환

-   최종적으로 가공된 결과는 Result 캐시가 활성화되어 있는 경우, 서버 프로세스가 직접 유저 프로세스에게 결과를 돌려주며, Result 캐시가 활성화되어 있지 않은 경우, 결과는 응답 큐를 통해 유저 프로세스로 전달된다.