[ Oracle - Optimizer ]

 

☞ 개요

 

1. 종류
   Rule-based - SQL에 대한 Execution Plan이 여러 개 있다고 할 때, 가장 낮은 순위의 실행계획을
                항상 사용
   ost-based - SQL에 대한 Execution Plan이 여러 개 있다고 할 때, 가장 cost가 적은 실행계획을
               선택

2. Optimizer Mode 
   o Rule-Based Optimizer : 하나의 SQL에 대한 여러 개의 Execution Plan 가운데 가장 낮은 순위의
                            실행계획을 사용Cost-Based Optimizer : 하나의 SQL에 대한 여러 개의
                            Execution Plan 가운데 가장 cost가 적은 실행계획을 선택

   o 실행환경CHOOSE : Optimizer가 CBO와 RBO 두 가지가 모두 선택 가능할 경우에 사용
      - ALL_ROWS : CBO 환경경에서 전체적인 처리, 즉 Batch 환경에서 주로 사용
      - FIRST_ROWS : CBO 환경에서 빠른 응답시간을 얻고자 할 때, 즉 ON-LINE 환경에서 주로 사용
      - RULE : RBO 환경에서 사용


☞ 설명

  

⊙ Rule-Based Optimizer (규칙기반 최적화)RBO는 규칙에 의해설 실행되므로 예측가능하고 통제
   가능하므로 대부분의 DBA, 프로그래머들이 선호

   - RBO는 구문 중심으로, SQL 구문을 변경할 경우 성능이 향상될 수 있음(통계정보, 비용계산 
     비사용). 오직 규칙에 의해서만 실행계획을 결정

   - 테이블의 row수가 작어나 query가 일반적으로 row의 대부분을 반활할 때에도 가능하면,
     항상 인덱스를 사용함으로써 비효율적이 될 수도 있음. 테이블명에 대한 파싱은 우에서
     좌로 진행되기 때문에 최후 기술된 테이블이 먼저 처리

   - 순위표(규칙)
     1. 문장의 WHERE절에 ROWID나 Oracle Precompiler에 지원되는 확장된 SQL 구문 구조의
        CURRENT OF CURSOR에 의해 지정된 ROW들이 식별될 수 있을 경우에만 사용이 가능
     2. 문장의 WHERE 젤에 join이 단지 하나의 row를 return하는 것을 보증하는 조건절을 가지고
        있어야 함. 이러한 조건절은 unique하거나 primary key인 칼럼의 '=' 조건절과 유사함.
        이러한 조건들은 반드시 AND 연산자를 통해 합쳐져야 하고, 이러한 문장을 수행하기 위해
        Oracle은 nested loops 연산을 수행
     3. WHERE 절이 '='조건절에 HASH CLUSTER KEY의 모든 칼럼을 사용하여야 하며, 합섣된
        CLUSTER KEYS인 경우에는 '=' 조건졀이 반드시 AND 연산자에 의해 연결되어야 함.
        문장은 칼럼이 HASH CLUSTER KEY를 만들어 내듯이 UNIQUE나 PRIMARY KEY를 만들어내기
        때문에 단지 하나의 ROW만을 RETURN해야 함
     4. WHERE절이 '=' 조건절에서 칼럼들의 unique나 primary key를 사용할 경우에 사용
     5. 이 접근 경로는 두 Join 테이블이 같은 cluster에 저장되고, 문장의 Where절에 한 테이블의
        각 칼럼에 대해 대응하는 테이블의 칼럼을 같게 하는 조건절을 포함하는 경우 사용함.
     6. WHERE절에 hash cluster key인 칼럼의 '='조건절이 있을 경우에 사용
     7. WHERE절에 Index cluster key인 칼럼의 '='조건절이 있을 경우에 사용
     8. WHERE절에 결합 INDEX의 결럼이 있을 경우에 사용
     9. WHERE절에 single row index의 컬럼이 있을 경우에 사용
     10. index column이 bound range 된 것을 Where 조건에서 있을 경우에 사용
     11. index column이 unbound range 된 것을 Where조건에서 있을 경우에 사용
     12. where조건에 있는 컬럼들이 각각의 index로 구성되었을 경우에 사용
     13. MAX와 MIN함수의 argument는 칼럼, 상수, +연산자, ||연산자나 CONCAT함수 등을 포함하는
         어떠한 수식도 올 수 있음. 단, select 절에 다른 수식이 오지 않아야 하며 문장은
         WHERE절이나 GROUP BY절이 없어야 함.
     14. index의 컬럼이 order by절에서 이용할 경우에 사용
     15. 마지막으로 테이블 전체를 읽게 됨

⊙ Cost-Based Optimizer (비용기반 최적화)이론적으로 RBO에 비해 진보됨, 전문지식이 없어도
   악성계획의 회피 가능 
   - 논리적인 한계성이 존재, 원하는 경로로 유도하기 어려운 단점
   - 환경 설정 Parameter 
     1. Optimizer Mode = CHOOSE : 비용 기반 옵티마이저 환경을 의미 
     2. ALL_ROWS     : 비용 기반 옵티마이저 환경을 의미하며, SQL문의 WHERE 조건을
                       만족하는 모든 행을 가장 빠르게 검색하는 실행 계획을 결정함 
     3. FIRST_ROWS   : SQL문의 WHERE 조건을 만족하는 첫 번째 행을 가장 빠르게 검색하는
                       실행계획을 결정함 
     4. FIRST_ROWS_10    : ~~~ 10개 행을 
     5. FIRST_ROWS_100   : ~~~ 100개 행을 
     6. FIRST_ROWS_1000  : ~~~ 1000개 행을

  - 특징
     1. 좌에서 우로 파싱되므로 최초 기술된 테이블이 먼저 처리됨
     2. ANALYZE 명령은 과부하를 초래하기 때문에 항상 최선은 아님
     3.  CHOOSE Mode에서 SQL문에 포함된 테이블 중 어느 하나라도 이미 분석된 상태라면,
         그 SQL문은 기본적으로 CBO(비용기반 최적화)에 맞춰지게 됨

⊙ Optimizer Modes 설정 방법 
     - Optimizer Mode = ( CHOOSE, ALL_ROWS, FIRST_ROWS, RULE 
     - 시스템 전체에 지정하기 (instance level)
       * SQL> SET AUTOTRACE TRACE EXPLAIN
     - 세션에서 지정 (Seesion level)
       * ALTER SESSION SET OPTIMIZE_MODE = ( CHOOSEM ALL_ROWS, FIRST_ROWS, RULE )
     - SQL문장에서 지정 (Statement level)
       * SELECT /*+ (ALL_ROWS, FIRST_ROWS, RULE) * /
       * Hint를 사용하지 않는 경우 Session 혹은 System 전체에 정해진 Rule로 실행계획을
          생성한 상태

  •  
    • 논리적인 한계성이 존재, 원하는 경로로 유도하기 어려운 단점
    • 환경 설정 Parameter
      • Optimizer Mode = CHOOSE : 비용 기반 옵티마이저 환경을 의미
      • ALL_ROWS           : 비용 기반 옵티마이저 환경을 의미하며, SQL문의 WHERE 조건을 만족하는 모든 행을 가장 빠르게 검색하는 실행 계획을 결정함
      • FIRST_ROWS        : SQL문의 WHERE 조건을 만족하는 첫 번째 행을 가장 빠르게 검색하는 실행계획을 결정함
      • FIRST_ROWS_10    : ~~~ 10개 행을
      • FIRST_ROWS_100   : ~~~ 100개 행을
      • FIRST_ROWS_1000 : ~~~ 1000개 행을
    • 특징
      • 좌에서 우로 파싱되므로 최초 기술된 테이블이 먼저 처리됨
      • ANALYZE 명령은 과부하를 초래하기 때문에 항상 최선은 아님
      • CHOOSE Mode에서 SQL문에 포함된 테이블 중 어느 하나라도 이미 분석된 상태라면, 그 SQL문은 기본적으로 CBO(비용기반 최적화)에 맞춰지게 됨
  •  

    ☞ 옵티마이저를 이용한 SQL 튜닝

      

    인덱스 정보 이용법
       1. SELECT DISTINCT B.CLASS, COUNT(B.CLASS)  //DISTINCT는 아래의 GROUP BY에 의해 의미가 없음
          FROM COL A, COM B
          WHERE A.YEAR = B.YEAR
          AND A.HOUSE = B. HOUSE
          A.SERIAL_NO = B.SERIAL_NO
          A.AMT >=100
          B.DATE < '950501'
          B.CLASS IN('C', 'Y', 'I' ,'P')
          GROUP BY B.CLASS;

       2. CHOOSE Mode와 CBO
          
    조합된 테이블 중 어느 하나라도 이미 분석된 상태라면, 기본적으로 CBO로 작동함
          
    SELECT /** RULE **/ ROUND (NUV(SUM(C.REQR_QTY Z.MIN_COMP_QTY * ...
       3. 비용 기반 옵티마이저를 이용한 sql튜닝

          1. 아무런 인덱스가 없는 테이블 EMP의 znalyze 되기 전의 실행계획
          2. 테이블 emp만 analyze 되었을 경우의 실행계획
          3. 테이블 emp의 칼럼 deptno에 대해서 인덱스 생성시의 실행계획
          4. 테이블 emp의 칼럼 empno에 대해서 인덱스 생성시의 실행계획
             
     아무런 인덱스가 없는 테이블 EMP의 znalyze 되기 전의 실행계획
                 ▶ SELECT ename
                    FROM em
                    WHERE deptno = 20
                    AND empno BETWEEN 100 TO 200
                    ORDER BY ename;
                    Execution Plan
                    -----------------------------------------------------------------------
                    0          SELECT STATEMENT Optimizer = CHOOSE
                    1     0      SORT (ORDER BY)
                    2     1         TABLE ACCESS (FULL) of 'EMP'

                    현재는 아무런 인덱스가 없으며 분석되지 않았으며, 비용기반이 아님


             
    테이블 emp만 analyze 되었을 경우의 실행계획
                 ▶ SQL> ANALYZE TABLE emp COMPUTE STATISTICS;
                 ▶ 분석 이후 Cost, Card, Byte등이 출력됨. (Cost가 큰 수일수록 비효율적임)
              
    테이블 emp의 칼럼 deptno에 대해서 인덱스 생성시의 실행계획
                 ▶ SQL> CREATE INDEX EMP_DEMPTNO_IDX ON EMP(DEPTNO);
                 ▶ 초기의 COST보다 18이 줄은 값이 나옴
                 ▶ 인덱스 사용이 미사용보다 COST가 높았다면 인덱스를 사용하지 않았을 것임

     

     

    '(DB) Oracle > 튜닝 및 조작' 카테고리의 다른 글

    Oracle - 여러 가지 조작  (0) 2017.01.22
    Oracle - Lock List 보기 및 Lock 해제  (0) 2017.01.22
    Oracle - DBA Scripts  (0) 2017.01.22
    Oracle - HINT  (0) 2017.01.22
    Oracle - Analyze  (0) 2017.01.22
    Posted by 농부지기
    ,

    [ Oracle - HINT ]

     

     

     

    /*+ ALL_ROWS */
    explicitly chooses the cost-based approach to optimize a statement
    block with a goal of best throughput (that is, minimum
    total resource consumption) 

    전체 RESOURCE 소비를 최소화 시키기 위한 힌트.
                 Cost-Based 접근방식.


     


    /*+ CHOOSE */
    causes the optimizer to choose between the rule-based
    approach and the cost-based approach for a SQL statement
    based on the presence of statistics for the tables accessed by
    the statement 
                 Acess되는 테이블에 통계치 존재여부에 따라
                 Optimizer로 하여금 Rule-Based Approach와 Cost-Based Approach
                 중 하나를 선택할수 있게 한다.
                 Data Dictionary가 해당테이블에 대해 통계정보를 가지고 있다면
                 Optimizer는 Cost-Based Approach를 선택하고,
                 그렇지 않다면 Rule-Based Approach를 선택한다.



    /*+ FIRST_ROWS */
    explicitly chooses the cost-based approach to optimize a statement
    block with a goal of best response time (minimum
    resource usage to return first row)
    가장 좋은 응답 시간의 목표로 문 블록을 최적화하기 위해 cost-based 접근
    방법을 선택합니다. (첫번째 행을 되돌려 주는 최소의 자원 사용)

    /*+ RULE */
    explicitly chooses rule-based optimization for a statement
    block 
      Rule-Based 최적화를 사용하기위해.

    /*+ AND_EQUAL(table index) */
    explicitly chooses an execution plan that uses an access path
    that merges the scans on several single-column indexes 

     single-column index의 merge를 이용한 access path 선택.
                 적어도 두개이상의 index가 지정되어야한다.


    /*+ CLUSTER(table) */
    explicitly chooses a cluster scan to access the specified table 
      지정된 테이블Access에 Cluster Scan 유도.
                 Cluster된 Objects에만 적용가능.


    /*+ FULL(table) */
    explicitly chooses a full table scan for the specified table 
    해당테이블의 Full Table Scan을 유도.


    /*+ HASH(table) */
    explicitly chooses a hash scan to access the specified table 
    지정된 테이블Access에 HASH Scan 유도


    /*+ HASH_AJ(table) */
    transforms a NOT IN subquery into a hash antijoin to access
    the specified table 

    NOT IN SubQuery 를 HASH anti-join으로 변형


    /*+ HASH_SJ (table) */
    transforms a NOT IN subquery into a hash anti-join to access
    the specified table 

     correlated Exists SubQuery 를 HASH semi-join으로 변형



    /*+ INDEX(table index) */
    explicitly chooses an index scan for the specified table
    그 명시된 테이블을 위하여, 색인 scan을 고르는

    /*+ INDEX_ASC(table index) */
    explicitly chooses an ascending-range index scan for the specified
    table 

    INDEX HINT와 동일 단,ASCENDING 으로 SCAN함을 확실히 하기위함.



    /*+ INDEX_COMBINE(table index) */
    If no indexes are given as arguments for the INDEX_COMBINE
    hint, the optimizer uses whatever Boolean combination
    of bitmap indexes has the best cost estimate. If particular
    indexes are given as arguments, the optimizer tries to use
    some Boolean combination of those particular bitmap indexes. 

     INDEX명이 주어지지 않으면 OPTIMIZER는 해당 테이블의
                 best cost 로 선택된 Boolean combination index 를 사용한다.
                 index 명이 주어지면 주어진 특정 bitmap index 의
                 boolean combination 의 사용을 시도한다.



     



    /*+ INDEX_DESC(table index) */
    explicitly chooses a descending-range index scan for the specified
    table 
     지정된 테이블의 지정된 index를 이용 descending으로 scan
                 하고자할때 사용.


    /*+ INDEX_FFS(table index) */
    causes a fast full index scan to be performed rather than a full
    table scan 

     full table scan보다 빠른 full index scan을 유도.


    /*+ MERGE_AJ (table) */
    transforms a NOT IN subquery into a merge anti-join to access
    the specified table 

     not in subquery를 merge anti-join으로 변형



    /*+ MERGE_SJ (table) */
    transforms a correlated EXISTS subquery into a merge semi-join
    to access the specified table 

    correalted EXISTS subquery를 merge semi-join으로 변형



    /*+ ROWID(table) */
    explicitly chooses a table scan by ROWID for the specified
    table 

    지정된 테이블의 ROWID를 이용한 Scan 유도


    /*+ USE_CONCAT */
    forces combined OR conditions in the WHERE clause of a
    query to be transformed into a compound query using the
    UNION ALL set operator 

     조건절의 OR 를 Union ALL 형식으로 변형한다.
                 일반적으로 변형은 비용측면에서 효율적일때만 일어난다.




    /*+ ORDERED */
    causes Oracle to join tables in the order in which they appear
    in the FROM clause 

    from절에 기술된 테이블 순서대로 join이 일어나도록 유도.



    /*+ STAR */
    forces the large table to be joined last using a nested-loops join
    on the index 

     STAR QUERY PLAN이 사용가능하다면 이를 이용하기위한 HINT.
                 STAR PLAN은 규모가 가장큰 테이블이 QUERY에서 JOIN ORDER상
                 마지막으로 위치하게 하고 NESTED LOOP 으로 JOIN이 일어나도록
                 유도한다.
                 적어도 3개 테이블 이상이 조인에 참여해야하며 LARGE TABLE의
                 CONCATENATED INDEX는 최소 3컬럼 이상을 INDEX에 포함해야한다.
                 테이블이 ANALYZE 되어 있다면 OPTIMIZER가 가장효율적인 STAR PLAN을
                 선택한다.    





    /*+ DRIVING_SITE (table) */
    forces query execution to be done at a different site from that
    selected by Oracle 

    QUERY의 실행이 ORACLE에 의해 선택된 SITE가 아닌 다른 SITE에서
                 일어나도록 유도.


    /*+ USE_HASH (table) */
    causes Oracle to join each specified table with another row
    source with a hash join 

    각 테이블간 HASH JOIN이 일어나도록 유도.



    /*+ USE_MERGE (table) */
    causes Oracle to join each specified table with another row
    source with a sort-merge join 

    지정된 테이블들의 조인이 SORT-MERGE형식으로 일어나도록 유도.



    /*+ USE_NL (table) */
    causes Oracle to join each specified table to another row
    source with a nested-loops join using the specified table as the
    inner table 

    테이블의 JOIN 시 테이블의 각 ROW가 INNER 테이블을 NESTED LOOP
                 형식으로 JOIN 한다.

    .



    /*+ APPEND */ , /*+ NOAPPEND */
    specifies that data is simply appended (or not) to a table; existing
    free space is not used. Use these hints only following the
    INSERT keyword.
    데이타가 테이블로 단순히 덧붙여진다는 (or not)것 명시합니다; 무료인
    현존하는 영역은 사용되지 않습니다.
    단지 그 삽입 키 핵심어를 따르는 이 암시를 사용하시오.

    /*+ NOPARALLEL(table) */
    disables parallel scanning of a table, even if the table was created
    with a PARALLEL clause
    그 테이블이 PARALLEL 문절로 새로 만들어졌다면 테이블의 평행  순차 검색을
    사용하지 않게 함


    /*+ PARALLEL(table, instances) */
    allows you to specify the desired number of concurrent slave
    processes that can be used for the operation.
    DELETE, INSERT, and UPDATE operations are considered for
    parallelization only if the session is in a PARALLEL DML
    enabled mode. (Use ALTER SESSION PARALLEL DML to
    enter this mode.)
    PARALLEL hint를 사용하면 query에 포함된 table의 degree를 설정할 수 있다.
    예를 들어, 다음과 같이 hint를 적어 degree 4로 parallel query option을
    실행하도록 할 수 있다.
    이 때 parallel이란 글자와 괄호( '(' )사이에 blank를 넣지 않도록 한다.
    select /*+ PARALLEL(emp, 4) */ * from emp; 
     
     

    /*+ PARALLEL_INDEX
    allows you to parallelize fast full index scan for partitioned
    and nonpartitioned indexes that have the PARALLEL attribute
    parallelize에 당신에게 빠른 가득한 색인 scan을 허락합니다. 그런데,
    그것은 PARALLEL 속성을 가지고 있는 색인을 분할했고 nonpartitioned했습니다.

    /*+ NOPARALLEL_INDEX */
    overrides a PARALLEL attribute setting on an index
    병렬이 색인을 나아가는 것을 속하게 하는 대체


    /*+ CACHE */
    specifies that the blocks retrieved for the table in the hint are
    placed at the most recently used end of the LRU list in the
    buffer cache when a full table scan is performed
    그 블록이 찾아서 가져왔다는 것을 명시합니다. 그리고 그 테이블을 위해
    그 암시에 놓여집니다. 그런데, 그것은 가장 요즈음 사용된 언제 그 버퍼 캐쉬,
    가득한 테이블 scan에 있는 LRU 리스트의 끝입니다. 수행됩니다.

    /*+ NOCACHE */
    specifies that the blocks retrieved for this table are placed at
    the least recently used end of the LRU list in the buffer cache
    when a full table scan is performed
    그 명시합니다. 그리고, 그 블록은 이 테이블을 위해 검색되면서 요즈음 사용된
    언제 그 버퍼 캐쉬, 가득한 테이블 scan에 있는 LRU 리스트의 가장 작은 끝에
    놓여집니다. 수행됩니다.

    /*+ MERGE (table) */
    causes Oracle to evaluate complex views or subqueries before
    the surrounding query
    오라클이 그 둘러싸는 질의 전에 복잡한 뷰나 부속 조회를 평가하게 합니다.

    /*+ NO_MERGE (table) */
    causes Oracle not to merge mergeable views
    오라클이 mergeable 뷰를 합병하지 않게 하지 않습니다

    /*+ PUSH_JOIN_PRED (table) */
    causes the optimizer to evaluate, on a cost basis, whether or
    not to push individual join predicates into the view
    개개 접합을 미는 것이 그 뷰 안으로 단정 하든 간에 비용 방식으로 최적자가
    평가하게 합니다.

    /*+ NO_PUSH_JOIN_PRED (table) */
    Prevents pushing of a join predicate into the view
    접합 술부 중에서 그 뷰로 밀면서, 막는

    /*+ PUSH_SUBQ */
    causes nonmerged subqueries to be evaluated at the earliest
    possible place in the execution plan
    원인은 그 실행 계획에서의 가장 이른 가능한 장소에 평가되는 부속 조회를
    nonmerged했습니다.

    /*+ STAR_TRANSFORMATION */
    makes the optimizer use the best plan in which the transformation
    has been used.
    최적자가 그 변형이 사용된 가장 좋은 계획을 사용하는 제작 

    [출처] ORACLE HINT 정리|작성자 다나끔

     

    '(DB) Oracle > 튜닝 및 조작' 카테고리의 다른 글

    Oracle - 여러 가지 조작  (0) 2017.01.22
    Oracle - Lock List 보기 및 Lock 해제  (0) 2017.01.22
    Oracle - DBA Scripts  (0) 2017.01.22
    Oracle - Optimizer  (0) 2017.01.22
    Oracle - Analyze  (0) 2017.01.22
    Posted by 농부지기
    ,

    [ Oracle - Analyze  ]

     

    ☞ 정의 : SQL은 RULE-BASED나 COST-BASED중 하나를 이용해서 기동된다.기존의 소프트웨어는 RULE
              BASED 방식을 채택하고 있다. 그리고 많은 오라클 소프트웨어가 이러한 방식을 오랫동안
              사용해 왔다.
              그러나 새로 출시된 소프트웨어에 대해서는 COST BASED 방식의 OPTIMIZER를 고려해야 한다.
              오라클은 새로 출시되는 프로그램을 COST BASED방식으로 업그레이드 시켜왔으며 이러한
              방식은 시스템을 훨씬 더 안정적으로 만들었다. 만약 COST BASED방식의 OPTIMIZER를
              사용한다면 반드시 ANALYZE 스키마를 정기적으로 사용해야 한다. ANALYZE스키마는
              데이터베이스 통계를 데이터 사전 테이블에 기록하는 역할을 수행하며 그렇게 되면
              COST BASED OPTIMIZER가 그것을 사용하게 된다.

    1. ANALYZE

     

    - ANALYZE는 인덱스, 테이블, 클러스터의 통계정보를 생성 합니다.

    - ANALYZE가 생성한 통계정보들은 비용기준(Cost-based)의 옵티마이저가 가장 효율적인
      실행계획을  수립하기 위해 최소비용을 계산할 때 사용 됩니다.

    - 각 오브젝트의 구조를 확인하는 것과 체인(Chain) 생성 여부를 확인할 수 있으므로
      시스템의 저장공간 관리를 도와줍니다.  


    2. ANALYZE 문법

     

    ANALYZE   object-clause operation   STATISTICS
            [
    VALIDATE  STRUCTURE[CASCADE]]
            [
    LIST CHAINED  ROWS [INTO tables
    ]]

    - object-clause : TABLE, INDEX, CLUSTER중에서 해당하는 오브젝트를 기술하고 처리할
                      오브젝트 명을 기술 합니다.
    - operation     : operation 옵션에는 다음 3가지중 한가지 기능을 선택할 수 있습니다.
      ◎ COMPUTE
           - 각각의 값들을 정확하게 계산 합니다.
           - 가장 정확한 통계를 얻을 수 있지만 처리 속도가 가장 느립니다.

      ◎ ESTIMATE
           - 자료사전의 값과 데이터 견본을 가지고 검사해서 통계를 예상합니다.
           - COMPUTE보다 덜 정확하지만 처리속도가 훨씬 빠릅니다.  

      ◎ DELETE
           - 테이블의 모든 통계 정보를 삭제 합니다.


    3. ANALYZE 생성 통계정보(데이터 사전)

     

    1. 테이블 : 총 로우의수, 총 블럭의 수, 비어있는 블럭에 쓰여질 수 있는 빈 공간의 평균,
                체인이 발생된 로우의 수, 로우의 평균 길이

    2. 인덱스 : 인덱스의 깊이(Depth), Leaf block의 개수, Distinct Key의 수,
                Leaf Blocks/Key의 평균, Data blocks/key의 평균,
                Clustering Factor, 가장 큰 key 값, 가장 작은 key 값

    3. 컬럼 : Distinct한 값의 수, 히스토그램 정보

    4. 클러스터 : Cluster Key당 길이의 평균


    4. ANALYZE 수행주기

      1. 주기적인 ANALYZE 작업을 수행 시켜 주어야 합니다.

    2. 테이블을 재생성 하거나, 새로 클러스터링을 한 경우, 인덱스를 추가하거나 재생성한 경우,
        다량의 데이터를 SQL이나 배치 애플리케이션을 통해 작업한 경우 ANALYZE를
       수행 시켜 주는 것이 좋습니다.

    3. 사용자는  USER_TABLES, USER_COLUMNS, USER_INDEXS, USER_CLUSTER 등의
        자료사전 뷰를 통해 정보를 확인할 수 있습니다  

    4. 테이블을 ANALYZE 시킨다면 거기에 따르는 인덱스들도 같이 실시하는 것이 좋습니다.

    5. ANALYZE 사용예

     

    ☞ 테이블 정보수집 예제
       SQL>
    ANALYZE TABLE  emplyee COMPUTE STATISTICS ;

    ☞ 테이블 수집정보 삭제
       SQL> A
    NALYZE TABLE  emplyee DELETE STATISTICS;

    ☞ 특정 컬럼에 대한 data 분포
        SQL>A
    NALYZE TABLE emplyee COMPUTE STATISTICS FOR ALL INDEXED COLUMNS
    ;


    6. ANALYZE 통계정보의 확인

      SQL>SELECT num_rows, blocks, empty_blocks, avg_space, chain_cnt, avg_row_len,            sample_size, last_analyzed
        
    FROM   USER_TABLES
        
    WHERE  table_name='CMS_CATEGORY';

    SQL>
    SELECT num_distinct, density, low_value, high_value, last_analyzed,column_name
        
    FROM   USER_TAB_COL_STATISTICS
        
    WHERE
     table_name='CMS_CATEGORY'


      

    '(DB) Oracle > 튜닝 및 조작' 카테고리의 다른 글

    Oracle - 여러 가지 조작  (0) 2017.01.22
    Oracle - Lock List 보기 및 Lock 해제  (0) 2017.01.22
    Oracle - DBA Scripts  (0) 2017.01.22
    Oracle - Optimizer  (0) 2017.01.22
    Oracle - HINT  (0) 2017.01.22
    Posted by 농부지기
    ,