농부지기

[ 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

[ Oracle. 실행계획 ]

1. 참고

     . AUTOTRACE나 Explain Plan을 통해서 나타나는 실행계획은 예상실행계획이고

     . SQL Trace를 통해서 나타나는 실행계획은 실제실행계획이다.

2. Group by

    . 9i까지는 Group by 시 Group by 에 정의 컬럼기준으로 정렬이되어 조회 됨

    . 10g 부터는 Group by 를 해도 정렬되어 나오지 않음.

3. CBO, RBO

    . 실행계획 CBO로 나오는지 RBO로 나오는지 구분방법

    . RBO는 Row, Bytes, Cost,Time이 나오지 않음

      - 즉, 차이즘은 비용 유무.

4. Optimzer가 실행계획 수립시 참조하는 통계정보 2가지

    1. System 통계정보

        . CPU의 처리능력(Mhz),Disk I/O 처리능력에 대한 정보

        . System 통계정보가 실행계획을 결정하는데 미치는 영향력을 볼 수 없음

    2. Object 통계정보

        . 각 Object(Table, Index)에 대한 통계정보

        . Object 통계정보가 실행계획을 결정하는데 미치는 영향력을 볼 수 있음

5. Cost (%CPU)

    1. 비용 (Cost) = CPU Cost + IO Cost

    2. 위예제에서 : 633 의 비용 시 CPU Cost비중 2%

        (즉, Full Table Scan은 IO 집중(Intensive)적인 작업 이라는 의미)

6. 실행계획

    SET TIMING ON;  --SQL처리 응답속도 조회
    SET AUTORACE TRACEONLY;           --sql문장수행 및 실행계획을 보여줌
    SET AUTORACE TRACEONLY EXPLAIN;   --SQL문장은 수행하지 않고 실행계획만 보여줌
      
    SELECT EXECUTIONS, FETCHES, SQL_TEXT
      FROM V$SQL
     WHERE SQL_TEXT like '%sql내용%';
     --EXECUTIONS : SQL수행 횟수
     --FETCHES    :

[ Oracle.PL/SQL(Anonymous Block, Stored Block) ]

1. Anonymous Block

    . 실행시점에 해당 Block이 네트웤을 타고 DBMS에 전단됨

    . SQL 처리과정과 동일하게 Parsing과 Execute과정을 거침

2. Stored Block

    . DBMS 서버 내에 저장 됨

    . 처음 실행 시에는 Parsing된 상태로 저장되기 때문에 빠르다고 생각함.

3. 참고

    . Anonymous,Stored Block 의 성능은 동일함

3. 각 프로그램별 처리 시간

    . 40만건을 처리시 수행 시간

4. Stored Block을 사용한 예제

5. Subquery를 사용한 예제

[ Oracle SQL튜닝. Optimizer ]

1. Optimizer 개념

     - 최적화하기

     - 성능향상하기

     - Query Optimzer : 질의 최적화하기

2. Optimizer 종류

    a. RBO

        - 행동대장형 (조직폭력 단체)

        - Roles Base

        - 미리 정해진 고정된 15개의 규칙을 기반으로 판단

    b. CBO

        - CFO형 (기업)

        - 통계 기반

        - Data Dictionary들에 저장된 통계정보 기반 판단

3. RBO 15기지 규칙   

4. CBO - 통계정보 수집하기

    1. CBO 통계정보 > 지우기

        - ANALYZE  TABLE table_name  DELETE  STATISTIS;

    2. CBO 통계정보 > 전체 수집

        - Data가 많을 경우 시간이 오래 걸림

        - ANALYZE  TABLE table_name  COMPUTE  STATISTIS;

    3. CBO 통계정보 > 예측정보 수집

        - 대용량인 경우 estimate로만 수집해도 compute로 했던 정보와 거의 유사함

        - ANALYZE  TABLE table_name  ESTIMATE  STATISTIS;

5. CBO-통계정보 내역 보기

    1. 정의

        - 수집된 통계정보 내역 보기

    2. 테이블 정보

        SELECT * FROM USER_TABLES

        WHERE TABLE_NAME = 'table_name';

    3. 컬럼정보

        SELECT * FROM USER_TAB_COLUMNS

        WHERE TABLE_NAME = 'table_name';

    4. HISTOGRAM정보

        - 판매종류 컬럼에 히스토그램(Histogram)정보 수집

        - ANALYZE TABLE table_name COMPUTE STATISTICS FOR COLUMNS 판매종류;

        SELECT * FROM DBA_HISTOGRAMS

        WHERE TABLE_NAME = 'table_name' AND COLUM_NAME = '판매종류';

[ Oracle SQL튜닝. 성능튜닝 Tool ]

1. DESC PLAN_TABLE

2. DBA가 PLAN_TABLE만들기

    - 방법 1

      > CREATE PUBLIC SYNONYM PLAN_TABLE FOR SYSTEM.PLAN_TABLE;

    - 방법2

      > @C:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\utlxplan.sql

3. DBA가 모든사용자에게 권한부여

    > GRANT ALL ON PLAN_TABLE TO PUBLIC;

4. 성능Tool종류 4가지

     1. SQL Trace

     2. Explan Plan

     3. Autotrace

     4. DBMS_XPLAN

5. 성능 Tool 특징

    1. Explan Plan

         - 사용하기 번거로운 단점

    2. Autotrace

         - 편리한 Tool

          - SQL Trace보다 자유로움.

    3. SQL Trace

       - 필수적인 Tool

     4. DBMS_XPLAN

         -Oracle 9i이후 버전부터 지원 - 사용편리, 유용

6. Explan Plan

7. Autotrace

    a. Autotrace설치방법 (dba권한 필요)

        dba>@C:\oracle\product\10.2.0\db_1\RDBMS\ADMIN\plustrce.sql;

    b. Autotrace방법으로 실행계획보기

         sql>SET AUTOTRACE ON;

         sql>SELECT * FROM DUAL;

    c. Autotrace 수행결과 3가지 그룹

        1. SQL 실행결과

        2. SQL 실행계획과 Predicate Information

        3. SQL 실행 시 사용한 자원통계정보

8. SQL Trace

    a. Trace파일 생성

        ...

    b. 수행결과  3가지 그룹

        1. SQL문장

        2. SQL처리 단계별 자원사용량과 시간정보

        3. SQL 실행계획과 각 단계별 처리된 Rows수와 Logical ? Physical I/O 및 시간

    c. SQL처리 단계별 자원사용량과 시간정보

        1. count

            - DBMS Call을 의미하며 1개의 sql실행시 4번의 DBMS Call이 발생

        2. cpu

            - DBMS Call을 처리하기 위해 사용한 CPU시간

        3. elapsed

            -

        4. disk

            - sql을 처리하기 위해수행된 Physical Read한 Block의 개수

        5. query

            - Logical Read이며 주로 데이터 조회인 Select연산을 위해 읽어 들인 Block개수

        6. current

            - Logical Read이며 주로 데이터 수정인 DML연산을 위해 읽어 들인Block의 개수

        7. rows

            -

        8. Fetch . SELECT시 만들어진 결과 데이터를 Client에게 보내는 행위

                     . 1회 실행 시 1개의 Row를 가져오지만 Fetch회수가 2인 이유는 마지막 데이터를

                       읽은 후 다음 데이터의 존재 유무를 알기 위해 한번 더 Fetch를 하기 때문.

                     . 먄약, Fetch 10번이고, rows가 10,00이면

                       db는 was에 약(10,000/10) = 1,000건씩 전송했다는 의미

        9. Parse . Sort Parsing하지 않고, hard parsing할 경우 count가 1이 나옴

                      . Misses in library cache during parse과 동일한 숫자임

         a. Misses in library cache during parse

             . sql을 aprse하는 동안에 library cache안에서 Miss했다는 뜻.

               즉, Soft Parsing이 아닌 Hard Parsing했을 때 1 이라는 숫자가 조회됨

             . Parse결과절과 동일한 숫자임        

9. SPCPKG

    a. 설치

         sql>CONN SYS AS SYSDBA

         sql>@%ORACLE_HOME%\RDBMS\ADMIN\SPCREATE.SQL

    b. 설치확인

        탐색기 > @%ORACLE_HOME%\RDBMS\ADMIN\spcpkg.lis  파일 확인

    c. 보고서

        sql>conn perfstat    --perfstat : 설치시 id

         ....생략...

    d. 성능모니터링

        sql> conn perfstat/perfstat

        sql>execute statpack.snap;    --구간모니터링 시작

        .. 업무수행...

        sql>execute statpack.snap;    --구간모니터링 종료

10. 추가

     . AUTOTRACE나 Explain Plan을 통해서 나타나는 실행계획은 예상실행계획이고

     . SQL Trace를 통해서 나타나는 실행계획은 실제실행계획이다.

[ Oracle SQL튜닝. 접근경로(Access Path) ]

1. Access Path 종류

    a. Direct Access

    b. Indes Scan

    c. Full Table Sacn

1. Direct Access

    a. ROW_ID를 이용한 DATA 접근

2. Index Scan 세분화

    a. UNIQUE SCAN

         - 데이터를 1건 찾은 후 동일한 중복값이 있을 수 없기 때문에 검색을 바로 중지함

         - 예) unique index key가 존재하는 컬럼에 = (equal)조건일 경우

                 SELECT * FROM EMP_TABLE WHERE emp_no = 1234;

    b. RANGE  SCAN

        - Equal조건에 의한 Index Range Scan

          . 동일한값이 존재 할 수 있기 때문에 해당 조건에 1개 이상의 값을 리턴 할 수 있음.

          . 예) non unique index key가 존재하는 컬럼에 = (equal)조건일 경우

                SELECT * FROM EMP_TABLE WHERE emp_name = '강감찬';

    c. FULL SCAN
        - Index Fast Full Scan과 Index Full Scan이 존재

        - 인텍스 Block을 처음부터 끝까지 읽기

        - 예) SELECT /*+ USER_MERGE(emp_large, depart) */  dname, ename, job_sal

                   FROM emp_large a, depart b

                 WHERE a.deptno = b.deptno ;

    d. SKIP SCAN

    e. FAST FULL SCAN

ROWID : Pseudo Column(가상컬럼)
Soft Parsing : 기존 parsing된 sql실행계획을 기준으로 sql수행
Hard Parsing : 기존 parsing된 sql이 존재하지 않아 신규로 실행계획을 생성 후 sql수행
Select수행구조
  . Data Buffer Cache
  . Cache :
 
SQL 수행과정
  . Parsing -> Execute -> Fetch

Logical Read : 메모리상에서 읽는 것

                        Current + Query

Physical Read : 데이터파일을 읽는 것

                          DISK

 
Server Process
   . Dedicated Server Process : User Process와 1:1로 연결되는 방식
                                Default option
   . Shared Server Process    : 1개의 Server Process를 여러 User가 공유하는 방식
  
실행계획 보는 방법
  . EXPLAIN PLAN명령어
  . AUTOTRACE OPTION
  . SQL Trace & TKPROF

Parallel Process
  . 힌트 : /*+ PARALLEL(TABLE명, Process갯수) */

대량의 데이터 조회 시

  . Array Fetch 의 개념 필요

  . 부분범위 처리와 전체범위 처리 적절하게 사용해야 됨

      - 부분점위 처리 : 10만 row를 보여줘야 될 때 1만row씩 client에 전송하는 방식

      - 전체범위 처리 : 10만 row를 부여줘야 될 때 10만 row 전체는 한번에 client에 전송하는 방식