SQL 파싱을 거친 후 해당 SQL이 메모리에 캐싱 돼 있는지를 먼저 확인.

SQL커서를 메모리에서 찾아 곧바로 실행단계로 넘어가는 것을소프트 파싱 (SOFT Parsing)
찾는데 실패해 (라이브러리 캐시 Miss) 최적화 및 Row-Source 생성 단계를 거치는 것을 하드 파싱 (Hard Parsing)

하드 파싱이 '하드(Hard)한' 이유는 최적회가 그만큼 무거운 처리과정을 거치기 때문

h3.(1) SQL 파싱
사용자가 던진 SQL을 가장 먼저 받아서 처리하는 엔진이 SQL 파서 (Parser)다. SQL 파
서는 우선 SQL 문장을 이루는 개별 구성요소를 분석하고 파싱해서 파싱 트리를 만든다.

Syntax 체크 : 사용할 수 없는 키워드를 사용했거나 순서가 바르지 않거나 누락된 키워드가 있는지 등을 체크
Semantic 체크 : SQLASCII 텍스트에 대한 숫자 값을 계산하고 이를 다시 해시 값으로 변환
SQL 커서가 Shared Pool에 캐싱돼 있는지를 확인

Shared Pool에서 찾은 SQL 문장이 현재 수행하려는 SQL문과 100% 일치하더 라도 파싱을 요청한 사용자가 다르거나
옵티마이저 관련 파라미터 설정이 다르다면 새로운 SQL커서를 생성

예> 
HR유저 EMP테이블에 총건수 5건이 존재하며 empid 컬럼은 유니크인덱스가 존재.
SCOTT유저 EMP테이블에 총건수 100만건이 존재하며 empid 컬럼은 유니크인덱스가 존재.

select * from emp where empid = 1234;     

어떤유저는 HR유저로 접속, 어떤유저는 scott유저로 접속하여 위에 쿼리를 날림.
Syntax와 Semantic체크에 아무 문제가 없으나 의미가 상의하다.

h3.(2) SQL 최적화
옹티마이저는 앞에서도 설명했듯이 시스템 통계 및 오브젝트 통계정보를 판단기준으로 삼아 다양한 액세스 경로
(Access Path)를 비교하고 그 중 가장 효율적인 실행계획을 선택 해주는 DBMS의 핵심 엔진이다.

QUERY Transformer : 샤용자가 던진 SQL을 그대로 둔 채 최적화하는 게 아니라우선 최적화하기 쉬운 형태로 변환
Plan Generator : 하나의 쿼리를 수행하는 데 있어 후보군이 될만한 실행계획들을 생성
Estimator : 쿼리 오퍼레이션 각 단계의 선택도(selectivity)， 카디널리티 (Cardinality)， 비용(Cost)을 계산
궁극적으로는 실행계획 전체에 대한 총 비용을 계산(오브젝트 통계정보와 시스템 통계정보 이용)

짧은시간내 불가능에 가까운 많은일을 해야함

h4.오라클 옵티마이저의 기본 원리- 이상원 | (주)엑셈 연구소장 겸 성균관대학교 교수

예를 들어, 3개의 테이블, T1, T2, T3에 대해 조인을 수행하는 SQL 문이 있다고
가정하자. 그럼 이 질의를 수행할 수 있는 가능한 실행 계획은 몇 가지일까? 우리는
앞에서 조인 순서, 조인 방법, 그리고 테이블 액세스 방법에 따라 서로 다른 실행
계획이 만들어진다고 했다. 그렇다면, 3개의 테이블 T1, T2, T3에 대한 조인 순서
는 3!, 즉 6개의 조인 순서가 있다.
(T1§_T2)§_T3, (T1§_T3)§_T2, (T2§_T1)§_T3, (T2§_T3)§_T1, (T3§_T1)§_T2,
(T3§_T2)§_T1
그리고, 하나의 조인 순서에는 2개의 조인을 포함하는데, 이용 가능한 조인 방법이
Nested Loop, Sort Merge, Hash Join의 세 가지가 있다면, 각 조인 순서에 대
해 총 32, 즉 9개의 조합이 가능하다. 그리고, 이 각각의 경우 테이블을 접근하는
액세스 방법이 Full Table Scan과 Index Scan의 두 가지가 있다면 23, 즉 8개의
서로 다른 조합이 가능하다.
따라서, 3! x 32 x 23 = 432가지의 실행 계획이 가능하다. 그런데, 옵티마이저가
고려해야 할 실행 계획의 개수는 SQL에 포함된 테이블의 개수가 증가함에 따라 기
하급수적으로 늘어나게 된다. 만일 from 절의 테이블의 개수가 5개인 경우, 5! x
35 x 25 = 933,120개가 가능해진다.

*계산이 좀 잘못된 듯한 개인적인 생각*

그리고, 여기서 각 실행 계획의 예상 비용을 계산하는 데 걸리는 시간이 0.01초라고 
가정했을 때, 모든 실행 계획의 예상 비용을 구하는 데 약 9,300초(약 2시간 36분)이 
걸린다. 만일 테이블의 개수가 10개라고 가정하면, 아마도 모든 실행 계획의 예상 
비용을 계산하는 데만도 몇 년이 걸릴지도 모른다. 
21세기 IT 환경에서는 하나의 SQL 문에 5 ~ 10개 정도의 테이블이 포함되는 경우가 
일반적이다. 그런데, 옵티마이저가 실행 계획을 선정하는 데 걸리는 시간이 
이와같다면, 옵티마이저는 차라리 없는 것이 더 나을지도 모른다. 
따라서, 옵티마이저는 모든 가능한 실행 계획을 다 고려할 수는 없다. 즉, 질의 
최적화에 걸리는 시간을 줄이기 위해 어떤 실행 계획들은 아예 비용 계산에서 
제외해야 할 필요도 있다. 
옵티마이저는 모든 가능한 실행 계획 조합들을 탐색하는 방법 - 즉 어떤 실행 계획을 
먼저 고려하고, 어떤 순서로 다음 실행 계획을 찾고, 어떤 실행 계획은 제외할 것인가?
 - 을 갖고 있어야 한다.

(T1§_T2)§_T3, (T1§_T3)§_T2, (T2§_T1)§_T3, (T2§_T3)§_T1, (T3§_T1)§_T2, (T3§_T2)§_T1
3! = 3*2*1 = 6개

(T1§_T2)§_T3 | Nested Loop Nested Loop | 
(T1§_T2)§_T3 | Nested Loop Sort Merge  |
(T1§_T2)§_T3 | Nested Loop Hash Join   |
(T1§_T2)§_T3 | Sort Merge  Nested Loop |
(T1§_T2)§_T3 | Sort Merge  Sort Merge  |
(T1§_T2)§_T3 | Sort Merge  Hash Join   |
(T1§_T2)§_T3 | Hash Join   Nested Loop |
(T1§_T2)§_T3 | Hash Join   Sort Merge  |
(T1§_T2)§_T3 | Hash Join   Hash Join   |
3개의 조인 방법에 및 조인 걸리는 곳의 갯수 : 3의2승개 : 3*3 = 9개

(T1§_T2)§_T3 | Nested Loop Nested Loop |  Full Table Scan, Full Table Scan, Full Table Scan
(T1§_T2)§_T3 | Nested Loop Nested Loop |  Full Table Scan, Full Table Scan, Index Scan
(T1§_T2)§_T3 | Nested Loop Nested Loop |  Full Table Scan, Index Scan,      Full Table Scan
(T1§_T2)§_T3 | Nested Loop Nested Loop |  Full Table Scan, Index Scan,      Index Scan
(T1§_T2)§_T3 | Nested Loop Nested Loop |  Index Scan,      Full Table Scan, Full Table Scan
(T1§_T2)§_T3 | Nested Loop Nested Loop |  Index Scan,      Full Table Scan, Index Scan
(T1§_T2)§_T3 | Nested Loop Nested Loop |  Index Scan,      Index Scan,      Full Table Scan
(T1§_T2)§_T3 | Nested Loop Nested Loop |  Index Scan,      Index Scan,      Index Scan
2개의 스캔방법이 3개의 테이블의 적용 : 2의3승개 : 2*2*2 = 8개

===> 6*9*8 = 432개

5개의 예라면
5! = 5*4*3*2*1 = 120개
3의4승개 = 3*3*3*3 = 81개
2의5승개 = 2*2*2*2*2 = 32개 

120*81*32 = 311,040개
0.01초로 계산시 3110초 (약 52분) 

*어쨌든 많다.*

Adaptive search strategy(적응적 탐색 전략) : 쿼리 수행 시 예상되는 총 수행시간에 비해 쿼리 최적화에 걸리는 시간이 일정비율을 넘지 않도록 함
Multiple lnitial orderings heuristic' : 이것은 조인 순서를 무순위로 평가하는 게 아니라 최적의 실행계획을 발견할 가능성이 높은 순서대로 비용을 평가

h3.(3) Row-Source Generation
우리가 아는 실행계획은 개념 수준의 실행계획이지 실제 실행 가능한 형태는 아니다.
따라서 이것을 실행 가능한 코드 또는 프로시저 형태로 포뱃팅하는 작업

DB에서 이루어지는 처리 과정은 대부분 1/0 작업에 집중되는 반면 하드 파싱은
CPU를 많이 소비하는 몇 안 되는 작업 중 하나에 속한다. 하드 파싱 과정에서 Shared Pool과 라이브러리 캐시에
대해 발생하는 래치 경합도 CPU를 많이 소비하게 만드는 요인으로 작용한다.