[Admin] 쿼리 수행 절차 (SELECT문)

◆ SELECT문의 쿼리 수행 절차

① User Process는 사용자가 실행한 쿼리를 받는다.
② 쿼리를 Server Process에 넘겨주어 결과를 달라고 요청한다.
③ Server Process는 맨 먼저 SGA의 Shared Pool에 있는 Dictionary Cache로 가서 문법/권한 검사를 한다. 그러고 난 후 해당 SQL에 대한 실행계획이 있는지 Library Cache에서 찾아본다. 만약 없다면 옵티마이저에게 실행계획 좀 세워달라고 부탁한다. 옵티마이저는 Dictionary Cache를 참고하여 해당 SQL문에 대한 실행계획을 세워 Server Process에게 전달한다. Server Process는 옵티마이저가 세워준 실행계획에 써있는대로 다음 단계로 넘어간다.
만약 해당 SQL문에 대한 실행계획이 있다면 바로 다음 단계로 넘어간다.
④ DB Cache에 사원(emp)테이블이 없다면 디스크에서 사원테이블이 속한 블록을 모두 메모리로 끌어올린다. 만약 DB Cache에 이미 사원 테이블이 올라와져 있었다면 execute 단계는 생략한다.
⑤ Execute단계에서 블록 단위로 끌어올린 DB Cache의 사원테이블 데이터 중 필요한 줄만 뽑아내어 PGA에 저장한다.
⑥ 해당 쿼리문의 결과를 User Process에 전달한다.

---

오라클도 반드시 쿼리를 받으면 컴파일을 한다.
일반 프로그래밍 언어는 컴파일도 사용자가 해주는데, 오라클은 서버프로세스가 쿼리를 받아서 컴파일을 하러 간다. 그 컴파일을 컴파일 작업이라 부르지 않고 Parse(구문분석)라고 부른다.

옵티마이저는 쿼리가 가장 빨리 실행될 수 있는 계획을 세워준다. 이를 실행계획이라고 한다.
서버프로세스는 딕셔너리에게 해당 쿼리가 문법에 맞는지 물어본다. 이를 Recursive SQL이라 한다.
그 다음 Library Cache를 뒤져서 실행계획이 존재하는지 찾아본다.
없으면 옵티마이저에게 실행계획을 물어본다.
옵티마이저가 세워준 실행계획 즉, 한번 실행되었던 쿼리와 실행계획은 버리지 않고 Library Cache에 저장해 놓는다. 이렇게 하면 다음에 같은 쿼리가 실행되었을 때 이 실행계획을 가지고 바로 다음 단계로 갈 수 있다.
여기서 Library Cache에 실행계획이 있었다면 이를 소프트파싱(Soft Parsing)이라 하고, 실행계획이 없어서 옵티마이저가 Dictionary Cache에서 실행계획을 수립하는 것을 하드파싱(Hard Parsing)이라 한다.

생각을 해보자. 소프트파싱과 하드파싱 중 당연히 소프트파싱이 많을수록 성능이 좋을 것이다.
오라클은 최대한 소프트파싱을 많이 하기 위해 많은 기법이 동원된다. 이는 튜닝시간에 좀 더 자세히 알아본다.

항상 모든 쿼리에 사용되는 테이블 데이터는 DB Cache에 올라와 있어야 한다.
DB Cache에 원하는 테이블(emp)이 있다면 바로 그것을 이용하면 되고, 없다면 디스크에서 테이블 블록을 끌어올려서 DB Cache에 놓는다. 이를 Execute단계라고 한다.
Execute단계에 디스크에서 메모리로 데이터를 끌어올리는 그 시간이 굉장히 오래 걸린다. 이는 오라클의 중요한 성능요소 중 하나이다.

옵티마이저는 인덱스 관련 실행계획을 수립시 블록의 위치를 딱딱 찝어주는 실행계획을 만들어주는 것이 아니라 인덱스가 있으면 인덱스에게 가서 물어보라는 식의 실행계획을 수립해준다. 인덱스가 없다면 풀스캔을 하라는 계획이 들어가있다.

자 또 한번 생각을 해보자. Library Cache의 크기가 클수록 좋을까 작을수록 좋을까? 조금 어렵다면 질문을 다시 던져보겠다. 많이 기억하고 있을수록 속도가 빠를까 조금 기억하고 있을수록 속도가 빠를까? 당연히 많이 기억하고 있을수록 속도가 빠를 것이다.
Dictionary Cache는 원래 DB Cache에 System tablespace에 있는 것인데 대략 500M의 용량을 차지하고 있다. 이것을 모두 싹 Shared Pool에 갖다 놓을수는 없을 것이다. 그 중 자주 쓰는 Dictionary정보들을 Shared Pool의 Dictionary Cache로 갖다놓자는 것이다. 만약에 갖다놓은 것 중에 없는 정보가 있다면 그때는 DB Cache에서 정보를 가져오면 된다.

그다음 DB Cache의 크기가 클수록 성능이 좋을까 작을수록 성능이 좋을까? 보통 일반적으로 DB Cache 사이즈가 클수록 메모리에 저장되어 있는 데이터가 많다는 뜻이므로 Execute횟수도 당연히 줄어들 것이다. 그러나 현실적으로 DB Cache의 용량을 너무 크게는 하지 못한다.
일반적으로 오라클은 메모리가 크면 성능이 좋다고 한다. 그러나 무조건 좋다고만은 말할 수 없다.
실행단계에서 DB Cache 안을 뒤지는데, 그 공간이 좁다면 금방 필요한 데이터를 찾는데, 공간이 넓다면 찾는데만도 시간이 오래 걸릴 것이다. 즉, 상황에 따라서 다르다는 것을 알아두자.

메모리 튜닝의 핵심은 필요시 조사를 해보아서 적으면 크게 잡아주면 되고 너무 크면 조금 줄이면 되는 식으로 해주면 된다.