AniBumiRami의 블로그

1. 실행계획

1. AutoTrace 이용

§ [sy]

set autotrace on

select * from emp where empno=7900;

i. set autotrace on

sql을 실제 수행하고 그 결과와 함께 실행계획 및 실행통계를 출력한다.

ii. set autotrace on explain

sql을 실제 수행하고 그 결과와 함께 실행계획을 출력한다.

iii. set autotrace on statistics

sql을 실제 수행하고 그 결과와 함께 실행통계를 출력한다.

iv. set autotrace traceonly

sql을 실제 수행하지만 그 결과는 출력하지 않고 실행계획과 통계만을 출력한다.

v. set autotrace traceonly explain

sql을 실제 수행하지 않고 실행계획만을 출력한다.

vi. set autotrace traceonly statistics

sql을 실제 수행하지만 그 결과는 출력하지 않고 실행통계만을 출력한다.

○ 1,2,3,4,6 은 수행결과 및 실행통계를 보여줘야 하므로 쿼리를 실제 수행한다. 

○ 5는 실행계획만 출력하면 되므로 쿼리를 실제 수행하지 않는다.

2. DBMS_XPLAN 패키지

  • PLAN_TABLE에 저장된 실행계획을 좀 더 쉽게 출력해 볼 수 있다.

  • [sy]

SELECT PLAN_TABLE_OUTPUT 

FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE', NULL, 'SERIAL'));

  • 첫번째 인자는 실행계획이 저장된 PLAN TABLE명을 입력

  • 두번째 인자는 STATEMENT_ID를 입력, NULL일경우 마지막 EXPLAIN PLAN 명령에 사용했던 쿼리의 실행계획을 보여준다.

  • 세번째 인자는 포맷옵션 선택

  • 예)

explain plan [set statement_id = 'SQL1'] for

select * from emp e, dept d

where d.deptno=e.deptno

and e.sal>=1000;

§ set statement_id 를 설정해주지 않으면 마지막에 실행한 쿼리를 null을 이용해 볼 수 있다.

select * from table(dbms_xplan.display('PLAN_TABLE', 'SQL1'(null), 'BASIC'));  

select * from table(dbms_xplan.display('PLAN_TABLE', 'SQL1', 'TYPICAL'));

select * from table(dbms_xplan.display('PLAN_TABLE', 'SQL1', 'SERIAL'));

select * from table(dbms_xplan.display('PLAN_TABLE', 'SQL1', 'ALL'));

  • 옵션종류

§ BASIC

§ TYPICAL

§ ROWS

§ BYTES

§ COST

§ PARTITION

§ PARALLEL

§ PREDICATE

§ PROJECTION

§ ALIAS

§ REMOTE

§ NOTE

  • 모두 다 출력해 보이려면 ALL 옵션을 사용하면 된다.

  • 실행계획을 수립하는데 필요한 힌트 목록을 출력.

§ outline

  • all과 outline 을 함께 사용하여 출력

§ advanced

2. SQL 트레이스 수집 및 분석

가. SQL 트레이스 수집

1. 현재 자신이 접속해 있는 세션에만 트레이스 설정

alter session set sql_trace=true;

select * from emp where empno=7900;

select * from dual;

alter session set sql_trace=false;

2. user_dump_dest 파라미터로 지정된 서버 디렉토리 밑에 트레이스 파일이 생성된다. 다음 쿼리를 실행하면 찾을 수 있다.

select r.value || '/' || lower(t.instance_name) || '_ora_' || ltrim(to_char(p.spid)) 

|| '.trc' trace_file

from v$process p, v$session s, v$parameter r, v$instance t

where p.addr = s.paddr

and r.name = 'user_dump_dest'

and s.sid = (select sid from v$mystat where rownum = 1);

나. SQL 트레이스 포맷팅

• 세션에서 트레이스 생성되게 설정 변경 후 생성된 트레이스 파일을 tkprof 포맷팅 하기

§ 트레이스 이름 설정

alter session set tracefile_identifier='AAA'; => 이후 생성되는 트레이스 파일은 뒤에 AAA가 붙는다.

§ alter session set sql_trace=true;

§ alter session set timed_statistics=true;

§ select * from emp where empno=7900;

• 저장경로 확인

§ show parameter user_dump_dest;

• tkprof 형식으로 바꾸기

§ 트레이스가 있는 폴더로 이동 후 명령어 입력

□ tkprof 원본이름 출력될이름.txt explain=kmj/kmj sys=no

□ 같은 폴더에 출력될이름.txt 가 생성됨.

다. SQL 트레이스 분석

○ 앞선 AutoTrace 실행 통계 항목과 비교해 보면 다음과 같다

§ db block gets                               = current

§ consistent gets                              = query

§ physical reads                               = disk

§ SQL*Net roundtrips to/from client     = fetch count

§ rows processed                             = fetch rows

• Call 통계 아래쪽 Row Source Operation

§  Rows 는 각 수행 단계에서 출력(Flow-Out) 된 로우 수를 의미한다.

§ cr, pr, pw, time 은 Consistent 모드 블록 읽기, 디스크 블록 읽기, 디스크 블록 쓰기, 소요시간(us=microsecont)

§ 부모는 자식 노드의 값을 누적한 값을 갖는다. 

예를들어 emp 테이블 액세스 단계는 cr=2이고, 그 자식 노드인 emp_pk 인덱스 액세스 단계는 cr=1이므로, 인덱스를 읽고 난 후 테이블을 액세스하는 단계에서 순수하게 일어난 cr 개수는 1이다.

3-3. 조인 수행 원리

1. NL JOIN

  • NL JOIN은 프로그래밍에서 사용하는 중첩된 반복문과 유사한 방식으로 조인을 수행한다.

  • 반복문의 외부에 있는 테이블을 선행 테이블 또는 외부 테이블이라고 하고, 내부에 있는 테이블을 후행 테이블 또는 내부 테이블이라고 한다.

1. 선행 테이블에서 조건을 만족하는 첫 번째 행을 찾음 ->이때 선행 테이블에 주어진 조건을 만족하지 않는 경우 해당 데이터는 필터링 됨

2. 선행 테이블의 조인 키를 가지고 후행 테이블에 조인 키가 존재하는지 찾으러 감 -> 조인 시도

3. 후행 테이블의 인덱스에 선행 테이블의 조인 키가 존재하는지 확인 -> 선행 테이블의 조인 값이 후행 테이블에 존재하지 않으면 선행 테이블 데이터는 필터링 됨 (더 이상 조인 작업을 진행할 필요 없음)

4. 인덱스에서 추출한 레코드 식별자를 이용하여 후행 테이블을 액세스 -> 인덱스 스캔을 통한 테이블 액세스 후행 테이블에 주어진 조건까지 모두 만족하면 해당 행을 추출 버퍼에 넣음

5. ~ 11. 앞의 작업을 반복 수행함.

2. SORT MERGE JOIN

  • 조인 칼럼을 기준으로 데이터를 정렬하여 조인을 수행한다.

  • 스캔 방식으로 데이터를 읽는다.

  • 정렬할 데이터가 많아 메모리에서 모든 정렬 작업을 수행하기 어려운 경우에는 임시 영역(디스크)을 사용하기 때문에 성능이 떨어질 수 있다.

  • 일반적으로 대량의 조인 작업에서 정렬 작업을 필요로 하는 경우 CPU 작업 위주로 처리하는 HASH JOIN이 성능상 유리하다.

  • SORT MERGE JOIN은 HASH JOIN과는 달리 동등 조인 뿐만 아니라 비동등 조인에서도 조인 작업이 가능하다는 장점이 있다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음

2. 선행 테이블의 조인 키를 기준으로 정렬 작업을 수행. 1~2 작업을 선행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행

3. 후행 테이블에서 주어진 조건을 만족하는 행을 찾음

4. 후행 테이블의 조인 키를 기준으로 정렬 작업을 수행. 3~4 작업 반복 수행

5. 정렬된 결과를 이용하여 조인을 수행하며 조인에 성공하면 추출버퍼에 넣음.

3. HASH JOIN

  • 해슁 기법을 이용하여 조인을 수행

  • 조인을 수행할 테이블의 조인 칼럼을 기준으로 해쉬 함수를 수행하여 서로 동일한 해쉬 값을 갖는 것들 사이에서 실제 값이 같은지를 비교하면서 조인을 수행한다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음

2. 선행 테이블의 조인 키를 기준으로 해쉬 함수를 적용하여 해쉬 테이블을 생성 -> 조인 칼럼과 SELECT 절에서 필요로 하는 칼럼도 함께 저장됨. 1~2 작업을 선행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행

3. 후행 테이블에서 주어진 조건을 만족하는 행을 찾음

4. 후행 테이블의 조인 키를 기준으로 해쉬 함수를 적용하여 해당 버킷을 찾음 -> 조인 키를 이용해서 실제 조인될 데이터를 찾음

5. 조인에 성공하면 추출버퍼에 넣음. 3~5 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해서 반복 수행

  • HASH JOIN은 조인 칼럼의 인덱스를 사용하지 않기 때문에 조인 칼럼의 인덱스가 존재하지 않을 경우에도 사용할 수 있다

  • 해쉬 함수를 이용하여 조인을 수행하기 때문에 '='로 수행하는 조인, 즉 동등 조인에서만 사용할 수 있다.

  • HASH JOIN을 할 때는 결과 행의 수가 적은 테이블을 선행 테이블로 사용하는 것이 좋다.

3장. SQL 최적화 기본 원리

3-1. 옵티마이저와 실행계획

1. 옵티마이저

  • 옵티마이저는 사용자가 질의한 SQL문에 대해 최적의 실행 방법을 결정하는 역할을 수행한다.

  가. 규칙기반 옵티마이저

§ 주요한 규칙

1) 규칙 1 (SINGLE ROW BY ROWID) : ROWID를 통해서 테이블에서 하나의 행을 액세스 하는 방식. 다른 정보를 참조하지 않고도 바로 원하는 행을 액세스 할 수 있다. 하나의 행을 액세스 하는 가장 빠른 방법이다.

2) 규칙 4 (SINGLE ROW BY UNIQUE OR PRIMARY KEY) : 유일 인덱스를 통해서 하나의 행을 액세스 하는 방식이다. 인덱스를 먼저 액세스 하고 인덱스에 존재하는 ROWID를 추출하여 테이블의 행을 액세스 한다.

3) 규칙 8 (COMPOSITE INDEX) : 복합 인덱스에 동등('=' 연산자) 조건으로 검색하는 경우. 인덱스 구성 칼럼의 개수가 더 많고 해당 인덱스의 모든 구성 칼럼에 대해 '='로 값이 주어질 수록 우선순위가 더 높다.

4) 규칙 9 (SINGLE COLUMN INDEX) : 단일 칼럼 인덱스에 '=' 조건으로 검색하는 경우.

5) 규칙 10 (BOUNDED RANGE SEARCH ON INDEXED COLUMNS) : 인덱스가 생성되어 있는 칼럼에 양쪽 범위를 한정하는 형태로 검색하는 방식. BETWEEN, LIKE 등이 있다.

6) 규칙 11 (UNBOUNDED RANGE SEARCH ON INDEXED COLUMNS) : 인덱스가 생성되어 있는 칼럼에 한쪽 범위만 한정하는 형태로 검색하는 방식. >, >=, <, <= 등이 있다.

7) 규칙 15 (FULL TABLE SCAN) : 전체 테이블을 액세스 하면서 조건절에 주어진 조건을 만족하는 행만을 결과로 추출한다.

§ 규칙기반 옵티마이저는 인덱스를 이용한 액세스 방식이 전체 테이블 액세스 방식보다 우선순위가 높다.

§ 조인 순서를 결정할 때는 조인 칼럼 인덱스의 존재 유무가 중요한 판단의 기준이다.

1. 조인 칼럼에 대한 인덱스가 양쪽 테이블에 모두 존재한다면 앞에서 설명한 규칙에 따라 우선순위가 높은 테이블을 선행 테이블로 선택한다.

2. 한쪽 조인 칼럼에만 인덱스가 존재하는 경우에는 인덱스가 없는 테이블을 선행 테이블로 선택한다.

3. 조인 칼럼에 모두 인덱스가 존재하지 않으면 FROM 절의 뒤에 나열된 테이블을 선행 테이블로 선택한다.

4. 조인 테이블의 우선 순위가 동일하다면 FROM 절에 나열된 테이블의 역순으로 선행 테이블을 선택한다.

  나. 비용기반 옵티마이저

§ 규칙기반은 '=' 연산자와 'BETWEEN' 연산자가 사용되면 규칙에 따라 '=' 칼럼의 인덱스를 

사용하는 것이 보다 적은 일량으로 작업할 것이라고 판단한다. 하지만 실제로는 'BETWEEN' 칼럼을 사용한 인덱스가 보다 일량이 적을 수 있다.

§ 규칙기반의 단점을 극복하기 위해 출현한 비용기반 옵티마이저는 SQL문을 처리하는데 필요한 비용이 가장 적은 실행계획을 선택하는 방식이다.

§ 비용을 예측하기 위해 규칙기반 옵티마이저가 사용하지 않는 테이블, 인덱스, 칼럼 등의 다양한 객체 통계정보와 시스템 통계정보 등을 이용한다.

§ 정확한 통계정보를 유지하는 것이 비용기반 최적화에서 중요한 요소이다.

2. 실행계획

  • SQL에서 요구한 사항을 처리하기 위한 절차와 방법을 의미한다.

3. SQL 처리 흐름도

  • SQL 처리 흐름도 (ACCESS FLOW DIAGRAM)란 SQL의 내부적인 처리 절차를 시각적으로 표현한 도표이다.

3-2. 인덱스 기본

1. 인덱스 특징과 종류

  • 인덱스는 원하는 데이터를 쉽게 찾을 수 있도록 돕는 책의 찾아보기와 유사한 개념이다.

  • 인덱스의 기본적인 목적은 검색 성능의 최적화이다.

  • INSERT, UPDATE, DELETE 등과 같은 DML 작업은 테이블과 인덱스를 함께 변경해야 하기 때문에 오히려 느려질 수 있다는 단점이 존재한다.

  가. 트리 기반 인덱스

§ 가장 일반적인 인덱스이다.

§ 브랜치 블록은 분기를 목적으로 하는 블록이다.

§ 브랜치 블록은 다음 단계의 블록을 가리키는 포인터를 가지고 있다.

§ 리프 블록은 인덱스를 구성하는 칼럼의 데이터와 해당 데이터를 가지고 있는 행의 위치를 가리키는 레코드 식별자로 구성되어 있다.

§ 리프 블록은 양방향 링크(DOUBLE LINK)를 가지고 있다. 이것을 통해 오름차순과 내림차순 검색을 쉽게 할 수 있다.

§ '=' 로 검색하는 일치 검색과 'BETWEEN', '>' 등과 같은 연산자로 검색하는 범위 검색 모두에 적합한 구조이다.

1. 브랜치 블록의 가장 왼쪽 값이 찾고자 하는 값보다 작거나 같으면 왼쪽 포인터로 이동

2. 찾고자 하는 값이 브랜치 블록의 값 사이에 존재하면 가운데 포인터로 이동

3. 오른쪽에 있는 값보다 크면 오른쪽 포인터로 이동

• ORACLE에서 트리 기반 인덱스에는 B-트리 인덱스, 비트맵 인덱스, 리버스 키 인덱스, 함수기반 인덱스 등이 존재한다.

  나. SQL Server의 클러스터형 인덱스

• 인덱스의 리프 페이지가 곧 데이터 페이지다.

• 리프 페이지의 모든 로우(=데이터)는 인덱스 키 칼럼 순으로 물리적으로 정렬되어 저장된다.

2. 전체 테이블 스캔과 인덱스 스캔

  가. 전체 테이블 스캔

• 옵티마이저가 연산으로서 전체 테이블 스캔 방식을 선택하는 이유

1. SQL문에 조건이 존재하지 않는 경우

2. SQL문의 주어진 조건에 사용 가능한 인덱스가 존재하지 않는 경우

3. 옵티마이저의 취사 선택

4. 그 밖의 경우

  • 병렬처리 방식으로 처리하는 경우 또는 전체 테이블 스캔 방식의 힌트를 사용한 경우

  나. 인덱스 스캔

• 인덱스 스캔은 인덱스를 구성하는 칼럼의 값을 기반으로 데이터를 추출하는 방식이다.

• 인덱스 리프 블록은 인덱스 구성하는 칼럼과 레코드 식별자로 구성되어 있다.

• 인덱스의 리프 블록을 읽으면 인덱스 구성 칼럼의 값과 테이블의 레코드 식별자를 알 수 있다.

• 인덱스에 존재하지 않는 칼럼의 값이 필요한 경우에는 현재 읽은 레코드 식별자를 이용하여 테이블을 액세스 해야 한다.

• SQL문에 필요로 하는 모든 칼럼이 인덱스 구성 칼럼에 포함된 경우 테이블에 대한 액세스는 발생하지 않는다.

• 인덱스는 인덱스 구성 칼럼의 순서로 정렬되어 있다.

  1. 인덱스 유일 스캔 : 단 하나의 데이터를 추출하는 방식. 유일 인덱스는 중복을 허락하지 않는 인덱스이다. 인덱스 구성 칼럼에 모두 '='로 값이 주어지면 결과는 1건이 된다.

  2. 인덱스 범위 스캔 : 유일 인덱스의 구성 칼럼 모두에 대해 '='로 값이 주어지지 않은 경우와 인덱스 범위 스캔 방식으로 데이터를 액세스 하는 것이다.

  다. 전체 테이블 스캔과 인덱스 스캔 방식의 비교

§ 인덱스 스캔은 인덱스에 존재하는 레코드 식별자를 이용해서 데이터의 정확한 위치를 알고서 데이터를 읽는다. 따라서 한번의 I/O 요청에 한 블록씩 데이터를 읽는다.

§ 전체 테이블 스캔은 데이터를 읽을 때 한번의 I/O 요청으로 여러 블록을 한꺼번에 읽는다.

§ 대용량 데이터 중에서 극히 일부의 데이터를 찾을 때 인덱스 스캔 방식이 유리하다.

§ 하지만 반대로 테이블의 대부분의 데이터를 찾을 때는 한 블록씩 읽는 인덱스 스캔 방식보다 한번에 여러 블록씩 읽는 전체 테이블 스캔 방식이 유리할 수 있다.

출처 : SQL 전문가 가이드 교재