농부지기

[ Oracle.튜닝-Index ]

1. index

    a. 많은 양의 페이지를 읽을 때

         - 본문을 처음부터 끝까지 쭉 읽는 것이 빠를 가능성이 높다.

    b. 적은 양의 페이지를 읽을 때

         1. Step

             색인을 뒤져서 페이지 번호를 찾는다.

         2. Step

             본문의 해당 페이지로 찾아 간다.

2. Index 분류

    a. B*Tree Index

    b. Bitmap Index

    c. Reverse Key Index

    d. Descending Index

    e. Function-based Index (FBI)

    f.  Domain indexes Index

3. B*Tree Index

    a. 구성요소

        . Root Block  -> Branch Blocks -> Leaf Blocks

    b. Root Block, Branch Blocks

        . 이 2개의 Block에는 data block에 접근하는 자료는 없다.

    c. Leaf Blocks

        . data block에 접근할 수 있는 rowid를 가지고 있다.

        . Leaf Node Block은 서로 양방향으로 연결되어 있다.

4. rowid

    a. 구성 : Object ID + File Number + Block Number + Row 위치 (Block내)

5. 결합인덱스

    a. 선행컬럼 선정순서

        1. 조건절에서 해당 컬럼이 항상 사용되는가

        2. 조건절에서 항상 '='로 사용되는가

        3. 컬럼의 분포도가 좋은가

        4. 정렬(sort)를 대신 할 수 있는가

        * 즉, index 컬럼 순서는 분포도 보다 '=' 검색이 더 우선 순위가 더 높다.

    b. 후행컬럼 선정기준

         1. 범위연산자로 조회되는 경우 (Between)

    c. 예제

         1. 만약, 급여테이블이 존재 할 때

             급여년월 + 사원번호 + 급여액   이라는 index가 존재 할 때 적절한지 파악해보면

             ; 급여년월은 주로 '=' 로 검색하고

             ; 사원번호, 급여액은 between 으로 검색하기에 적절하게 된다.

         2.

    c. 실행계획

        1. INDEX SKIP SCAN

            . A + B + C 에 대한 index가 존재 할 때

              where B = '12' AND C = '가가'; 로만 조건절에 적용시 11g 부터 적용될 실행계획임

            . 첫 번째 선행컬럼(A)의 데이터 분포도가 나쁘고 (고유한 값이 작고 중복된 값이 많은 경우)

            . 두 번재 선행컬럼(B)의 데이터 분포도가 좋은 경우 (고유값이 많고 중복이 적은 경우)

            . skip의 효과가 좋은 것이지, 모든 경우에 효율성이 좋은 것은 아님

6. 인덱스를 사용하지 못하는 경우

    a. 인덱스 사용이 비효율적인 경우

    b. 비교가 불가능한 경우

7. 인덱스와 힌트

    a. INDEX ~ 특정 인덱스를 사용하도록 유도하는 힌트

        . SELECT /*+ INDEX(emp_large EMP_IDX01) */ ..

    b. INDEX_ASC ~ 인덱스를 오름차순으로 접근하도록 하는 힌트

        . SELECT /*+ INDEX_ASC(emp_large EMP_PK) */ ..

    c. INDEX_DESC ~ 인덱스를 내림차순으로 접근하도록 하는 힌트

        . SELECT /*+ INDEX_DESC(emp_large EMP_PK) */ ..

8. Function-based Index (FBI)

    a. Index가 걸려 있는 컬럼에 계산식이나 함수가 사용되는 경우에는 Index를 사용할 수 없음

    b. FBI는 컬럼에 계산식이나 함수를 적용하여 자주 조회를 하는 경우에 사용가능

10. 용어

      a. 분포도가 좋다.

          . 고유한 값이 많다.

          . 데이터 처리 범위가 좁다.

          . 처리 일량이 적다

      b. 분포도가 나쁘다.

          . 중복된 값이 많다.

          . 데이터 처리 범위가 넓다

          . 처리 일량이 많다.

[ Oracle. 실행계획 - 자원통계정보 ]

1. Statistics

2. Recursive Call

    . 재귀호출이라고 해석 하며 Oracle DBMS가 사용자의 요청(sql)을 처리 하기 위하여

      내부적으로 사용한 DBMS Call(SQL)한 횟수

    . Trigger, 사용자정의 함수 호출(function), Hard Parsing등

3. DB Block Gets

    . 주로 DML 문장 실행에 필요해서 읽은 블록 수

4. Consistent Gets

    . 주로 Select문장 실행에 필요해서 읽은 블록 수

5. Physical Reads

    . 메모리에서가 아니라 DISK에서 읽은 블록 수

6. redo size

    . DML문장 실행 시 발생한 Redo Log Size

7. bytes snet via SQL*Net to client

    . Sql*Net을 통해서 보낸 Bytes수

8. bytes receieve via SQL*Net from client

    . Sql *Net을 통해서 받은 Bytes수

9. sorts(memory)

    . 메모리 내에서 발생한 sort 수

10. sorts(disk)

     . 디스크 내에서 발생한 sort 수

11. rows processed

      . 실행결과 출력된 row의 갯수

[ Oracle. 실행계획 - 기타연산자 ]

1. COUNT STOPKEY 연산자

    - sql > SELECT * FROM emp_large WHERE rownum < 10;

    - 실행계획

       ; 기본적으로 FULL TABLE SCAN을 하지만 조건절에 의해서 Stop하는 연산

2. FILTER 연산자

    - sql >SET AUTOTRACE TRACEONLY 

       sql >SELECT deptno, sum(sal) as total FROM emp_large

               WHERE job <> 'PRESIDENT'

               GROUP BY deptno

               HAVING sum(sal) > 6000;

    - 실행계획

       ; id 에서 HAVING절을 수행하기 위해서 FILTER연산자를 수행 했음.

[ Oracle. 실행계획 - JOIN ]

1. JOIN연산 종류

    1. Nested Loop Join

    2. Sort Merge Join

    3. Hash Join

2. Nested Loop Join

    - sql > SELECT /*+ USE_NL(emp_large, depart) */ dname, ename, job, sal

                  FROM emp_large a,  depart b

                WHERE a.deptno = b.deptno;

    - 실행계획

        ; NESTED LOOPS 수행방식

           . 2번 id를 먼저 수행 후 4,3 순서로 수행 됨

           . EMP_LARGE 에서 1건의 데이터를 읽어서 DEPART테이블에 접근하는 것을 반복하는 방식

             LOOP 라는 용어가 들어간 이유이다.

           . DEPART테이블을 하나씩 접근하므로 INDEX UNIQUE SCAN을 하게 된다.

    - 수행방법

        1. 조건절에 적용된 기준으로 emp_large테이블을 먼저 읽어서 SGA영역에 위치

        2. emp_large의 각 레코드 1개씩 depart 테이블과 join한다.

    - 특징

        1. 중첩된(Nested)Loop방식으로 처리되는 알고리즘

            (C언어나 기타 개발언어에서 종종 보던 중첩 Loop와 동일)

        2. 소량의 데이터 처리용

     - hine

         1. SELECT /*+ USE_NL(테이블1, 테이블2) */..

         2. SELECT /*+ ORDERED USE_NL(테이블1, 테이블2) */..

             . ORDERED란 FROM절에 기술된 테이블 순서대로 Nested Loop Join을 수행하라는 의미

3. Sort Merge Join

    - sql > SELECT /*+ USE_MERGE(emp_large, depart) */ dname, ename, job, sal

                  FROM emp_large a,  depart b

                WHERE a.deptno = b.deptno;

    - 실행계획

       ; id 2,4 각각 자료를 조회 후 정렬한 다음 join조건으로 JOIN을 하게 됨

         (depart는 index full scan이므로 정렬을 하지 않았음)

   - 특징

       . Sort merge Join을 할 때는 인덱스가 없어도 수행 될 수 있다.

       . Optimizer Mode가 ALL_ROWS인 경우에 자주 발생

       . Online 사용자에게는 부적합한 Join 알고리즘 임

       . Sort 연산에 많은 처리 비용이 발생

       . 대량의 데이터 처리용

4. Hash Join

    - sql > SELECT /*+ USE_HASH(emp_large, depart) */ dname, ename, job, sal

                  FROM emp_large a,  depart b

                WHERE a.deptno = b.deptno;

    - 실행계획

       참고) Sort merge Join에서는 full Table Scan을 수행한 후 Sort연산을 수행했었음.

       ; HASH JOIN

          . Sort Merge Join과 유사하게 접근하지만 Sort연산 대신 Hash 연산 사용

    - 장점

       . Sort Merge Join성능을 개선하려는 시도로 등장한 방법

    - 수행순서

       1. Sort 연산 후

       2. Merge 연산을 통해

       3. Join하는 방식

   - 특징

       . Sort Merge Join에 대한 성능 향상을 위해 7.3버전에 새로 등장한 알고리즘

       . '='연산자를 사용하는 경우에만 사용이 가능

       . Hash 함수와 Hash 테이블을 사용

          (Hash 함수 : 메모리상에 생성되는 데이터 집합)

       . Hash function : 데이터값 arg값으로 받아서 중복을 최소화한 고유한 주소 데이터를 생성함

       . Sort를 하지 않고도 대량의 데이터를 처리 할 수 있음.

9. 종합

    1. 전체 데이터 중 소량의 데이터를 Join으로 가져 올 때는 Sort Merge Join보다는

        Nested Loop Join이 효율적일 수 있다.

    2. OLTP성 트랙잭션 유형에는 Nested Loop Join이 어울린다.

    3. 배치성(DSS)성 트랜잭션 유형에는 Sort Merge Join/Hash Join이 어울린다.

    4. join처리 알고리즘

      5. Optimizer 실행계획 3단계

          . Query Transformation -> Query Optimization -> Generate Execution Plan