오라클 구조(Architecture) 1

 

<Select 요청을 오라클이 처리하는 과정>

1. 사용자의 SQL 요청(사용자의 PC에는 오라클 클라이언트가 설치되어 있는 상태를 가정)

2. User Process는 tnsnames.ora 정보확인 후 Listener에게 접속요청

3. Listener은 PMON에게 사용자 접속요청

4. PMON은 사용자에게 Server Process 할당

5. Listener은 사용자의 SQL 쿼리 전달

6. User Process 와 Server Process 간 연결완료
(이후 Listener 간섭없이 User Process 와 Server Process 간 통신)

7. Sever Process는 도착한 SQL문(여기서는 Select Query)을 아래와 같이 크게 3단계로 나누어 처리
(Parse -> Execute -> Fetch)

가. Parse(구문분석) : SQL문의 문법, 권한, 의미검사를 진행하고, 실행계획을 생성해 내는 단계
1) 문법검사(Syntax) : 키워드의 철자, 키워드의 배치순서 등 검사
2) 권한 및 의미검사(Semantic) : 해당 객체에 접근권한이 있는지, 해당 객체가 실제 존재하는지 검사
(테이블, 컬럼, 뷰 등이 존재하는 지 검사)
3) 실행계획 생성 : 위 1) ~ 2) 단계를 거쳐 생성된 Parse Code를 오라클 Optimizer에게 전달해,
SQL문의 액세스 경로 확인, 튜닝 등의 작업을 실시한다.
결과물로 실행계획(Execute plan) 생성

참고 : Soft Parse Vs Hard Parse
Parse는 크게 Soft Parse, Hard Parse 로 나눈다. 제일먼저 Library Cache에 해당 SQL의 실행계획이 저장되어 있는지 확인하는 Soft Parse단계를 거치는데 실행계획인 존재한다면 바로 Execute 로 넘어간다. 만일, Library Cache에 없다면 위 syntax, semantic 검사를 통해 parse code를 생성하고, Optimizer를 통해 실행계획을 생성한다. 이후 Execute로 넘어간다. Soft Parse 에 비해 Hard Parse는 많은 I/O를 발생해 성능을 저하시킨다.

나. Execute(실행) : 실행계획에 따라 SQL 실행
(Datafile에서 필요한 데이터 블럭을 Database Buffer Cache로 불러들이는 과정등을 진행)

참고 : 테이블의 인덱스
실행단계에서 테이블에 인덱스가 생성되어 있었다면, 필요한 데이터 블럭을 바로 찾을 수 있어 디스크와 메모리사이의 I/O를 줄일 수 있다. 만일 인덱스가 생성되어 있지 않다면, 필요한 데이터 블럭을 찾기위해 테이블을 Full Scan하게 되며 많은 I/O로 성능이 크게 저하된다.

다. Fetch(인출) : 불러들인 블럭에서 원하는 결과값(row)을 찾음


8. 사용자에게 결과값 전달