과거의 파일 시스템에서의 DB 프로그래머는 데이터 처리 절차를 일일히 코딩했다.
지금은 SQL 언어만 작성하면 DBMS의 SQL 옵티마이저가 이를 대신해준다.
사용자가 SQL문을 작성하면, 옵티마이저는 사용자가 원하는 결과를
최저의 비용으로 얻을 수 있는 데이터 처리 절차, 실행 계획(execution plan)을 만들어 낸다.
SQL 실행 순서
SQL 파싱
SQL 파서는 사용자가 입력한 SQL 문장에 문법적 오류를 검사한 후, (Syntax)
존재하지 않는 테이블을 참조했다거나, 권한이 없는 등의 의미상의 오류를 검사한다. (Semantic)
이후 이 문장이 라이브러리 캐시에 있는지 확인한다.
있으면 그 실행 계획을 바로 실행하면 된다.
이를 Soft Parsing이라고 한다.
없으면, 최적화를 새로 해야 한다.
이를 Hard Parsing이라고 한다.
라이브러리 캐시는 SQL문을 키로 하는 해시 구조이다.
SQL 문장이 조금만 달라져도 캐시에서 못 찾을 수도 (library cache miss) 있다.
SQL 최적화
옵티마이저는 3개의 서브 엔진을 사용한다.
Query Transformer: SQL문을 최적화하기 쉬운 형태로 변환한다.
Plan Generator: 후보군이 될만한 실행 계획들을 생성한다.
Estimator: 쿼리 실행 시 각 단계의 선택도(Selectivity), 카디널리티(Cardinality), 비용(Cost)을 계산해서 총 예상 비용을 계산한다.
이를 위해 I/O, CPU, 메모리 사용량 통계 정보를 이용한다.
이들은 오라클이 자동으로 수집하거나 DB관리자의 정책에 따라 주기적으로 수집되어 데이터 딕셔너리 캐시에 캐싱된다.
이후 최소의 비용을 갖는 하나의 실행 계획을 선정해서 실행한다.
하나의 쿼리를 수행하더라도 액세스 경로, 조인 방식, 순서 등 고려 사항이 많다.
이를 다 계산하기엔 어렵다.
그렇기에 두 가지 방법을 이용하여 비용을 현실적으로 계산한다.
Adaptive Search Strategy
쿼리 최적화에 걸리는 시간이 일정 비율을 넘지 않도록 하는 전략이다.
Multiple Initial Orderings Heuristic
조인할 때 다 해보는 게 아니라 최적의 실행계획을 발견할 가능성이 높은 순서대로 비용을 평가한다.
위 두 테크닉으로 오라클은 완전히 최소 비용은 아니더라도 만족할 만한 실행 계획을 찾아낼 수 있다.
Row-Source Generation
row source generator는 옵티마이저에게 최적의 실행 계획을 받아서
query plan이라고 하는 반복처리 계획을 생성해낸다.
query plan은 일을 처리하는 단계들의 집합으로 구성되어 있다.
각 단계는 row set을 반환한다.
이 set의 행들은 다음 단계에서 다시 쓰이거나,
SQL문을 실행한 주체로 반환되는 마지막 단계에 있다.
row source는 실행 계획의 각 단계가 반환하는 row set이며,
반복적으로 행들을 처리할 수 있는 제어 구조이다.
row source는 테이블이 될 수도, 뷰가 될 수도, 혹은 조인이나 그룹 동작의 결과일 수도 있다.
최적화 과정을 거쳐서 만들어진 실행 계획은 실제 실행 가능한 형태는 아니다.
이런 실행계획을 실행 가능한 코드 또는 프로시저 형태로 포맷팅하는 작업이 필요하며,
이 역할을 Row-Source Generator가 담당 한다.
요약
- 문법적(syntax), 의미상(semantic) 오류 검사
- sql문을 라이브러리 캐시에서 해싱해 검색한다.
- 검색된 해시 버킷을 돌면서 sql문-실행계획을 찾는다.
3-1. 찾았다면 해당 실행계획을 바로 실행한다. - 못 찾았으면 최적화를 수행한다.
- 최적화된 실행 계획을 아까 탐색한 해시버킷의 체인에 연결한다.
- 실행 계획을 통해 row-source을 생성한다.
- row source를 실행한다.
