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

    [ Oracle - web에서 sql  plus 실행방법 ]

     

    1. 방법 : http://localhost:7778/isqlplus

    '(DB) Oracle > SQL_PLUS' 카테고리의 다른 글

    Oracle - 파일안에 있는 SQL문 실행방법  (0) 2017.01.22
    Posted by 농부지기
    ,

    [ 파일안에 있는 SQL문 실행방법 ]

     

    1. 정의 : sql plus에서 hard내부에 있는 파일안에 있는 sql문을 실행하는 방법

    2. 방법 - 해당 파일이 있는 곳에서 sql plus실행

                 - @file_name

                   실행됨

    3. 참고 : file 안에 있는 sql 문은 DDL, DML 모두 가능한다.

     

    ----------------------------------------------------------------------------

     

    1. 정의 : UNIX에서 실행결과를 spool하고 싶을 경우

    2. 파일내용 :  (emp_select.sql)

                     spool test.dat

     

                     select * from emp;

     

                     spool off

     

    3. 실행방법

        SQL> emp_select.sql

     

    '(DB) Oracle > SQL_PLUS' 카테고리의 다른 글

    Oracle - web에서 sql plus 실행방법  (0) 2017.01.22
    Posted by 농부지기
    ,

    [ Oracle - SQL TRACE ]

     

    ☞ SQL TRACE

     

    1. 정의 : SQL TRACE의 기능을 사용하면 개개의 SQL 문 실행시 실행과정의 및 결과등의 통계 정보를
              트레이스.파일에 출력한다. 이 결과를 모니터링하여 SQL튜닝을 실시해야 할 곳을 발견할
              수 있다.

    2. 단점 : SQL TRACE를 하게 되면 속도가 느려 지므로 필요시에만  상태를 True로 하고 사용하지 않을
              경에는 False로 한다.   

    ☞ SQL TRACE 시작 /종료 OPTION
     

    ■ 현재Session 만을 변경 
      SQL> alter session set timed_statistics=true;  --(CPU 시간을 알고 싶을 경우에 실행)
      SQL> alter session set sql_trace = true;
      SQL> select ... (SQL문 처리의 실행)
      SQL> alter session set sql_trace = false;
      SQL> exit

    ■ 임의Session을 변경
        SQL> alter session set timed_statistics=true; 
        SQL> EXEC DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(sid, serial#, TRUE);
     
        SQL> select ... (처리의 실행)
        SQL> EXEC DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(sid, serial#, FALSE);

    ■ 인스턴스 전체를 변경
      init.ora ->
      timed_statistics=true
      sql_trace_true
      user_dump_dest ...

      RESTART INSTANCE

      여기서 초기화 파라미터 USER_DUMP_DEST(udump)에 트레이스·파일이 작성 된다.
      해당 트레이스·파일은 작성된 타임 스탬프로 확인한다.

      이 SQL 트레이스·파일은 SQL문 실행시에 순서대로 정보가 써지므로 이 파일을 보고 SQL문을
      분석하는 것은 곤란하다. 다음의 2.에서 소개하는 TKPROF라고 하는 유틸리티를 사용해 
      SQL 트레이스·파일을 정형하는 것으로 튜닝을 위한 분석을 실시하기 쉽게 한다.

    2. TKPROF의 실행 방법
         - TKPROF로 SQL 트레이스를 포맷 해 보기 쉽게 한다

    상기로 취득한 SQL 트레이스에 대해 TKPROF 커멘드를 실행하면 SQL 트레이스가  알기 쉽게 포맷 됩니다.

    % tkprof <상기로 작성된 트레이스·파일> <임의의 파일명>
      (예: % tkprof oracle_ora_8138.trc tkprof.txt)

    ※ TKPROF 커멘드에는 많은 옵션이 있습니다.자세한 것은 Oracle8 or Oracle8i 「퍼포먼스를 위한 설계 및 튜닝」또는 Oracle9i  「데이타베이스·퍼포먼스·가이드 및 레퍼런스」의 "SQL 트레이스 기능과 TKPROF의 사용 방법" - 순서 3:TKPROF에 의한 트레이스·파일의 포맷을 참조.

    3. 통계 정보를 해석한다
       - TKPROF 실행 후의 트레이스·파일의 대략적인 견해(처리에 걸린 시간) 

    ☞ SQL TRACE시 취득 정보

     

    ◆ Parse
       - SQL문이 파싱되는 단계에 대한 통계
       - 새로 파싱을 했거나, 공유 풀에서 찾아 온 것도 포함됨.
       - 단, PL/SQL 내에서 반복 수행(Loop)된 SQL이나 PL*SQL에서 보존 커서(Hold cursor)를 지정한
         경우에는 한 번만 파싱됨.

    ◆ Execute
       - SQL문의 실행단계에 대한 통계임.
       - UPDATE, INSERT, DELETE 문들은 여기에 수행한 결과가 나타나게 됨.
       - 전체범위 방식으로 처리된 결과가 여러 건인 경우는 주로 여기에 많은 값이 나타나며
         Fetch에는 아주 적은 값이 나타남.

    ◆ Fetch
       - SQL문이 실행되면서 Fetch된 통계임. 
       - 부분범위 방식으로 처리된 SELECT 문들이나 전체범위 처리를 한 후 한 건을 추출하는 경우        (AGGREGATE, 전체집계, COUNT 등)는 주로 여리게 많은 값들이 나타나고 EXECUTE에는 아주
         적은 값이 나타남.

    ◆ COUNT
       - SQL문이 파싱된 횟수, 실행된 횟수, FETCH가 수행된 횟수

    ◆ CPU
       - PARSE, EXECUTE, FETCH가 실제로 사용한 CPU 시간(1/100초 단위)

    ◆ ELAPSED
       - 작업의 시작에서 종료시까지 실제 소요된 총 시간

    DISK
       - 디스크에서 읽혀진 데이타 블록의 수

    QUERY
       - 메모리 내에서 변경되지 않은 블록을 읽거나 다른 세션에 의해 변경되었으나 아직 Commit되지
         않아 복사해 둔 스냅샷 블록을 읽은 블록의 수
       - SELECT 문에서는 거의가 여기에 해당하며 UPDATE, DELETE, INSERT시에는 소량만 발생됨.

    CURRENT
       - 현 세션에서 작업한 내용을 Commit하지 않아 오로지 자신에게만 유효한 블록(Dirty Block)을
         액세스한 블록 수
       - 주로 UPDATE, INSERT, DELETE 작업시 많이 발생
       - SELECT문에서는 거의 없으나 아주 적은 양인 경우가 대부분임.

    Logical I/O : QUERY + CURRENT

    ROWS
       - SQL문을 수행한 결과에 의해 최종적으로 액세스된 ROW의 수
        - 서브쿼리
    에 의해서 추출된 ROW는 제외됨.
       - 만약 SUM, AVG, MIN, COUNT 등의 그룹함수를 사용한 경우라면 큰 의미가 없음.

    ▣ 재귀적 콜(RECURSIVE CALL)이란:
       유저가 발행한 SQL문을 실행하기 위해서 Oracle는 추가의 문장을 발행해야만 하는 경우가 있다.
       이러한 문장을 재귀적 콜 또는 재귀적 SQL문 이라고 한다. 예를 들어 충분한 공간이 없는 테이블에
       행을 삽입하려고 하면, Oracle는 재귀적 콜을 실행해 동적으로 공간을 할당한다. SQL 트레이스
       기능이 사용 가능으로 되어 있을 때 재귀적 콜이 발생하면 TKPROF는 재귀적 콜의 원인이 된
       문장에 대해 재귀적 SQL문의 통계를 표시한다.

    ▣ 재귀적 콜의 분별법:
       TKPROF로 출력되고 있는 SQL문이 재귀적 SQL문인가 그렇지 않은가는 각 SQL문의 최후의 「
       recursive depth」정보로 판단한다. 이 값이 1이상의 경우, 그 SQL문은 재귀적 SQL문으로서의
       통계 정보가 된다.

    「recursive depth」(이하, DEPTH)은, SQL 문이 발행된 재귀 레벨을 나타낸다. 예를 들어 값 0 은
        유저가 그 문장을 발행한 것을 나타내 보인다. 값 1은 Oracle이 값0의 문장(유저 발행의 문장)을
        처리하는 재귀적 콜로서 그 문장을 생성했다란 것을 나타낸다.값n 는 Oracle 가 그 문장을 값 n-1
        의 문장을 처리하는 재귀적 콜로서 생성한 것을 나타낸다.
        주의:내부표에 대한 처리만이 재귀적 SQL문이 되는 것은 아니다.

        PL/SQL 블록으로
          스토어드·프로그램(패키지, 프로시저, 팬쿠션등)을 부르는 처리를 실시했을 경우
          스토어드·프로그램 안에서 실행되는 SQL문은 SELECT나 UPDATE여도 재귀적 SQL문
                     으로 간주해져 재귀적 SQL문의 통계 정보로서 출력됩니다.

    전체의 통계 정보에 대해:
    전체의 처리에 걸린 통계 정보는 트레이스·파일의 마지막에 출력되고 있다

          OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
          OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

    란 통계 정보로 확인한다.
    OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS = 비재귀적 SQL문의 통계 정보의 합계
    OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS = 재귀적 SQL문의 통계 정보의 합계

        처리 전체에 걸린 시간은 이 양자를 합계한 시간이 된다.
        (※ SQL 트레이스를 취득할 때에 초기화 파라미터 timed_statistics를 TRUE로 하고 있지 않은
            경우 에는 처리 시간은 항상 0.00이 된다.



    ☞ ORANGE TOOL에서 SQL TRACE하기

      [단, Oracle이  windows에 설치 되었을 경우의 설명]
    1. ORANGE 로 Oracle접속
    2. 메뉴 : Tools -> Plan Tool 선택
    3. 메뉴 : Tools -> Trace Method -> Local File
                (참고, Plan Tool창을 띄워야  Trace 메뉴가 추가 됨)
    4. POP_UP창에서 : Trace  file 위치를 [ \oracle\admin\sid\udump ] 로하고
                                Trace Name Format은 [ sid_ora_%d.trc ] 로 한다.   
    5. 다시 Plan Tool 창으로 온다.
    6. Trace를 하고 싶은 SQL 문을 KEY IN 한다.
    7. ORANGE의 왼쪽에 상단에 TRACE  Icon       을 클릭 한다.
    8. Plan Tool 창  하단 TRACE Tab page에서 Trace 내용이 출력 된다.

    ☞  ORANGE TOOL에서 SQL TRACE 결과 보기
     

    1. SQL문을 KEY IN 후 처음 TRACE를 할 경우
        (아래 결과는  
           - Oracle이  Local PC인  windows XP에 설치 되었다.
           - TABLE FULLSCAN 이다
           - Record 갯수가  334개 결과가 나오는 SQL문장의 TRACE결과이다
         

     

     

    2. SQL문을 KEY IN 후 두 번째 부터의 TRACE결과
         

     

     

     

    '(DB) Oracle > Object & Utility' 카테고리의 다른 글

    Oracle - Data Pump Export / Import 1편  (0) 2017.01.22
    Oracle - 데이터 펌프 (Data Pump) expdp, impdp  (0) 2017.01.22
    Oracle - Listener_EM Console  (0) 2017.01.21
    Oracle - Pro*C  (0) 2017.01.21
    Oracle - Recovery - Point in Time  (0) 2017.01.21
    Posted by 농부지기
    ,

    Dangtong 의 오라클 <Data Pump Export / Import 1편>

     

    dangtong76님의 블로그 | 당통
    http://blog.naver.com/dangtong76/140042693346

     

    우리가 데이터 베이스 내에 있는 정보들을 운영체제 파일 시스템으로 옮기거나 혹은 그 반대

    의 경우를 위해 사용해 오던 것이  export/import 였다면 ,오라클 Data Pump 는 우리가 사용

     오던 export/import 의 기능에 다양하고 강력한 기능들을 추가 한 것입니다.  

    오라클 10g 에서는 export/import와 Data Pump export/import 두 가지 기능을 모두를 지원

    하고 있지만, Data Pump import/export 를 알고난 후 에는 더 이상 기존에

    사용해오던 export/import 를 사용하실 필요성을 느끼지 못하게 되실 겁니다.  왜냐구요?

    그만큼 강력한 기능을 제공한답니다.  자 그럼 Data Pump 의 세계로 들어가 볼까요?

    ※잠깐만~~!!

    Export/Import와 Data pump는 서로 호환되지 않습니다. 즉 Export유틸리티를 이용하여 백업 받은 파일을 Data pump 를 이용하여 Import할 수 없으며, 마찬가지로 Data Pump 를 통해 Export 된 데이터는 Export/Import 유틸리티를 통해 Import할 수 없습니다.

     

     

     

    1. Data Pump export/import 의 잇점

       Data Pump export/import 를 사용함으로서 얻을 수 있는 잇점은 다음과 같습니다.  

        1) JOB 콘트롤 가능

        Interactive mode 를 통하여 Data Pump 작업을 통제 할 수 있습니다. 작업을 중단시키고

        재시작 할 수 있으며 동적으로 dump file 을 할당 할 수 있습니다. 에러가 나더라도 작업

        이 중지 될 뿐 언제든지 원인을 수정하고 재수행 할 수 있습니다.

        2) 병렬수행지원

        PARALLEL 파라메타 를 이용하여 프로세스의 Data Pump 작업의 프로세스를 병렬화 할수

        있습니다. 병렬화 된 프로세스는 여러게의 데이타 파일에 각각 데이터를 쓰거나 여러

        개의 데이터 파일로 부터 데이터를 읽어 데이터베이스에 저장합니다. 병렬 수행이 가능

        함으로써 이전 보다 훨씬 강력한 수행 속도를 보장합니다.

        3) 작업에 필요한 디스크공간을 미리 예상

        ESTIMATE 파라메타를 이용하여 작업 시작 전에 필요한 물리적인 디스크 공간을 예상 할

        수 있습니다.

        4) 원격지 수행

        DB LINK를 통하여 원격지 데이터에 대한 Data Pump Import/Export 를 수행 할 수 있습

        니다.

        5) Remapping 지원

        유저 스키마, 테이블 스페이스, 데이터파일 등과 같은 정보들의 Data Pump Import/

        Export 시에 변경 할 수 있습니다. 이러한 기능은 데이터 마이그레이션 시에 보다 많

        은 유연성을 제공하는데 큰 역할을 합니다.

    2. Data Access Methods

        1) Direct-path

        메모리를 거의 사용하지 않고 파일에 direct 로 쓰게 되는 방법입니다. 메모리

        사용이 적고 속도가 빠르며, 데이터 컨버전에 시간이 걸리지 않습니다.

        2) External tables

        메타 데이터를 데이터베이스에 저장하고 데이터 는 파일시스템에 존재하게 함으로써

        대용량 데이터를 Export/Import 할 때 사용합니다.

        이두가지 모드는 오라클이 자동으로 판단하여 수행하게 됩니다.

    ※잠깐만~~!!!

    Direct-path 가 되지 않는 경우

    . 클러스터 테이블인 경우

    . 테이블에 활성화된 트리거가 존재 할 경우

    . 글로벌 인덱스를 가진 테이블이 하나의 파티션에 존재 할 경우

    . LOB 칼럼 에 있는 도메인 인덱스

    . insert 모드에서 fine-grained access control 이 enable 인 경우

    . BFILE 을 가진 테이블 인 경우

     

     

     

     

     

     

     

     

     

     

     

     

    External Table이란?

    . Create TABLE ~~ ORGANIZATION EXTERNAL 문을 통해 만들어진 테이블입니다.

    . 실질적인 데이터는 데이터 베이스 내에 존재하는 것이 아니라 물리적 디스크에 논리

      적 공간을 할당 받아 데이터를 저장하며, 파일형태로 존재합니다.

    . 저장되는 데이터는 READ ONLY 데이터 이며 인덱스를 생성할 수 없습니다.

    . DML 작업을 수행할 수 없습니다.

    . MEAT-DATA in DATABASE, DATA in OS 라고 압축 설명 할 수 있습니다.

     

     

     

     

     

     

     

     

    3. Data Pump의 권한 설정

        좀더 다양한 옵션과 Data Pump 의 모든 기능을 자유자재로 사용하고

        자 한다면, 시스템에 설정된 EXP_FULL_DATABASE, IMP_FULL_DATABASE 롤을 부여 함으로써

        가능합니다. 일단 다음과 같이 유저를 생성하고 두 권한 모두를 생성된 사용자에 게 주는

        실습을 해 보도록 합시다.

        1) 사용자 생성

           create user dangtong identified by imsi00

           default tablespace USERS

           temporary tablespace temp;

        2) 권한부여

           grant connect, resource to dangtong;

        3) 모든 테이블에 대한 select 권한 부여

           grant select any table to dangtong;

        4) EXP_FULL_DATABASE,IMP_FULL_DATABASE 권한 부여

           grant EXP_FULL_DATABASE, IMP_FULL_DATABASE to ecampus;

           

        이렇게 함으로써 모든 데이터 베이스 오브젝트에 대한 Data Pump 권한을 획득

        하였습니다. 그럼 이제 실제적으로 Data Pump 를 이용하여 Export/Import 를 실습해 보실

        모든 준비가 되었습니다.   

     

        4. Data Pump 파일 오브젝트

        1) Data Pump 가 사용하는 파일의 종류

           ⓛ Dump File : 테이블로부터 데이터 또는 메타 데이터를 로드하여 저장된 파일

           ② Log File  : Data Pump 작업 중에 발생 하는 메세지나 결과를 기록하는 파일

           ③ SQL File  : Data Pump 는SQLFILE 이라는 옵션을 사용합니다. 이옵션을 사용할 경

                           우 Data Pump Import 작업이 수행되는 동안 DDL 문을 수행할 수 있게

         해주는 옵션입니다.(자세한 사항은 이후에 다룸)

     

        2) Data Pump 디렉토리 오브젝트

          

     

           Data Pump 는 디렉토리 오브젝트를 참조하여 Dump 파일을 쓰게 됩니다.

           그림과 같이 사용자 A는 DO1,DO2 에 허가(GRANT)되어 실재 존재하는 Dir1 과

           Dir2를 사용할 수 있게 됩니다. Data Pump 가 Export 받은 데이터를 Dir1, Dir2 모두

           에 저장할 수 있다. 반면, 사용자 B는 DO1에 만 (Grant) 되어 Dir1 에만 접근할 수 있

           습니다. 이처럼 Data Pump를 이용하게 되면 디렉토리에 대한 권한까지 설정할 수 있

      습니다.

      

           ⓛ 사용 중인 디렉토리 오브젝트의 조회

              SELECT * FROM dba_directories;   

           ② 디렉토리 오브젝트 추가

              CREATE DIRECTORY datapump_dir1 as '/temporary/ora_tmp';  

              '/temporary/ora_tmp' 에 대한 디렉토리 오브젝트 datapump_dir1 을 생성하는

              명령문 입니다.

           ③ 디렉토리 오브젝트에 대한 권한 설정

              GRANT READ,WRITE ON DIRECTORY datapump_dir1 to dangtong;

              ecampus 유저에 대해 datapump_dir1 에 대한 쓰기 및 읽기 권한을 할당하는 명령문 입니다.

              이제 Data pump 를 통해 Export 받을 때 ecampus 유저는 다음과 같이 지정함으로서 '/temporary/ora_tmp'

              에 Export된 덤프 파일을 저장할 수 있습니다.

     expdp dangtong/imsi00 DIRECTORY=datapump_dir1 Tables=EMP dumpfile=dangtong_dump1.dmp

             

           ④ 디펄트 디렉토리 설정하기

              Data Pump 를 사용할 때마다 디렉토리지정을 하지 않고 묵시적으로 사용하고 싶다

              면 운영체제 환경변수에 DATA_DUMP_DIR 을 만들고 그 값으로 디렉토리 오브젝트명

              을 입력 하면 됩니다.

              $ export DATA_DUMP_DIR datapump_dir1

              위와 같이 선언하게 되면 이제 다음과 같이 디렉토리를 지정하지 않아도 됩니다.

              $ expdp ecampus/password  dumpfile=ecam_dump01.dmp Tables= test_00

     

    Dangtong 의 오라클 <Data Pump Export / Import 2편>  

     5. Data Pump Export 사용하기

       이제 본격적으로 Data Pump Export 를 사용하는 방법과, 여러 가지 옵션들에 대해 살펴

       보고, 실 상황에서 옵션들이 어덯게 동작하는지 테스트 해보는 시간을 가져 보도록 하겠습

       니다.

         1) 컴맨드 라인을 이용한 Data Pump 사용

         $ expdp system/manager DIRECTORY=datapump_dir1 DUMPFILE=dangntong_dump01.dmp

         컴맨드 라인을 이용하여 보기와 같이 expdp 를 사용하실 수 있습니다. 커맨들 라인을

         이용 할 때는 비교적 적은 수의 옵션들이 사용되거나 간단한 구문일 때 이용하시는 것이

         좋습니다. 복잡하고, 옵션이 많게 되면 수정 하거나, 잘못 타이핑할 때 시간이 많이

         걸리게 됩니다.

         2) 파라메타 파일을 이용한 Data Pump 사용

         파라메타 파일에 다음과 같이 기록합니다. 파일명은 dangtong.par입니다.

         ⓛ dangtong.par 파일을 다음과 같이 작성하세요

         SCHEMAS=SCOTT

         DIRECTORY=datapump_dir1

         DUMPFILE=dangtong_dump01.dmp

     LOGFILE=dangtong_dump.log  

         $ expdp dangtong/imsi00 PARFILE=dangtong.par

     

       6. Data Pump Export 모드

        1) Full export 모드

        FULL 파라메타를 사용합니다.

        데이터 베이스 전체를 export 받을수 있습니다. 한가지 주의 할점은

        EXPORT_FULL_DATABASE 롤이 Full export 받고자 하는 사용자 에게 부여되어 있

        어야 합니다.

        2) 스키마 모드

        SCHEMAS 파라메타를 사용합니다.

        하나의 유저가 소유하고 있는 데이타및 오브젝트 전체를 export 받고자 할때  사용할 수

        있는 모드입니다.

        3) 테이블스페이스 모드

        TABLESPACE 파라메타를 사용합니다.

        하나 이상의 테이블스페이스에 대해 해당 테이블스페이스에 속한 모든 테이블을 받을수

        있습니다. 만약 TRANSPORT_TABLESPACES 파라메타를 이용한다면, 테이블 뿐 아니라 테이

        블스페이스의 메타데이타 까지 export 받게 되어 다른 서버에 dump 파일을 카피 한 후

        import 하게 되면 테이블 스페이스 및 테이블이 자동으로 생성됩니다.

        4) 테이블 모드

        TABLES 파라메타를 사용합니다.

        하나 이상의 테이블을 export 받을 때 사용합니다.

     

       7. Data Pump Export 파라메타

        1) 파일 및 디렉토리 관련 파라메타

           파라메타 :DIRECTORY,DUMPFILE,FILESIZE,PARFILE,LOGFILE,NOLOGFILE,COMPRESSION

           ① DIRECTORY : 디렉토리 오브젝트를 참조 하는 DIRECTORY 파라메타를 이용하여

              덤프 파일의 위치 및 로그 파일의 위치를 지정할 수 있습니다.

              DIRECTORY=directory_object_name  형식으로 사용할 수 있습니다.

           ② DUMPFILE  : Export 받아 파일시스템에 저장될 덤프파일의 이름을 지정하는 파

              라메터 입니다. 파라메타를 사용할 때 다음을 기억하시고 사용하시면 됩니다.

              - %U 를 사용하여 여러 개의 덤프 파일을 구분할 수 있습니다.

                DUMPFILE=DANGTONG_DUMO_%U.dmp 로 파라메타를 정의 합니다. 만약 덤프 파일

                이 10개가 생성 된다고 가정하면 DANGTONG_DUMO_01.dmp 부터 DANGTONG_DUMO_10.dmp

                까지 %U 부분이 자동 증가하여 파일을 구분하여 줍니다. %U의 범위는 01~99 까

                지입니다.

              - ',' 를 이용하여 여러게의 파일명을 구분할 수 있습니다. 예를 들어 다음과 같이

                DUMPFILE=DANGTONG_DUMO_01.dmp,DANGTONG_DUMO_02.dmp,DANGTONG_DUMO_03.dmp 라고

                정의 할 수 있습니다.

              - 만약 DUMPFILE 파라메타를 지정하지 않는다면 expdat.dmp 라는 파일명으로 오

                라클이 자동 선언하게 됩니다.

           ③ FILESIZE  : Export 받는 1개 파일의 최대 크기를 지정하는 파라메타 입니다.

              만약 총데이터 량이 10Gigabyte 이고 FILESIZE 를 1Gigabyte 로 지정하였다면

              1Gigabyte 크기의 dump file 이 10개 만들어 지게 됩니다.

              FILESIZE=N [ BYTES | KILOBYTES | MEGABYTES | GIGABYTES ] 형식으로 쓸 수 있습

        니다.

     ④ PARFILE   : 파일에 파라메타 들을 저장해두고 Data Pump 를 이용할 때 마다 참조

        하여 작업을 수행하고 싶을 때 PARFILE 파라메타 를  사용할 수 있습니다.

        PARFILE=filename.par 형식으로 사용할 수 있으며, 파일 확장자는 아무런 영향을

        미치지 않습니다.

     ⑤ LOGFILE and NOLOGFILE : 로그파일명을 지정하는 파라메타 입니다.

        LOGFILE=logfile_name 형식으로 사용 하시면 됩니다. 파라메타 를 설정하지 않

        는다면 export.log 라는 파일명으로 로그가 남게 됩니다. 로그파일을 남기고 싶

        지 않을 때는 NOLOGFILE 파라메타 를 사용하시면 됩니다.

     ⑥ COMPRESSION : 오라클에서 EXPORT 시에 메타데이터는 압축을 하여 파일에 저장

        하게 됩니다. COMPRESSION 파라메타를 사용 하지 않을 경우에는 덤프파일 내에

        메타데이타가 압축되어 보관됩니다. COMPRESSION 파라메타 에는 METADATA_ONLY,    

     NONE 두개의 옵션이 있으며,METADATA_ONLY 는 파라메타를 사용하지 않으면 디펄

     트로 인식되는 옵션입니다. COMPRESSION=OPTION_NAME 형식으로 사용하시면 됩니다.

     

    $expdp dangtong/imsi00 DIRECTORY=datapump_dir1 DUMPFILE=dump.dmp COMPRESSION=NONE

     

        2) Export 모드 관련 파라메타

          파라메타 :FULL,SCHEMAS,TABLES,TABLESPACES,TRANSPORT_TABLESPACES

         TRANSPORT_FULL_CHECK 가 있으며, TRANSPORT_FULL_CHECK 파라메타를 제외한 파라메타

         들은 여러분들 께서 이미 "6. Data Pump Export 모드" 에서 학습 하셨습니다. 그럼

         TRANSPORT_FULL_CHECK 파라메타에 대해서만 학습 하도록 하겠습니다.

         TRANSPORT_FULL_CHECK 파라메타는 Export 작업시에 테이블스페이스 내에 존재하는 테

         이블과 인덱스의 의존성을 검사 할 것인지 하지 않을 것인지를 설정하는 파라메타 이

         며 'Y' 또는 'N' 두개의 값만을 허용 하는 파라메타 입니다. TRANSPORT_FULL_CHECK

         파라메타는 TRANSPORT_TABLESPACES 와 같이 사용 되어 집니다.

         ① 'Y' 일경우 TABLESPACE 내에 테이블만 있고 인덱스가 없다면 작업은 실패합니다.

            반드시 INDEX도 같은테이블 스페이스에 존재 해야합니다.

         ② 'Y' 일경우 TABLESPACE 내에 인덱스만 존재하고 테이블이 없다면 작업은 실패합니다.

            반드시 TABLE 또한 존재 해야합니다.

         ③ 'N' 일경우 TABLESPACE 내에 테이블만 있고 인덱스가 없다면 작업은 성공합니다.

         ④ 'N' 일경우 TABLESPACE 내에 인덱스만 있고 테이블이 없다면 작업은 실패합니다.

       

        3) Export 필터링 관련 파라메타

         파라메타 :CONTENT,EXCLUDE,EXCLUDE,QUERY 파라메타가 있으며, 이러한 파라메타들은

         어떤 데이터를 Export 된 파일에 포함시킬지 결정 하는 파라메타 입니다.

         ① CONTENT :3개의 옵션을 가질 수 있으면 옵션 들은 다음과 같습니다.

            - ALL : 테이블과 메터데이터를 포함한 모든것을 포함시키겠다는 옵션

           

     

    $ expdp dangtong/edu2006 DUMPFILE=datadump.dmp CONTENT=ALL

            - DATA_ONLY : 테이블 데이터만 포함 시키겠다는 옵션

           

     

    $ expdp dangtong/edu2006 DUMPFILE=datadump.dmp CONTENT=DATA_ONLY

            - METADATA_ONLY : 메타데이터 만을 포함하겠다는 옵션이며, 이경우 Export된

              파일을 이용해 다른 데이터베이스에 Import할 경우 테이블 구조만 생성되게

              됩니다.

            $ expdp dangtong/edu2006 DUMPFILE=datadump.dmp CONTENT=METADATA_ONLY

         ② EXCLUDE and INCLUDE  : 원하는 오브젝트를 선택하여 받을 수 있습니다.

            그렇다면 EXCLUDE 와 INCLUDE 파라메타가 가질 수 있는 오브젝트의 종류에는 어떤

            것들이 있을까요? 오라클에서 오브젝트란 유저스키마, 테이블, 인덱스, 프로시져

            등을 통칭해서 오브젝트라고 합니다. 파라메타의 사용방법은 아래와 같습니다.

            - SCOTT 유저와 관련된 모든것을 Export 받고 싶은데 단, BONUS 테이블을 제외하고

            받고 싶다면 아래와 같이 하시면 됩니다.

           

     

    $ expdp dangtong/edu2006 dumpfile=ex_dump.dmp schemas=scott

      exclude=TABLES:"='BONUS'"  

            - SCOTT 유저와 관련된 모든 것을 Export 받고 싶은데 단, EMP 테이블의 인덱스는 받

              지 않고 싶다면  다음과 같이 하시면 됩니다.

           

     

    $ expdp dangtong/edu2006 dumpfile=ex_dump.dmp schemas=scott

      exclude=INDEX:\"='EMP%'\"  

     

            [exclude | include]=object_name:조건 형식으로 사용하실 수 있습니다.

     

         ③ QUERY : 테이블 내에 있는 데이터 중 특정 조건에 만족하는 데이터 만을 Export 받

            고자 할때 사용 하는 파라메타 입니다. 사용방법은 다음과 같습니다.

            QUERY=SCHEMA.TABLE: "조건" 이며 다음과 같은 예들을 볼 수 있습니다.

            - QUERY=SCOTT.EMP: "where SAL > 1200 '

            SCOTT유저의 EMP 테이블을 Export 하되 SAL 컬럼의 값이 1200 보다 큰 값들만 Export

            한다는 뜻입니다.

         ④ SAMPLE : 오라클 10g 에서 새롭게 지원하는 기능중 하나로써 테이블의 데이터를

            Export 할때 퍼센트를 정하여 지정된 퍼센트 만큼의 데이터를 샘플링 해서 뽑을

            때 사용 하는 옵션입니다. 사용방법은 아래와 같습니다.

            

     

    $ expdp dangtong/edu2020 DIRECTORY=datapump_dir1 DUMPFILE=datapump.dmp

      SAMPLE=scott.emp:20

         

     

              SCOTT 유저의 EMP 테이블의 데이터 중 20%만을 Export 하게 됩니다.

            - 입력 가능한 PERCENT 의 범위는 0.000001 ~ 100 까지 입니다.

     

        4) 네트웍링크 파라메타

        원격지 데이터 베이스에 있는 데이터에 접근하여 로컬 데이터베이스 머신에 Export

        된 덤프 파일을 저장하고자 한다면 NETWORK_LINK 파라메타를 사용함으로써 가능합니다.

        원격지 데이터는 DB_LINK를 통해 가져올 수 있으며 NETWORK_LINK 파라메타 를 사용하기

        위해서는 원격지 데이터베이스의 테이블에 대한 DB_LIBK 를 만들어 놓아야 합니다.

        A 데이터베이스에 B 테이터베이스의 EMP 테이블을 소유한 SCOTT_B 유저에 대한

        DB LINK link_b_scott_b 이 존재 한다면 다음과 같이 NETWORK_LINK 파라메타를 사용

        하여 export 할 수 있습니다.

        

     

    $ expdp dangtong/edu2006 DIRECTORY=datapump_dir1 dumpfile=datapump.dmp

      NETWORK_LINK=EMP@link_b_scott LOGFILE=datapump.log

     

        5) 암호화 관련 파라메타

        Export 되는 데이터중 일부 컬럼이 암호화 되어 있거나, 중요한 데이터 라면

        ENCRYPTION_PASSWORD 파라메타를 이용하여 Export 시에 암호를 설정 하여 Export

        된 데이터가 위 변조 되지 못하게 설정할 수 있습니다. 사용 방법은 아래와 같습니다.

        

     

    $expdp dangtong/edu2006 TABLES=EMP DUMPFILE=datapump.dmp

     ENCRYPTION_PASSWORD=abcdef

     

        

        위와 같이 설정 하게 되면 차후 Import 시에 패스워드를 물어 보게 됩니다.

         

        6) JOB 관련 파라메타

        JOB 관련 파라메타 에는 JOB,STATUS 가 있습니다.

         JOB : JOB 파라메타를 설정하면 Data Pump 의 작업 명을 오라클에서 자동할당 하지

           않고 JOB 파라메타에 주어진 이름으로 등록 하게 되게 됩니다. 작업 마스터 테이블에

           작업명이 등록괴어 작업에 대한 정보들을 JOB 파라메타에 등록된 이름으로 조회할 수

           있습니다.

         STATUS :STATUS 파라메타는 Data Pump Export 작업시에 작업의 갱신된 내용을 STATUS

           에 설정된 크기의 시간 간격으로 진행상태를 보고 받고자 할때 사용하는 파라메타 입

           니다. STATUS=30 이면 30초 간격으로 작업결과를 갱신하여 보여 주게 됩니다. 만약 이

           파라메타를 설정하지 않으면 디펄트는 0입니다. 디펄트로 설정하게 되면 거의 실시간

           으로 작업 정보를 보여 주게 됩니다.

         FLASHBACK_SCN :System Change Number(SCN)는 시스템의 테이블이나 오브젝트가 변경

        되었을 때  변경 되는 SCN값을 가집니다. FLASHBACK_SCN 파라메타를 이용하여 SCN 값을

        지정할 경우에 파라메타에 설정된 SCN  기준 이전까지의 상태를 받게 됩니다.

        

     

    $expdp dangtong/edu2006 dircetory=datapump_dir1 dumpfile=datapump.dmp

     FLASHBACK_SCN=120001

     

     

         FLASHBACK_TIME : FLASHBACK_TIME은 번호 대신에 시간 값을 가집니다. FLASH_BACK

        파라메타를 사용하면 파라메타에 지정된 시간까지 의 변경사항만을 Export 하게 됩니다.

        FLASHBACK_TIME 의 값은 TIMESTAMP 형식의 값을 가지며 TO_TIMESTAMP 함수를 사용하여

        설정할 수 있습니다.

         PARALLEL : PARALLEL 파라메타를 사용할 경우 Export 작업시에 프로세스를 필요한

        숫자 만큼 만들어 수행 함으로써 작업의 속도를 향상 시킬 수 있습니다. 디펄트 값은

        1로 설정되어 있으며, 주의할 점은 PARALLEL 에 지정된 갯수 만큼의 dumpfile 을 지정

        해주어야 합니다. 앞서 배운 %U 를 사용 하면 지정된 PARALLEL 갯수 만큼 자동으로 파일

        을 만들게 됩니다.

        

     

    $expdp dangtong/edu2006 direcotry=datapump_dir1 dumpfile=datapump%U.dmp

     PARALLEL=3

     

        위와 같이 설정하게 되면 datapump01.dmp, datapump02.dmp, datapump03.dmp 3개의 덤프

        파일이 생성 됩니다.

        

     

    $expdp dangtong/edu2006 direcotry=datapump_dir1 dumpfile=(datapump1.dmp,

     datapump2.dmp, datapump3.dmp) PARALLEL=3

     

     

        위와 같이 %U를 사용하지 않고 사용자가 직접 3개의 파일명을 ',' 로 구분하여 입력해도

        무방 합니다.

         ATTACH : ATTACH 파라메타 를 이용하여 Interactive Mode 로 들어 갈수 있습니다.

         오라클에서는 작업을 제어하고 모니터링 하기 위해 Interactive Mode 를 제공합니다.

         Interactive mode 로 들어가는 방법은 2가지가 있으며 다음과 같습니다.

          - Crtl + C 를 입력 함으로써 들어 갈 수 있습니다.

            $expdp dangtong/edu2006 directory=datapump_dir1                

             table=scott.emp dumpfile=datapump.dmp

             LOGFILE=datapump.log JOBNAME=MYJOB

            작업로그.........

            ................. -> 작업에 대한 로그가 떨어질때 Crtl + C 를 누르게 되면

            export> _         -> 와 같이 프롬프트 상태로 진입하게 됩니다.

            로그가 멈춘다고 해서 작업이 중단 된게 아니라 여러분 께서는 이상태에서 Inter

             active mode 명령을 사용하여 작업을 모티너링 하고 작업을 제어 할수 있습니다.

     

          - $expdp username/password ATTACH=SCHEMA.JOB_NAME 형식 으로 원하는 작업의 

            Interactive mode 로 들어 갈수 있습니다.

            

     

     $expdb dangtong/edu2006 ATTACH=scott.MYJOB

     

            하게 되면 조금 전에 실행한 작업의 Interactive mode 로 들어 가게 됩니다.

            이처럼 ATTACH 파라메타는 현재 수행 중신 작업의 Interactive mode 로 진입 하는데

            사용 되어 지며 InterActive Mode 명령에는 다음과 같은 것들이 있습니다.

            

    명령어

    설명

    ADD_FILE

     덤프파일 을 추가 할 때 사용합니다.

    CONTINUE_CLIENT

     Interactive Mode 에서 Logging Mode 로 전환 할 때 사용합니다.

    EXIT_CLIENT

     Client Session 을 종료하고 Job 의 상태에서 벗어납니다.

    HELP

     Interactive mode 도움말페이지

    KILL_JOB

     작업을 삭제합니다.

    PARALLEL

     현재 수행중인 작업의 프로세스 개수를 조정할때 사용합니다.

    START_JOB

     실패한 작업이나 중단된 작업을 다시 시작시킬 때 사용합니다.

    STATUS

     현재 작업상태를 모니터링 할 때의 갱신 시간을 설정합니다.

    STOP_JOB

     작업의 실행을 중단하고 Client 를 종료합니다.

     

     

     

     

     

     

     

     

     

     

     

    Dangtong 의 오라클 <Data Pump Export / Import 3편> 

      

    7. Data Pump Import 모드

       지금 까지  Data Pump Export 대해 자세히 알아 보았습니다. 데이터베이스 내에 있는 오브

       젝트를 운영체제 파일시스템으로 옮기는 작업을 Data Pump Export 라고 한

       다면 Data Pump Import 작업은 운영체제 파일시스템에 있는 오브젝트 들을 데이터 베이스

       내의 테이블로 옮기는 작업 입니다.  impdp 명령어를 통하여 사용할 수 있으며,

       Data Pump Import 작업에서 처럼 Command 라인, par 파일, Interactive Mode 모두 사용 하

       실 수 있습니다.

     

        1) 파일 및 디렉토리 관련 파라메타

          

     

    impdp dangtong/edu2006 DIRECTORY=datapump_dir1 DUMPFILE=datapump.dmpSCHEMAS=SCOTT

     

     

           과 같이 DIRECTORY 는 디렉토리 오브젝트를 받는 파라메타 이고 DUMPFILE 파라메타

           는 Import 될 파일명, SQLFILE 은 작업 수행동안 수행될 DDL문을 저장할 파일이름

           이며, 디렉토리 관련 파라메타 로 설정 됩니다.

        2) 필터링 관련 파라메타

           필터링 파라관련 파라메타 에는 COTENT,INCLUDE,EXCLUDE,TABLE_EXISTS_ACTION 파라메

           터가 있습니다. COTENT,INCLUDE,EXCLUDE 파라메타는 Export 와 마찬가지로 사용 하

           실수 있으며,TABLE_EXISTS_ACTION 파라메타는 오직 Import 작업시에만 사용 할 수 있

           습니다.

            COTENT : CONTENT 파라메타는 DATA_ONLY,ALL,METADATA_ONLY 3가지 값을 가질 수 있

           으며, CONTENT=DATA_ONLY 형식으로 사용 하실 수 있습니다.

           

     

    impdp dangtong/edu2006 DIRECTORY=datapump_dir1 DUMPFILE=datapump.dmp

    SCHEMAS=SCOTT CONTENT=DATA_ONLY

     

     

     

            INCLUDE : INCLUDE=OBJECT_NAME:"='조건'" 형식으로 사용하실 수 있으며, 오브

           젝트의 종류에는 앞서 배운 것 과 같이 TABLE,INDEX,PORCEDURE,FUNCTION 등이 있습

           니다.

           

     

    impdp dangtong/edu2006 DIRECTORY=datapump_dir1 DUMPFILE=datapump.dmp

    SCHEMAS=SCOTT INCLUDE=TABLE:"='SAL'"

     

     

     

           SCOTT 유저의 테이블을 Import 하되 SAL 테이블 만 포함 시키라는 명령 이 됩니다

           SCOTT 유저가 EMP,SAL,SALARY 3개의 테이블을 가졌다고 가정하고 하나의 덤프파일에

           3개의 테이블을 Export 받았고, 위와 같은 import 명령을 내린다면 3개의 테이블중

           오직 SAL 테이블 만을 Import 하게 됩니다.

            EXCLUDE : EXCLUDE=OBJECT_NAME:"='조건'" 형식으로 사용하실 수 있으며, 마찬가지

           로 오브젝트 종류는 INCLUDE 와 같습니다.

     

           

     

    impdp dangtong/edu2006 DIRECTORY=datapump_dir1 DUMPFILE=datapump.dmp

    SCHEMAS=SCOTT EXCLUDE=TABLE:"='SAL'"

     

     

     

           SCOTT 유저의 테이블을 Import 하되 SAL 테이블을 제외한 나머지 테이블을 Import

           하라는 명령이 되겠죠? 마찬가지로 SCOTT 유저가 EMP,SAL,SALARY 3개의 테이블을 가졌

           다고 가정하고 하나의 덤프파일에 3개의 테이블을 Export 받았고, 위와 같은 import

           명령을 내린다면 3개의 테이블중 SAL 을 제외한 EMP,SALARY 테이블만 Import 될 것

           입니다.

            TABLE_EXISTS_ACTION : Import 시에 중요한 옵션입니다. 우리가 Data Pump 를 통

           해 작업을 하게될 경우 같은 이름의 테이블이 존재할 때가 있습니다. 만약 테이블이

           존재 하더라도 Import 하고자 하는 데이터의 row 수가 다를 수고 있고 같을 수도 있

           을 겁니다. 즉, 테이블은 존재하지만 데이터의 내용은 차이가 난다는 거죠.

           이러한 경우에 사용할 수 있는 유용한 파라메타가  TABLE_EXISTS_ACTION 입니다.

           TABLE_EXISTS_ACTION 파라메타는  SKIP,APPEND,TRUNCATE,REPLACE 의 값을 가질수 있으

           며 각 값의 의미는 다음과 같습니다.

           - SKIP     : 같은 테이블을 만나면 지나치고 다음 테이블을 Import 합니다.

           - APPEND   : 같은 테이블을 만나면 기존의 데이터에 추가하여 Import 합니다.

           - TRUNCATE : 같은 테이블을 만날경우 기존의 테이블을 TRUNCATE 하고 새로운 데이

                        터를 Import 합니다.

           - REPLACE  : 같은 테이블을 만날 경우 기존의 테이블을 DROP 하고 테이블을 재생성

                        한후 데이터을 Import 합니다.

           

     

    impdp dangtong/edu2006 DIRECTORY=datapump_dir1 DUMPFILE=datapump.dmp

    SCHEMAS=SCOTT TABLE_EXISTS_ACTION=SKIP  

     

     

           위와 같이 실행하면 같은 테이블을 만날경우 그냥 지나치고 다른 테이블을 Import

           하겠죠?

          2) JOB 관련 파라메타

           앞서 학습한 JOB_NAME,STATUS,PARALLEL 파라메타를 Export 와 같은 방법으로 사용

           하실 수 있습니다. Export 와 마찬가지로 PARALLEL 작업시에 dumpfile 의 개수를

           %u를 사용하여 지정하여 주거나, 명시적으로 ','를 사용하여 PARALLEL 개수 만큼

           파일을 지정 하셔야 합니다.

     

          3) 리맵핑 관련 파라메타

          리맵핑 관련 파라메타에는 REMAP_SCHEMA,REAMP_DATAFILE,REMAP_TABLESPACE 가 있으며,

          이들 파라메타 를 통하여 우리는 다른 데이터베이스 로 Import 시에 많은 유연성을 제

          공 받을 수 있습니다.

           REMAP_SCHEMA : A 유저 스키마로 Export 받은 데이터를 B 유저 스키마로 Import 하

          고자 할때 사용 합니다.

          

          

     

    impdp dangtong/edu2006 DIRECTORY=datapump_dir1 DUMPFILE=datapump.dmp

    SCHEMAS=SCOTT REMAP_SCHEMA=SCOTT:DANGTONG

     

     

          위와 같이 수행한후 TABLE의 OWNER 을 조회 한다면 DANGTONG 유저의 소유로 테이블

          이 등록 되었음을 확인 하실수 있습니다.

           REMAP_DATAFILE : 전체 데이타베이스 시스템을 Data Pump 를 통하여 옮기고자 할때

          Export 된 daumfile 에는 DataFile 정보까지 포함하게 됩니다. 하지만 다른시스템의

          디스크 경로 상에는 존재하지 않는 경로이기 때문에 Import에 실패하게 됩니다. 이러한

          경우에 사용 할 수 있는 파라메타가 REAMP_DATAFILE 입니다. Export 된 dumpfile 이

          Datafile 정보를 포함한 경우에만 해당합니다.

          

     

    impdp dangtong/edu2006 FULL=Y DIRECTORY=datapump_dir1

    DUMPFILE=datapump.dmp 

    REMAP_DATAFILE='/db1/data/lvol01':'/db2/data/lvol01',

                   '/db1/data/lvol02':'/db2/data/lvol02'     

                                    .

                                    .

                                    .

     

     

     

           REMAP_TABLESPACE : Export 받은 데이터 속한 TABLESPACE에서 다른 테이블 스페이

          스로 REMAPPING 하고 하는 경우 사용할 수 있응 파라메타 입니다.

          

     

    impdp dangtong/edu2006 REMAP_TABLESPACE='scott_tsb':'dangtong:tbs'

    DIRECTORY=datapump_dir1 DUMPFILE=datapump.dmp SCHEMAS=SCOTT

     

     

          4) 네트웍 링크 파라메타

          Export 에서와 마찬가지로 DB LINK를 이용하여 원격지 데이터베이스에 대해 Import

          작업을 수행할 수 있습니다.

     

          5) Interactive mode 파라메타

          Export 에서와 마찬가지로 Ctrl + C 를 통하여 Interactive mode 로 진입할 수 있으며

          작업을 통제 할 수 있습니다.

     

       8. Data Pump 모니터링 하기  

       이번 장에서는 SQL을 통한 작업 모니터링 방법에 대하여 학습해 보도록 하겠습니다.

       작업의 진행 경과와 작업속성들 그리고 얼마나 많은 작업들이 존재 하는가를 알 수

       있습니다.

          1) 관련 조회 테이블 및 VIEW 들

         

              DBA_DATAPUMP_JOBS 현재 실행중인 작업의 속성들을 살펴 볼 수 있는 테이블

                입니다.

             SQL> select * from dba_datapump_jods;

             로 조회 하시면  다음과 같은 컴럼이 나옵니다.

             - OWNER_NAME  : DB 작업 계정

             - JOB_NAME    : 작업의 명칭

             - JOB_MODE,   : FULL,TABLE,INDEX,TABLESPACE 등이 있습니다.

             - STATE       : EXECUTING(수행중),DEFINING ,UNDEFINED, NOT RUNNING 의 값을

                             가집니다.

              Pump Session 확인

            Select sid,serial# from v$session session,dba_datapump_session pump_session

            where session.saddr = pump_session.saddr;

             로 조회 하시면 현재 Data Pump 를 통해 수행 중인 모든 Session 들과 상태들을

             모니터링 할 수 있습니다.

              Data Pump  의  모니터링

             SELECT opname,target_desc,sofar,totalwork,(sofar/totalwork*100) Percentage

             FROM v$session_longops;

             opname  : JOBNAME 과 같습니다.

             TOTALWORK : 총 수행하여야할 용량을 가르키며 단위는 Megabytes 입니다.

             sofar     : 현재 수행한 용량 을 가르키며 단위는  Megabytes 입니다.

             target_desc : 작업의 종류를 말합니다. IMPORT/EXPORT 가 값이 될수 있습니다.

     

    Dangtong 의 오라클 <ASM 4편- ASM관리 및 모니터링> 

     

    4절. ASM 의 관리

     

    이절에서는 생성된 ASM 인스턴스와 DiskGroup 을 관리하기 위한 명령어 들과 관리 방법에 대해 보고 더불어 관리를 위한 다양한

    VIEW 들에 대해 학습해 보도록 합시다.

     

    1. DiskGroup 의 변경과 관리

    1) DiskGroup 의 변경

       ① disk 의 추가

     

       

     % Alter diskgroup ecamp_disk1 add disk '/dev/rdsk/c4t20d7s4'   

        rebalance power 11;

     

       디스크 그룹에 디스크를 추가하는 sql문 입니다. 명령문 끋에 REBALACNE 속도를 조절

       하는 옵션을 볼수 있습니다. 앞서 학습한 바와 같이 디스크를  추가하거나 삭제 할대 REB

       ALANCE 이벤트가 발생 하는데요, 마찬가지로 디스크를 추가할때 속도를 해당 오퍼레이

       션에 한에 조절 할 수 있습니다. 옵션을 사용하지 않으면 파라메터에 설정된       

       ASM_POWER_LIMIT 를 기본 값으로 사용합니다. 만약 시스템의 부하가 많고 운영시간중에 디

       스크의 추가나 삭제가 이루어 져야 한단면. rebalance power 옵션을 사용하여 사용자가 조

       절한다면  시스템에 긍정적인 효과를 볼수 있습니다.

       ② disk 의 삭제

       

     SQL> Alter diskgroup ecamp_disk1 drop disk '/dev/rdsk/c4t20d7s4'

        rebalance power 11 ;

     

       마찬가지로 REBALANCE 속도를 조절할수 있습니다. 단. sql문을 수행하면 백그라운드로

       삭제 작업이 수행됩니다.  만약 삭제후 삭제 취소를 하고 싶다면 다음과 같은 sql문을 작성

       하여 실행 하시면 됩니다.

     

       

      SQL> Alter diskgroup ecamp_disk1 undrop disks;

       단, 주의 할점은 백그라운드로 수행되던 삭제 작업이 종료 되었다면, 수행 할수 없으며, 현

       재 수행 중이라면 삭제 작업을 취소 할 수 있습니다.

     

     

       ③ DiskGroup의 Mount 와 Unmount

       기본적으로 ASM 인스턴스의 시작시에 자동으로 디스크 그룹이 마운트 되게 되어 있지만,

       다음과 같은 sql문을 통해 사용자가 메뉴얼 하게 조정 할 수 있습니다.

       

       

     SQL> alter diskgroup alll dismount;  -- 디스크그룹을 마운트 합니다.

       

     SQL> alter diskgroup ecamp_disk1 mount; -- 디스크 그룹을 언마운트 합니다.

       위 sql 문에서 보듯이 all 또는 해당 DiskGroup 명을 명시 할수 있습니다.  

       

       ④ DiskGroup 의 정합성 체크

       

       

     SQL> alter diskgroup ecamp_disk1 check all

       디스크 그룹의 정합성을 체크합니다. 단, 정합성 체크를 위해서는 디스크 그룹이 마운트

       상태 이여햐 합니다. 부가적으로 발생하는 에러 로그 들은 Alert.log 에 생성됩니다.

     

    2. ASM 의 디렉토리 생성및 관리

     

    ASM 디스크 그룹의 생성 하게 되면 기본적으로 디스크 그룹의 이름이 최상위 root  디렉토리 가 됩니다. ASM 내에 사용자가 디렉토리

    를 추가적으로 생성하여 리두로그, 아카이브로그, 콘트롤 파일 들을 기록 할 수 있습니다.

     

    ① ASM 의 디렉토리 생성

    우리가 생성한 디스크 그룹은 ecamp_disk1, ecamp_disk2 입니다. 따라서 다음 과 같이 디렉토리를 생성 할 수 있습니다.

     

     SQL> alter diksgroup ecamp_disk1

           add directory '+ecamp_disk1/mydir' ;

     

    위의 sql문에서 '+' 기호는 디렉토리 라는 의미로 사용되어 집니다. '+' 기호가 들어가면 ASM

    의 내부 디렉토리로 해석하게 됩니다.

     

    ② ASM 디렉토리의 RENAME

    설정 된 디렉토리 명을 바구기 위해서는 다음과 같은 sql문을 실행 하시면 됩니다.

     

     SQL> alter diskgroup ecamp_disk1 rename directory

           '+ecamp_disk1/mydir' to '+ecamp_disk1/renamed_dir'

     

    ③ ASM 디렉토리의 삭제

    디렉토리를 삭제 할대는 다음과 같은 명령문을 실행하면 됩니다.

     

     SQL> alter diskgroup ecamp_disk1 drop directory 

           '+ecamp_disk1/renamed_dir' FORCE to

           '+ecamp_disk1/renamed_dir'

     

    FORCE 옵션은 디렉토리내의 파일이 있을경우 파일까지 모두 삭제 할때 사용합니다. 일반적

    으로 FORCE 옵션을 사용하여 삭제 합니다.

     

    3. ASM 에서의 파일 템플릿과 파일 생성

     

    오라클 10g 에서는 파일을 다룰때 파일이  ASM 디스크 에서 어덯게 기록되며, 기록될때 스트라이핑 이나 미러링의 속성을 어떠한 형

    태로 가지게 될까를 템플릿 이라는 새로운 개념을

    도입하여 설정합니다. 템플릿은 시스템에 제공 되는 템플릿과 , 사용자 정의 템플릿 두가지가 있습니다 우선 오라클에서 지원되는 파일

    의 종류를 살펴 보도록 하겠습니다.

     

    File Type

    지원여부

    템플릿명

    콘트롤 파일

    yes

    CONTROLFILE

    데이타 파일

    yes

    DATAFILE

    리두로그 파일

    yes

    ONLINELOG

    아카이브로그 파일

    yes

    ARCHIVELOG

    트레이스 파일

    no

    N/A

    Temporary files

    yes

    TEMPFILE

    Datafile backup pieces

    yes

    BACKUPSET

    Datafile incremental backup pieces

    yes

    BACKUPSET

    Archive log backup piece

    yes

    BACKUPSET

    Datafile copy

    yes

    DATAFILE

    Persistent initialization parameter file(SPFILE)

    yes

    PARAMETERFILE

    Disaster recovery configurations

    yes

    DATAGUARDCONFIG

    Flashback logs

    yes

    FLASHBACK

    Change tracking file

    yes

    CHANGETRACKING

    Data Pump dumpset

    yes

    DUMPSET

    Automatically generated control file backup

    yes

    AUTOBACKUP

     

     

    오라클에서는 트레이스 파일을 제외한 모든 파일 템플릿을 제공합니다.. 그럼 이러한 파일들이 앞서 학습한 NOMAL REDUNDANCY,

    HIGH REDUNDANCY, EXTERNAL REDUNDANCY 의 환경에서 어덯게 기록 되는 지 살펴 보도록 하겠습니다.

     

    Template Nmae

    Striping

    Mirroring,

    Nomal

    Redundancy

    Mirroring,

    High

    Redundancy

    Mirroring,

    Erternal

    Redundancy

    ARCHIVELOG

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    TEMPFILE

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    BACKUPSET

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    PARAMETERFILE

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    DATAGUARDCONFIG

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    FLASHBACK

    FINE

    MIRROR

    HIGH

    UNPROTECTED

    CHANGETRACKING

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    DUMPSET

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    XTRANSPORT

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    AUTOBACKUP

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    DATAFILE

    COARSE

    MIRROR

    HIGH

    UNPROTECTED

    CONTROLFILE

    FINE

    HIGH

    HIGH

    UNPROTECTED

    ONLINELOG

    FINE

    MIRROR

    HIGH

    UNPROTECTED

     

    표에서 보듯 Striping AU(Allocation Unit) 의 크기가 FLASHBACK, CONTROLFILE, ONLINELOG 일경우 항상 FINE GRAINDED 하게 설

    정됩니다.  디펄트로 제공되는 템플릿 이되에 사용자가 직접 mirroring 이나 string 정도를 설정 하고 싶을 때에는 다음과 같이 직접

    플릿을 작성하여 디스크 그룹에 추가해 주면 됩니다.

     

     SQL> alter diskgroup ecamp_disk1 add template my_temp

           attributes mirror fine

    ATTRIBUTES(속성)을 지정하지 않는다면 디스크 그룹이 NOMAL 일경우 MIRROR 가 디펄트 값이며,, HIGH일 경우는 HIGH 가 디펄트

     입니다.  디스크 그룹이 EXTERNAL 일경우에는 UNPROTECTED 값이 자동으로 설정 됩니다.

     

    4. ASM 을 사용한 TABLESPACE생성

    우리가 ecamp_disk1 DiskGroup 을 상에 테이블 스페이스를 생성하고자 한다면 , 다음과 같은 sql문을 작성하여 실행 할 수 있습니다.

     

               SQL> create tablespace sample DATAFILE 'ecamp_disk1(datafile)';  

     

             

     

    그림과 같이 테이터 파일을 생성하게 되면 일련된 이이터 파일은 디스크 그룹내의 여러개의

    디스크로 균일하게 쪼개어져 저장됨으로써 디스크 I/O 집중을 막을수 있습니다.

    Create tablespace sample datafile '+ecamp_disk1(datafile)' 에서  + 기호는 디렉토리라는

    뜻이며 '()' 안의 내용은 생성된 파일의 속성을 템플릿을 이용하여 지정 하였습니다.

    datafile 이라는 템플릿을 사용하였으므로 Redundancy 정도에 따라 템플릿 정보에 의해 다르

    게 기록 될것입니다.

    이러한 방법으로 테이블 스페이스 뿐만 아니라 아카이브 로그 , 리두로그  등을 ASM 을 이용하여 저장할 수 있습니다.

     

    5. ASM 을 사용한 Redolog생성

     

    init 파라메터 파일에 다음과 같이 값을 설정합니다.

     

    DB_CREATE_ONLINE_LOG_DEST1= '+ecamp_disk1'

    DB_CREATE_ONLINE_LOG_DEST2= '+ecamp_disk2'

     

    설정우 sqlplus 로 접속하여

     

    SQL> alter database add logfile;

     

    6. ASM 모니터링 하기

     

    1) ASMCMD (ASM Command Line Interface) 를 이용한 ASM 모니터링

    ASM에서는 sqlplus 를 이용해서 ASM 내에 생성 되는 파일이나 디렉토리를 볼수 있을 뿐만아니라 ASMCMD 라는 Command Line

    Interface 를 제공하여 sqlplus 보다 더욱 간편하게 파일이나 디텍토리를 조회 할 수 있습니다. sql문과 마찬가지로 ASMCMD 를 사용

    하기 위해서는 환결변수의 변경이 필요합니다. 환경 변수 를 변경하고 asmcmd 를 실행하면 Command Line Mode 로 접속 할 수 있습

    니다.

     

    % export ORACLE_SID=+ASM

    % asmcmd

    ASMCMD> help

     

    help 명령어는 ASMCMD 의 명령어 사용방법을 알려줍니다. 유니긋 명령어와 유사아여 help 페이지를 토대로 누구나

    실습할수 있습니다.

    다음과 같이 ASM 내의 디렉토리로 들어간다음 파일 목록들을 볼수 가 있습니다.

     

    ASMCMD> cd +ecamp_disk1

    ASMCMD> ls -al

    Type     Redund    Striped    Time      Sys       Name

                                               Y         ORAASM/

    ASMCMD> cd ORAASM

    ASMCMD> ls

    1_2_589873405.dbf

    ARCHIVELOG/

    CONTROLFILE/

    DATAFILE/

    ONLINELOG/

    PARAMETERFILE/

    TEMPFILE/

    spfileoraasm.ora

    ASMCMD> du

    Used_MB      Mirror_used_MB

    1287                     2585

    ASMCMD>_

     

    위의 예제에서보듯이 'cd' 명령어를 통해 디렉토리에 접근 할 수 있으며 'ls' 명령을 통해 파일 리스트를 확인 할 수 있습니다.

    또한 du 명령어를 통해 용량을 확인 할 수 있습니다.

     

    2) ASM  관련 VIEW 를 이요한 모니터링

     

    VIEW

    설명

    V$ASM_DISKGROUP

    디스크 그룹에 관계된 정보를 저장함.

    V$ASM_DISK

    디스크 에 관계된 정보를 저장함

    V$ASM_FILE

    ASM 상에 생성된 파일데 대한 정보를 보여줍니다.

    V$ASM_TEMPLATE

    ASM 상의 모든디스크 그룹에 설정된 템플릿정보를 보여줍니다.

    V$ASM_ALIAS

    ASM 디스크 그룹의 별칭 정보를 보여줍니다.

    V$ASM_OPERATION

    ASM 인스턴스상에서 실행되는 작업들의 현황을 보여줍니다.

    V$ASM_CLIENT

    ASM 을 사용하는 DB 인스턴스를 보여줍니다.

     

     

    ① ASM 에 접속된 DB 인스턴스 상태 확인하기

    ASM 인스턴스에 접속된 DB 인스턴스의 정보와 연결상태 등을 조회 할 수 있습니다.

     

    SQL> select instance_name,db_name,status from v$asm_client

    INSTANCE_NAME        DB_NAME      STATUS

    oraasm                  oraasm         CONNECTED

    ② 디스크 그룹 정보 확인

    디스크 그룹에 대한 정보를 알수 있습니다.

     

    SQL> select name,state,type,total_mb,free_mb from v$asm_diskgroup

    NAME         STATE      TYPE     TOTAL_MB   FREE_MB

    ecamp_disk1   MOUNTED   NORMAL         3904        1218

    ecamp_disk2   MOUNTED   NORMAL          1952        1850

     

    ③ 디스크 정보 확인

    디스크에 대한 정보를 확인할 수 있습니다.

     

    SQL> select name,path,group_number from v$asm_disk

    NAME                    PATH              GROUP_NUMBER

    ECAMP_DISK2_001        /dev/raw/raw6                     2

    ECAMP_DISK2_000       /dev/raw/raw6                      2

    ECAMP_DISK1_000       /dev/raw/raw6                      1

    ECAMP_DISK1_001       /dev/raw/raw6                      1

    ECAMP_DISK1_002       /dev/raw/raw6                      1

    ECAMP_DISK1_003       /dev/raw/raw6                      1   

     

     

     

    '(DB) Oracle > Object & Utility' 카테고리의 다른 글

    Oracle - SQL TRACE  (0) 2017.01.22
    Oracle - 데이터 펌프 (Data Pump) expdp, impdp  (0) 2017.01.22
    Oracle - Listener_EM Console  (0) 2017.01.21
    Oracle - Pro*C  (0) 2017.01.21
    Oracle - Recovery - Point in Time  (0) 2017.01.21
    Posted by 농부지기
    ,

    [Oracle - 데이터 펌프 (Data Pump) expdp, impdp ]

     

    ※ 10g부터 제공.
        expdp, impdp는 exp, imp와 호환돼지 않는다. 기존의 exp로 추출한 데이터를 impdp로 입력할 수 없다.

    1. DP의 장점
        - 오브젝트와 데이터의 선택
                EXCLUDE, INCLUDE, CONTENT 파라메터를 이용해서 이전버전 보다 쉽게 추출하거나 입력할 대상을 선택할 수 있다.
        - 데이터베이스의 버전을 명시적으로 정의한다.
                VERSION 파라메터를 사용하여 이동할 객체의 데이터베이스 버전을 지정하면 데이터 펌프를 지원하는 이전 릴리즈의
                오라클 데이터베이스와 호환 가능한 덤프 파일 셋트를 생성한다. 현재는 릴리즈 10, 11 간에 호환이 가능하다.
        - 병렬수행이 가능하다.
        - exp에 필요한 디스크 공간을 예측한다.
        - 분산환경에서의 네트워크 모드
                원격지의 데이터베이스에서 직접 데이터를 추출할 수 있다.
        - remmaping : 데이터를 입력하는 동안 데이터를 입력할 데이터 파일명, 스키마, 테이블 스페이스를 변경할 수 있다.
        - 데이터를 추출할 때, 압축 기능을 사용할 수 있다.
        - 작업이 길어진다면 중간에 멈췄다가 재개할 수도 있다.
                INTERACTIVE COMMAND LINE 모드로 가능하다.

    2. DP 인터페이스
        dp를 수행하기 위해서 다음과 같은 인터페이스를 제공한다.
        - command line
                대부분의 파라메터를 커맨드라인에서 입력하여 실행한다.
        - parameter file
                모든 커맨드 라인 파라메터를 파라메터 파일에 정의할 수 있다.
                단, PARFILE은 제외한다. 이 파라메터는 파라메터 파일의 위치를 정의한다.
        - interactive command line
                이 모드를 사용하면, 터미널의 로깅이 중지되고, export 혹은 import 프롬프트가 표시된다. 
                커맨드라인 혹은 파라메터 파일로 시작한 export 작업 중에 '컨트롤+C' 키를 눌러서 활성화한다.
        - database control
                엔터프라이즈 메니져를 쓴다.

    3. DP 모드
        다음과 같은 모드들이 있다.
        - Full
        - Schema
        - Table
        - Tablespace
        - Transportable tablespace

     

    ------------------------------------------------------------

    출처:http://kr.forums.oracle.com/forums/thread.jspa?threadID=477162&tstart=60

    제품 : ORACLE SERVER

    작성날짜 : 2004-05-28


    [10G]ORACLE DATA PUMP를 사용하여 이미 존재하는 테이블에 IMPORT 수행
    ===================================================================

    PURPOSE
    -------
    이 문서는, datapump 파라미터인 TABLE_EXISTS_ACTION과 CONTENT 파라미터를 사용하여 이미 존재
    하는 테이블에 데이터를 import 시키는 상세 방법을 지정하는 절차를 보여주는데 목적을 둔다.

    Explanation
    -----------
    Data Pump import는 TABLE_EXISTS_ACTION라는 새로운 파라미터를 사용하며 CONTENT (export, import)
    파라미터와 함께, 이미 존재하는 테이블에 데이터를 어떻게 import 하는지를 지정한다.
    이 새로운 파라미터는 기존 export/import 유틸리티의 'ROWS'와 'IGNORE' 파라미터와 사용법이
    유사하다.

    TABLE_EXISTS_ACTION 파라미터:
    ---------------------------

    기본값: SKIP (주의 : CONTENT=DATA_ONLY를 지정할 경우에는 기본 값이 SKIP이 아니라 APPEND 임)


    이 파라미터는 생성하고자 하는 테이블이 이미 존재할 경우, 어떤 작업을 수행할지를 지정한다.
    지정 가능한 값에는 다음과 같은 것들이 있다 :

    SKIP - 테이블을 있는 그대로 두고 다음 객체 생성으로 이동한다. CONTENT 파라미터를 DATA_ONLY로 지정할 경우
    SKIP을 지정할 수 없다.
    APPEND - 소스로 부터 row를 읽어 들여 테이블에 적재 시키고, 이미 존재하는 row는 그대로 둠
    TRUNCATE - 이미 존재하는 row가 있다면 삭제시킨 후 새로 데이터를 적재 시킴
    REPLACE - 이미 존재하는 테이블을 드롭 시킨 후, 테이블을 새로 만들고 데이터를 적재 시킴. CONTET 파라미터를
    DATA_ONLY로 지정하느 경우 이 값을 지정할 수 없다.

    다음은 옵션을 지정하는데 있어 고려해야 할 사항이다 :

    TRUNCATE나 REPLACE를 지정할 경우, 영향을 바는 테이블이 참조 무결성에 의해 참조 되지 않는 지 여부를 확인한다.
    SKIP, APPEND 또는 TRUCATE를 지정할 경우, 이미 존재하는 테이블에 대한 인덱스나, 권한 부여, 트리거, 제약 조건이
    무시된다. REPLACE를 지정할 경우, 의존 관계에 있는 객체들이 먼저 drop 된 후, 재 생성된다. 이것을
    피하기 위해서는 EXCLUDE를 사용하여, 명시적으로 제외를 시키거나 임포트 하고자 하는 덤프 파일에 해당 내용이
    포함 되지 않아야 한다.
    APPEND나 TRUNCATE를 사용할 경우에는,다른 모든 작업에 앞서 덤프 파일의 내용이 이미 존재하는 테이블에 들어갈 수
    있는 형태의 데이터인지를 먼저 확인한다.

    이미 존재하는 테이블에 대해서는 external 테이블을 사용하여 load 작업이 수행되는데 이것은, external table 이
    constraint나 trigger가 제 기능을 하도록 하기 때문이다. 하지만, active constraint를 위반하는 row 가
    하나라도 존재하면,load 작업은 취소되어 아무런 데이터도 load 되지 않는다는 점을 기억해 둘 필요가 있다.

    만약 데이터를 반드시 load 시켜야 하는데, constraint voilation을 유발시킬 만한 내용이 있다면
    constraint를 먼저 disable 시키고, 데이터를 적재 시킨 후, 문제가 되는 row를 삭제 하고 constraint를
    다시 enable 시키는 방법을 사용해야 한다.

    APPEND를 사용할 때는, 데이터가 언제나 새로운 공간에 load 된다. 기존에 사용중인 공간에 여유 공간이 있더라도
    재 사용되지 않는다. 이와 같은 이유 때문에 데이터에 대한 compress를 별도로 수행할 필요가 있을 수도 있다.

    CONTENT 파라미터:
    ---------------

    CONTENT 파라미터는 Export 또는 Import 세션에서 사용할 수 있다. 명백하게, export 값이 DATA_ONLY나
    METADATA_ONLY였다면, 지정된 데이터만 덤프파일에 존재하여 import 시 사용할 수 있다.

    기본값 : ALL

    import 될 수 있는 내용을 제한하기 위해서는 다음과 같은 옵션을 사용할 수 있다 :

    DATA_ONLY - 이미 존재하는 테이블에 대해서만 데이터를 load 시킨다. 없던 객체를 생성 시키지 않는다.
    METADATA_ONLY - 데이터베이스 객체에 대한 정의만 load 시킨다. 테이블의 row 데이터를 load 시키지 않는다.
    ALL - 소스의 데이터 및 메타데이터를 load 시킨다. 기본 값.





    Example
    -------


    Reference Documents
    -------------------
    Note:261013.1 Importing into Existing tables with Oracle Data Pump
    Oracle Database Utilities 10g Release 1 (10.1) 

     

     

     

     

     

    '(DB) Oracle > Object & Utility' 카테고리의 다른 글

    Oracle - SQL TRACE  (0) 2017.01.22
    Oracle - Data Pump Export / Import 1편  (0) 2017.01.22
    Oracle - Listener_EM Console  (0) 2017.01.21
    Oracle - Pro*C  (0) 2017.01.21
    Oracle - Recovery - Point in Time  (0) 2017.01.21
    Posted by 농부지기
    ,