Query 실행순서(select)

아래의 QUERY가 실행되는 순서를 알아보자.

select * from emp
where deptno = 10
          and sal >= 2500
order by empno;

- 사용자가 QUERY를 날린다.


parse

1. 동일 문장을 찾는다.
   ascii값으로 바꾼다. -> 바꾼 ascii값으로 hashing 함수를 통과시킨다. 
      -> hash key 값이 나옴 
          (Shared Pool의 Library Cache에서 hash chain을 찾는다.
           Library Cache에는 이전에 실행했던 SQL의 hash chain이 있다.)
   hashing된 결과를 볼 수 있는 query는 다음과 같다.(관련 column : hash_value)

select * from v$sqlarea

2. syntax 검사
    : 키워드의 오타 검사

3. semantics 검사
    : 단어를 놓고 관계를 검사.(권한, 객체 유무 등) -> recursive SQL(재귀적 SQL) 
       system 파일에 저장되어 있음 -> database buffer cache로 가져옴(block 단위)

4. Execution plan
    : 실행계획을 선택한다. (SQL> set autot on : 실행계획을 볼 수 있다.)


execute

:메모리에 있는 것을 읽음 - logical read 또는 cache hit라고 부른다.
 파일에 있는 것을 읽음 - physical read 또는 cache miss라고 부른다.


fetch

:가서 가져 오다.라는 뜻으로 select에서만 일어난다. 필요할 경우 sort가 됨
database buffer cache의 정렬이 안된 데이터를 PGA로 가져와서 정렬해서 리턴


기타 참고 사항

- DBA는 코딩규약을 만들어 개발자들이 지키도록 해야한다.
  같은 쿼리를 또다시 parsing과정을 거치지 않게 하기 위해서.
  메모리의 크기, 속도에 연관이 있다.

- select * from v$bh 로 database buffer cache의 내용을 볼 수 있다.
   bh는 block header의 약자

- 오라클은 디스크 기반 DBMS이다.

- 메인 메모리 DB도 있다. (응답속도가 매우 빠른 증권시스템에서 쓰임)

각 부분이 존재하는 이유
- library cache  : 동일 문장의 reparsing을 줄이기 위해
- row cache(data dictionary cache) : meta data disk i/o를 줄이는 위해
- database buffer cache : user data disk i/o 를 줄이기 위해

- 메타데이터 : 데이터 관리용 데이터
- 유저데이터 : 유저가 만든 데이터
- 서버튜닝(조정) : 상황에 따라 각 부분(library cache, row cache, database buffer cache)의 크기를 조정하는 것.