'(DB) Oracle/튜닝 및 조작'에 해당되는 글 7건

  1. 2017.01.22 Oracle - Lock걸린_자료조회
  2. 2017.01.22 Oracle - 여러 가지 조작
  3. 2017.01.22 Oracle - Lock List 보기 및 Lock 해제
  4. 2017.01.22 Oracle - DBA Scripts
  5. 2017.01.22 Oracle - Optimizer
  6. 2017.01.22 Oracle - HINT
  7. 2017.01.22 Oracle - Analyze

[ Oracle - Lock걸린_자료조회 ]

 

'(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 농부지기
,

[ Oracle - 여러 가지 조작 ]     

 

☞ tablespace 변경

 

alter table <TABLE> move tablespace <TABLESPACE>;
alter index <INDEX> rebuild tablespace <TABLESPACE>;


☞ table 변경

 

drop table (table_name) cascade constraints;


 

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

Oracle - Lock걸린_자료조회  (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 농부지기
,

[ Oracle - Lock List 보기 및 Lock 해제 ]     

 

☞ 참고

 

LOCK 해결방법 (ORA-00054 해결 방법)

 

☞ 방법1

 

1. Lock List 찾기
   SELECT B.USERNAME USERNAME, C.SID SID, C.OBJECT OBJECT,A.SQL_TEXT SQL
   FROM   V$SQLTEXT A, V$SESSION B,V$ACCESS C
   WHERE  A.ADDRESS    = B.SQL_ADDRESS
   AND    A.HASH_VALUE = B.SQL_HASH_VALUE
   AND    B.SID        = C.SID
   AND    C.OWNER      = 'USER ID' ;

2. Lock 삭제
   alter system kill session '150,101';   --세션ID, Serial#

☞ 방법2
 

1. Lock List 찾기
   select a.sid, a.serial#, b.type, c.object_nam
   from   V$session a, v$lock b, dba_objects c
   where  a.sid = b.sid
   and    b.id1 = c.object_id
   and    b.type = 'TM'
   and    c.object_name = 'FSFE1_STRACK_INFO'

2. Lock 삭제
   alter system kill session '150,101';   --세션ID, Serial#

 

☞ step

  STEP 1 : Lock 이 발생한 OBJECT 확인
SELECT object_id, object_type
    FROM dba_objects
  WHERE object_name='테이블 / 인덱스 이름';

STEP 2 : Lock 을 잡고 있는 세션 ID 확인
SELECT *
    FROM v$locked_object
  WHERE object_id='STEP1에서 검색한 object_id';

(오라클 사용자 이름과 세션 ID 를 기억해 둔다)

STEP 3 : Lock 을 잡고 있는 세션의 Serial 번호 확인
SELECT sid, serial#, command, taddr
    FROM v$session
  WHERE sid='STEP2의 세션 ID 번호';

STEP 4 : 세션 강제 종료
ALTER SYSTEM KILL SESSION '<세션 ID, Serial#>';

STEP 5 : 세션 종료 확인 및 Rollback 체크
SELECT used_ublk
    FROM v$transaction
  WHERE ADDR='<STEP3의 TADDR>';


 


 

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

Oracle - Lock걸린_자료조회  (0) 2017.01.22
Oracle - 여러 가지 조작  (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 농부지기
,

[ Oracle - DBA Scripts ]     

☞ DBA Scripts

 
Here are some of the scripts I use regularly. Some of them are not necessary when using Oracle Enterprise Manager (OEM), but if like me you hate waiting around for OEM to start up you'll often get the job done more quickly with these. Cheers Tim...

These scripts can be used by
easyscript for oracle and are available in the file oraclebase.esp produced by James Wang of Gudu Software.


10g...
active_session_waits.sql db_usage_hwm.sql dynamic_memory.sql
feature_usage.sql jobs.sql jobs_running.sql
job_classes.sql job_programs.sql job_schedules.sql
lock_tree.sql segment_advisor.sql services.sql
session_waits.sql windows.sql window_groups.sql

constraints...
disable_chk.sql disable_fk.sql disable_pk.sql
disable_ref_fk.sql enable_chk.sql enable_fk.sql
enable_pk.sql enable_ref_fk.sql

miscellaneous...
analyze_all.sql column_comments.sql comments.sql
compare_schemas.sql compile_all.sql compile_all_bodies.sql
compile_all_funcs.sql compile_all_procs.sql compile_all_specs.sql
compile_all_trigs.sql compile_all_views.sql conversion_api.sql
dict_comments.sql drop_all.sql dsp.pkb
dsp.pks err.pkb err.pks
ftp.pkb ftp.pks gen_health.sql
get_pivot.sql login.sql proc_defs.sql
rebuild_index.sql soap_api.sql string_agg.sql
string_api.sql switch_schema.sql table_comments.sql
table_defs.sql table_differences.sql trc.pkb
trc.pks

monitoring...
access.sql active_sessions.sql cache_hit_ratio.sql
call_stack.sql code_dep.sql code_dep_on.sql
column_defaults.sql db_cache_advice.sql db_info.sql
dispatchers.sql errors.sql error_stack.sql
explain.sql file_io.sql fks.sql
free_space.sql health.sql high_water_mark.sql
hot_blocks.sql index_extents.sql index_monitoring_status.sql
index_partitions.sql index_usage.sql invalid_objects.sql
jobs.sql jobs_running.sql latches.sql
latch_hit_ratios.sql latch_holders.sql library_cache.sql
license.sql locked_objects.sql longops.sql
lru_latch_ratio.sql max_extents.sql monitor.sql
monitoring_status.sql monitor_memory.sql non_indexed_fks.sql
object_status.sql obj_lock.sql open_cursors.sql
open_cursors_by_sid.sql open_cursors_full_by_sid.sql parameters.sql
parameter_diffs.sql pga_target_advice.sql pipes.sql
profiler_runs.sql profiler_run_details.sql rbs_extents.sql
rbs_stats.sql recovery_status.sql roles.sql
search_source.sql sessions.sql session_events.sql
session_events_by_sid.sql session_events_by_spid.sql session_io.sql
session_rollback.sql session_stats.sql session_waits.sql
show_space.sql source.sql spfile_parameters.sql
sql_area.sql sql_text.sql sql_text_by_sid.sql
system_events.sql system_parameters.sql system_stats.sql
table_dep.sql table_extents.sql table_indexes.sql
table_partitions.sql table_stats.sql temp_io.sql
temp_segments.sql top_latches.sql top_sessions.sql
top_sql.sql trace_runs.sql trace_run_details.sql
ts_extent_map.sql ts_full.sql tuning.sql
unusable_indexes.sql unused_space.sql user_hit_ratio.sql

rac...
locked_objects_rac.sql longops_rac.sql monitor_memory_rac.sql
sessions_rac.sql

resource manager...
active_plan.sql consumer_groups.sql consumer_group_usage.sql
plan_directives.sql resource_plans.sql

script creation...
backup.sql build_api.sql build_api2.sql
create_data.sql drop_cons_on_table.sql drop_fks_on_table.sql
drop_fks_ref_table.sql drop_indexes.sql fks_on_table.sql
fks_ref_table.sql index_monitoring_off.sql index_monitoring_on.sql
monitoring_off.sql monitoring_on.sql rbs_structure.sql
recreate_table.sql seq_structure.sql tablespace_structure.sql
table_constraints.sql table_indexes.sql table_structure.sql
view_structure.sql

security...
grant_delete.sql grant_execute.sql grant_insert.sql
grant_select.sql grant_update.sql package_synonyms.sql
sequence_synonyms.sql table_synonyms.sql view_synonyms.sql

 

 

 

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

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

[ 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 농부지기
    ,