이번 시간에는 SQL문이 오라클 내부에서 어떻게 동작하는지에 대해 설명하려합니다. 갑자기 말투가 친절해졌다고 생각된다면 그것은 기분탓일거에요 ㅎㅎ
이번 챕터에서는 중요한 내용이 많으니 순차적으로 진행하면서 결론을 내리겠습니다.
그래도 정리한 내용은 앞으로 뺄게요 :)
SQL과 다른 프로그래밍 언어의 차이
SQL이 다른 프로그래밍 언어와 다른 점이 무엇이 있을까요? 바로 처리방법을 개발자가 기술하지 않는다는 점입니다. 예를들어 아래와 같은 쿼리가 있습니다.
SELECT A
FROM B
WHERE C = 1
위 쿼리는 ‘B라는 테이블에서 C가 1인 조건을 만족하는 데이터를 가저오는데, A컬럼의 값만 꺼내와’ 라는 의미입니다. 하지만 어떻게 데이터를 가저오는지, 어디서 가저오는지 우리는 알 수 없습니다.
Full scan을 통해 B 테이블을 전부 조회한 후에 가져올수도 있고, Index를 활용하여 데이터를 조회해 올 수도 있습니다. 바로 ‘어떻게 처리할지’에 대해 고민하는 것은 오라클이 스스로 해줍니다. 우리가 흔히 옵티마이저라고 불리는 기능이 바로 그것입니다.
옵티마이저가 스스로 처리한다고 비유적으로 표현했지만 사실 일련의 알고리즘을 통해 처리방법을 선택합니다. 크게 ‘규칙기반(Rule base)’와 ‘비용기반(Cost base)’로 구분됩니다만 오라클 10g부터는 규칙기반을 지원하지 않습니다.
따라서 비용기반 알고리즘에 대해 집중해보겠습니다.
비용기반 옵티마이저
간단하게 후려쳐서 설명하자면 ‘처리시간이나 I/O 횟수가 가장 적은 처리방법이 최고의 성능이다’ 입니다. 따라서 처리시간이나 I/O를 수치화하여 가장 적은 방법을 선택합니다.
그럼 조금 더 자세히 살펴보겠습니다. 우선 비용이 가장 적은 방법을 선택하기 위해 옵티마이저는 정보가 필요합니다. 이를 ‘통계 정보’라고 합니다. 통계 정보는 ‘이 테이블에는 데이터가 몇 건이나 존재하고 있으며, 데이터의 양은 이정도다’, ‘컬럼의 데이터 최대값과 최소값은 이런 것이다.’, ‘해당 테이블의 인덱스는 이것과 이것이 있다.’ 등 이와 같은 테이블이나 인덱스에 관한 수치를 말합니다.
통계 정보는 쿼리를 실행하기 이전에 미리 가지고 있어야 합니다. 만약 쿼리가 올 때 마다 이런 정보를 새로 수집하게 되면 속도가 상당히 지연될 것입니다. 따라서 오라클은 사용자가 별도의 요청을 하지 않아도 자동으로 통계 정보를 최신화 시켜줍니다.
이렇게 얻게 된 통계 정보를 기반으로 옵티마이저는 모든 경우의 수를 따져 비용이 가장 적은 방법을 처리방법으로 선택합니다. 따라서 비용기반 옵티마이저가 좋지 않은 성능을 보인다면 ‘선택 가능한 실행 계획의 수가 많다는 점’과 ‘이렇게 계산한 실행 계획이 어디까지나 예측에 지나지 않다’는 점 일 것 입니다.
공유 풀의 동작과 구조
비용을 분석하는 것은 컴퓨터의 자원소모가 큽니다. 모든 경우의 수를 예측하기 때문이죠. 그래서 오라클은 공유 풀을 통해 분석한 내용을 공유합니다. 이는 컴퓨터 자원소모가 심한 분석 작업을 줄이고 실행 계획을 공유하기 위해서 입니다.
그럼 어떻게 오라클은 같은 SQL문이라고 판단할까요?
오라클은 SQL문을 해시코드로 변환하여 관리합니다. 그래서 아래 두 SQL문은 오라클이 보기엔 서로 다른 SQL로 생각합니다.
-- 대문자로 작성
SELECT
empId
, empName
FROM emp;
-- 소문자로 작성
select
empId
, empName
from emp;
사람과 컴퓨터는 바라보는 기준이 다른가 봅니다 :)
마지막으로 아래 SQL문 같이 바인딩변수를 사용한다면 어떻게 동작할까요?
SELECT
empId
, empNames
FROM emp
WHERE empId = :empId;
변수의 값에 따라 SQL문이 달라지니깐 매번 분석작업을 실행할 것 같지만 SQL문의 해시코드는 변하지 않으므로 하나의 SQL문으로 생각합니다 :)
이번 4장에서는 공유풀과 옵티마이저에 대해 간단하게 알아봤는데요, 다음 포스팅에서는 오라클의 동작 순서와 정지상태에 대해 정리해오겠습니다.
오늘도 어김없이 감사합니다 ;)