//-- 원문출처: http://www.dba-oracle.com/t_impdp_transform_segment_attributes.htm 

//-- impdp transform=segment_attributes

//-- Oracle Database Tips by Donald BurlesonFebruary 22, 2015 


impdp transform=segment_attributes

Oracle Database Tips by Donald BurlesonFebruary 22, 2015

Question:  What does the impdp transform parameter do?  I read about thetransform=segment_attributes:n:table argument in the docs.

Answer:  Oracle data pump import (impdp) provides the transform=segment_attributes argument to allow you to change object DDL for specific objects (table, indexes), and remove just about everything from the DDL but the basic column definitions.

If the value is transform=segment_attributes:y (the default), then segment attributes (file attributes, storage parameters, tablespaces, and logging) are included in the import (impdp, with the DDL for the specified object types.

For example, if you wanted to use the default tablespace parameters for the imported DDL, you could include:

root>  impdp scott/tiger transform=segment_attributes:n:tables

This example would import only the "basic" DDL for all table DDL in the dmp file, omitting the storage clause, tablespace specification and datafiles parameters, allowing the system-wide defaults to be used.  This is useful when you don't want to have to pre-create all of the table definitions and import with ignore=y.

In another example, assume that you only wanted to omit the storage clauses for all tables:

root>  impdp scott/tiger transform=segment_attributes:storage:n

You can also use the impdp transform=segment_attributes:n is used with other arguments such as remap_tablespace  to change the tablespace names for all table in the import dmp file.  For example, the following directs the import (impdp) to ignore the existing tablespace specifications and re-map the tablespace names:

root>  impdp scott/tiger transform=segment_attributes:n remap_tablespace=users:prodts

You can also combine transform=segment_attributes parameters to perform multiple operations on the dmp file DDL. 

root>  impdp scott/tiger transform=SEGMENT_ATTRIBUTES:n:table,STORAGE:N:table



//-- Oracle DB 의 Datapump 를 이용한 DB 간 Data 이관 

//-- Draft 버전 



1. 개요 


  -- 필요한경우 

    > Oracle DB 간의 Data Migration

    > 사례1) 개발DB에 있는 특정한 Schema의 모든 Object들을 운영DB로 모두 옮기는 경우 등 

  -- 제약사항

    > Oracle DB 10.2.0.X 이상 (11.1.0.X 이상 권고) => 해당 버전 이상에서 제공하는 datapump 를 사용


  

2. 전체적인 가이드


  A. Datapump 를 떨어뜨릴 Directory를 소스/타켓 양쪽에 생성

  B. Datapump 명령어로, 해당 Data 를 OS File 형태로 추출

  C. FTP 로 타켓서버로 전송

  D. Datapump 명령어로, 해당 OS File 을 DB에 적재 



3. 세부방법


  A. (소스/타켓 양쪽 DB에) Directory 설정 


  -- 기존 Directory 중 적당한 것을 사용해도 되고, 새로 만들어 사용해도 됨

  -- DB 관리user 인 system 을 사용하는 것이 무난함 => 그렇지 않은 경우, 일반 User 에 필요한 권한을 설정 필요

  

  -- 기존 Directory 조회

  -- 아래의 경우, DATA_PUMP_DIR 가 사용하기에 무난

  

SQL> set linesize 350

SQL> set pagesize 100

SQL> col owner format a15

SQL> col directory_path format a80  

SQL> select * from dba_directories ; 


OWNER        DIRECTORY_NAME                 DIRECTORY_PATH

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

SYS          SUBDIR                            /app/oracle/product/11.2.0/db/demo/schema/order_entry/2002/Sep

SYS          SS_OE_XMLDIR                   /app/oracle/product/11.2.0/db/demo/schema/order_entry/

SYS          JOOYH_DIR                        /home/oracle/data_pump

SYS          LOG_FILE_DIR                     /app/oracle/product/11.2.0/db/demo/schema/log/

SYS          MEDIA_DIR                        /app/oracle/product/11.2.0/db/demo/schema/product_media/

SYS          XMLDIR                             /app/oracle/product/11.2.0/db/rdbms/xml

SYS          DATA_FILE_DIR                    /app/oracle/product/11.2.0/db/demo/schema/sales_history/

SYS          DATA_PUMP_DIR                 /app/oracle/admin/ogg25/dpdump/

SYS          ORACLE_OCM_CONFIG_DIR    /app/oracle/product/11.2.0/db/ccr/state

9 rows selected.

SQL> 


  -- 새로운 Directory 생성 (tran_pump 로 생성) 및 필요권한 부여

  -- system 에는 이미 권한이 있으나, 셈풀Query를 수행

  

[/home/oracle]$ id

 uid=401(oracle) gid=512(dba) groups=512(dba)

 [/home/oracle]$ cd /app/oracle/admin/ogg25/

 [/app/oracle/admin/ogg25/]$ mkdir tran_pump         --  dpdir 정도의 이름으로 만들어진 것을 사용하면 됨


-- 일반 User로 Directory 생성시 필요 (system 은 기 보유) 

SQL> GRANT CREATE ANY DIRECTORY TO SYSTEM ;   

-- 원하는 Directory 생성

SQL> CREATE DIRECTORY tran_pump AS '/app/oracle/admin/ogg25/tran_pump' ; 

-- DIRECTORY 에 개별권한 부여

SQL> GRANT READ, WRITE ON DIRECTORY tran_pump TO SYSTEM ;  

-- 일반 User로 추출/적재 시 필요 (system 은 이미 권한이 있음}

SQL> grant EXP_FULL_DATABASE, IMP_FULL_DATABASE to SYSTEM ;  


  B. Datadump 명령어로, 해당 Data 를 OS File 형태로 추출

  

  -- 추출대상 Object 확인 : 하단 참조

  

  -- 새로 생성한 tran_pump 에 Data 를 추출/적재

  -- tran_pump 이름의 directory 에 dumpfile 이 생성됨

  

[/home/oracle]$ expdp system/oracle directory=tran_pump schemas=BIGDATA01 job_name=bigdata01_expdp dumpfile=src_schema_bigdata01.dmp logfile=src_schema_bigdata01.expdp.log


[/app/oracle/admin/ogg25/tran_pump]$ du -hs *

5.1G    src_schema_bigdata01.dmp      -> 14:13:13 소요됨, tran_pump 란 directory 에 생성됨

12K     src_schema_bigdata01.expdp.log

[/app/oracle/admin/ogg25/tran_pump]$ 

  C. FTP 로 타켓서버로 전송 : 생략

  

  D. Datadump 명령어로, 해당 OS File 을 DB에 적재 

  

** 주의사항

     -- 사전에 적재 될 Schema 는 이미 만들어 두어야 함

     -- 이미 생성하지 않으면, 적재 시 생성하나 (동일 DB서버에 복구 하는 경우가 아니라면) 이미 생성해 두어야 함

     -- 적재된 Tablespace 에도 충분한 공간이 확보되어 있어야 함


SQL> drop user bigdata02 cascade ;          -- 해당 Schema 가 이미 있는 경우, 삭제하고 재생성 필요

SQL> create user bigdata02 identified by bigdata02

        default tablespace tmp_data

        temporary tablespace temp ; 

SQL> grant resource, connect to bigdata02 ; 

SQL> grant dba, sysdba to tranm ;          -- TRANManager DB User 에는  dba, sysdba 권한도 추가로 부여 


 ** 만약 impdp 가 퍼미션 문제로 실행되지 않는다면 SYSDBA 로 로그인한 후, 아래 Query 를 실행한 후 재시도.

SQL> execute dbms_metadata_util.load_stylesheets ;

-- 아래 명령어로 적재

-- 추출하는 Schema 와 적재되는 Schema 가 다른 경우 REMAP_SCHEMA 사용해야 함

-- 소스DB 의 Tablespace 명이 타켓DB에서 달라지는 경우, REMAP_TABLESPACE 를 사용해야 함


[/home/oracle]$ impdp system/oracle directory=tran_pump job_name=bigdata01_impdp dumpfile=src_schema_bigdata01.dmp logfile=src_schema_bigdata01.impdp.log REMAP_SCHEMA=bigdata01:bigdata02

    

 


8. 관련 Query 


  A. 추출 대상 Schema 의 Object 정보 사전 확인


SQL> set linesize 350  

SELECT DB.NAME DBNAME

, USERNAME

        , NVL(ROUND(SUM(CASE WHEN SEGMENT_TYPE LIKE 'INDEX%' THEN NULL ELSE BYTES END)/1024/1024/1024,1),-1) TABLE_SIZE

, NVL(ROUND(SUM(CASE WHEN SEGMENT_TYPE LIKE 'INDEX%' THEN BYTES ELSE NULL END)/1024/1024/1024,1),-1) INDEX_SIZE

, COUNT(B.SEGMENT_NAME) SEGMENT_COUNT

, MAX(C.OBJ_CNT) OBJECT_COUNT

FROM DBA_USERS A

INNER JOIN

(SELECT NAME FROM V$DATABASE) DB

ON 1=1

LEFT OUTER JOIN DBA_SEGMENTS B

ON A.USERNAME=B.OWNER

AND SEGMENT_NAME NOT LIKE 'BIN%'

LEFT OUTER JOIN (SELECT OWNER OWNER2,COUNT(*) OBJ_CNT FROM DBA_OBJECTS GROUP BY OWNER) C

ON A.USERNAME = C.OWNER2

WHERE A.USERNAME IN ('BIGDATA01')

GROUP BY DB.NAME,USERNAME

ORDER BY USERNAME  


SQL> /


DBNAME    USERNAME                       TABLE_SIZE INDEX_SIZE SEGMENT_COUNT OBJECT_COUNT

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

OGG25     BIGDATA01                             4.7        1.4           126          134


SQL> 


select owner, object_type, count(1)

  from dba_objects 

 where owner in ('BIGDATA01') 

 group by owner, object_type

 order by owner, object_type


OWNER           OBJECT_TYPE           COUNT(1)

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

BIGDATA01       INDEX                       42

BIGDATA01       PACKAGE                      1

BIGDATA01       PACKAGE BODY                 1

BIGDATA01       PROCEDURE                    3

BIGDATA01       SEQUENCE                     1

BIGDATA01       TABLE                       84

BIGDATA01       VIEW                         2


7 rows selected.

SQL> 



9. 참조 사례/셈풀


  A. 추출 하지 않고, 생성될 dump file 의 Size 만 계산 : estimate_only 사용 

  

    -- 다음 옵션으로 expdp에 사용되는 공간을 추정할 수 있다.

$ expdp dpumpuser/dpumpuser full=y estimate_only=Y

  


  B. 추출/적재 시 병렬처리 하는 경우 : %U 를 사용


    -- parallel 파라메터는 몇 개의 스레드로 병렬 처리 할 것 인지 지정한다.

# expdp hr/hr tables=paratest directory=data_pump_test dumpfile=paratest%U.dmp parallel=4 job_name=parr_test;


    -- paratest01.dmp, paratest02.dmp, paratest03.dmp paratest04.dmp => 4 개의 파일이 생성된다.

# impdp hr/hr directory=data_pump_test dumpfile=paratest%U.dmp job_name=parr_test;


  C. 추출 시, 특정 Schema 데에터만 추출


    -- 특정 스키마의 구조와 데이터 추출 : schema 를 사용

$expdp dpumpuser/dpumpuser schema=PORTAL directory=data_pump dumpfile=portal_schema_20081031.dmp


  D. 추출 대상 정하기 - Metadata 만을 추출하거나, Table 의 Data 만 추출하는 경우 : content 를 사용

  

    -- content를 사용해 특정 스키마의 데이터만 추출 (all 전체 | metadata_only 껍데기만 | data_only table의Data만 ) 

$expdp dpumpuser/dpumpuser schemas=PORTAL content=data_only directory=data_pump dumpfile=portal_schema_data_20081031.dmp

  E. 적재 시, Schema 및 Tablespace 가 변경되는 경우 : REMAP_XXXXX 사용

    -- 데이터 파일, 테이블 스페이스, 유저는 각각 다음의 옵션으로 변경할 수 있다.

REMAP_DATAFILE='C:\user01.dbf':'/usr/data/user01.dbf'

REMAP_TABLESPACE='users':'user'

REMAP_SCHEMA=scott:stralth

    -- TABLESPACE 변경이 여러개인 경우, "," 를 구분자로 필요한 만큼 기술 가능

    --  ex) impdp system/oracle directory=datapump dumpfile=scott.dmp remap_tablespace =users1_data:users2_data, users1_index:users2_index schemas=scott;

 

  F. 적재 시 이미 Table 이 존재하는 경우 선택 가능 : table_exists 사용


$ impdp dpumpuser/dpumpuser table_exists_action=truncate directory=data_pump dumpfile=portal_schema_data_20081031.dmp  

    -- table_exists_action 옵션 사용, 기존의 데이터를 truncate 하도록 (skip | append | truncate | replace)

skip      : 존재하는 오브젝트에 대해 임포트 스킵

append : 기존 오브젝트에서 업는 행만을 임포트

truncate : 기존 테이블 truncate

replace : drop & recreate 



//-- 2012.04.18. 초안작성
//-- 2012.05.07. 수정 

 

1. CDC 제품을 활용한 Oracle DB 실시간 Migration 개념

 

  Source 시스템을 운영하는 동안 Source DB 을 백업 받아서 Target 시스템을 구축하고 구축하는 동안 Source 시스템에 유입된 변경 데이터를 정합성에 어긋남이 없이 Oracle GoldenGate 을 이용하여 작업을 하게 됩니다.

 

 

1.      GoldenGate 변경 데이터 추출 시작

2.      Source DB 백업

3.      백업 데이터를 Target DB 에 적용

4.      추출된 변경 데이터 Target DB에 적용

5.      APP 에서 기존 Source 시스템에서부터 신규 Target 시스템으로의 Connection 을 변경

 

Zero Down-Time Migration 에서 Source DB Backup Target DB Recovery 그리고  Oracle GoldenGate 을 이용한 데이터 복제는 아래와 같은 방법으로 진행됩니다.

 

 

본 간략 절차 사례에서는, 소규모 Size Oracle DB exp/imp dump 를 이용해 Target DB 로 옮겨 실시간 DB 동기화를 구성하는 방법으로 Zero Down-Time Migration 을 구현해 보았습니다.

 

2. Zero Down-Time Migration 실례 (간략 절차)

 

 

Source DB

Target DB

Step 1

CDC(Change Data Capture)를 위한 Oracle Golgdngate 설치 (DB 무 중단)

Step 2

Goldengate 변경 분 추출 Process (extract) 시작

 

Step 3

SCN 기반 데이터 추출 (expdp)

 

Step 4

 

추출된 데이터 DB 에 적재 (impdp)

Step 5

 

Goldengate 변경 분 반영 Process (replicat) 시작

Step 6

CDC(Change Data Capture) 기반, DB 동기화(sync) 중인 상태

 

2-A. Change Data Capture 를 위한 Oracle Golgdngate 설치

 

  Oracle 사의 CDC 제품인 Goldengate 제품을 설치합니다. 설치를 위한 Requirement Installation 과정은 이 문서에서는 생략하겠습니다.

 

2-B. Source DB 에서 Goldengate 변경 분 추출 Process (extract) 시작

 

가.   GGSCI 에서 해당 extract pump 를 시작해 Data 변경분을 추출 시작하기

 

GGSCI> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING                                           

EXTRACT     STOPPED     EXTORCL     00:00:02      00:00:07   

EXTRACT     STOPPED     PMPORCL     00:00:04      00:00:03

GGSCI> start *ORCL

GGSCI> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING                                          

EXTRACT     RUNNING     EXTORCL     00:00:02      00:00:01   

EXTRACT     RUNNING     PMPORCL     00:00:01      00:00:02

GGSCI>

 

    역시, 이 문서가 Goldengate 제품 자체에 대한 문서는 아니기 때문에, 자세한 내용들은 생략하겠습니다.

 

2-C. Source DB 에서 SCN 기반 데이터 추출 (expdp)

 

가.   Long Transaction 유무를 확인하고, SCN 을 추출해 둡니다.

 

SQL> select min(start_time) from v$transaction ;

 

MIN(START_TIME)

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

                                             ---> 현재 수행중인 Transaction 이 없음

SQL> col a format 99999999999999999999

SQL> select dbms_flashback.get_system_change_number a from dual ;

 

                    A

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

       12478584165405                       ---> 추출 시점의 SCN 값 입니다.

 

SQL> select min(start_time) from v$transaction ;

 

MIN(START_TIME)

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

---> 현재 수행중인 Transaction 이 없음

SQL>

 

v$transaction 에 수행 중인 transaction 이 있더라도 상관 없습니다. 다만 수행중인 Transaction start_time 을 비교해서, 계속 변경되고 있는지 기존에 수행 중인 Transaction 이 종료 되고, 새로운 transaction 이 시작되었는지 확인 할 필요는 있습니다.

 

나.   Export dump 를 사용해, Source DB 해당 data 를 추출

 

Oracle ] expdp userid=\"system/password_of_system as sysdba\" job_name = 120418_boro_pm_exp dumpfile = 120418_boro_pm_exp.dmp logfile = 120418_boro_pm_exp.log schemas = SEI_PM flashback_scn = 12478584165405

 

    Oracle 10g 이상에서는 exp/imp 보다 속도 등이 개선된 exp dump가 지원됩니다. 이 사례에서는 특정한 DB User (SEI_PM) 의 모든 DB Data 120418_boro_pm_exp.dmp 이라는 OS File 로 추출한 것이고, flashback_scn 값을 앞서 dbms_flashback 을 통해 추출한 값으로 입력합니다.

    Dmp file 이 생성되는 기본 위치는 $ORACLE_BASE/admin/SID/dpdump 입니다.

 

    File 생성이 완료되면, Target DB dmp file 을 전송합니다. 보통은 compress ftp 를 이용합니다.

 

2-D. Target DB 로 추출된 데이터 DB 에 적재 (impdp)

 

가.   보통, 아래와 같이 간단히 DB에 적재할 수 있습니다. 해당 DB Schema 를 먼저 만들어 주어도 import 에 문제가 없습니다.

 

Oracle ] impdp userid=\"system/password_of_system as sysdba\" job_name = 120418_boro_pm_imp dumpfile = 120418_boro_pm_exp.dmp logfile = 120418_boro_pm_impdp.log

 

나.   다만, 여러 개의 Source DB 에서 1개의 Target DB DB Data 병합하는 경우, temp schema 를 통해 필요한 Data 만 적재할 수도 있습니다. 아래의 Query 를 참조하세요

 

2-D.-1. Temp Schema 를 사전에 생성합니다.


SQL> drop user tmp_sei_pm cascade ;

SQL> create user tmp_sei_pm identified by password_of_tmp_sei_pm default tablespace TMP_SEI_PM temporary tablespace TEMP_FIELD ;

SQL> grant resource, connect, dba to tmp_sei_pm ;

 

2-D.-2. Source DB 에서 추출한 Data Temp Schema 로 임시로 적재합니다


Oracle ] impdp userid=\"system/password_of_system as sysdba\" job_name = 120418_boro_pm_imp dumpfile = 120418_boro_pm_exp.dmp logfile = 120418_boro_pm_impdp.log remap_schema=sei_pm:tmp_sei_pm

    마찬가지로, 기본 위치는 $ORACLE_BASE/admin/SID/dpdump 입니다

 

2-D.-3. 임시로 적재된 Data 에서, 필요한 Data 만을 실 사용할 Schema 로 적재

 

실제 사용할 Schema 로 적재할 때는, 해당 시나리오에 따라, 특정 코드값의 Data 만을 삭제 하거나, 특정 코드값의 Data 를 제외하고 삭제, 특정 코드값에 해당하는 rows 만을 insert 하는 경우 등이 있겠습니다. 이 때 사용될 Query 들은 아래와 같습니다.

 

SQL> create table SEI_PM.PM_P_AREA as select * from TMP_SEI_PM.PM_P_AREA where job_no = 'SC2222' ;

SQL> delete SEI_PM.PM_P_AREA   where job_no <> 'SC2222' ;

SQL> insert into SEI_PM.PM_P_AREA         select * from TMP_SEI_PM.PM_P_AREA       where job_no = 'SC2222' ;

SQL> delete SEI_PM.PM_P_BM      where job_no = 'SC2222' ;

 

2-E. Target DB 에서 Goldengate 변경 분 반영 Process (replicat) 시작

 

GGSCI> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING                                           

REPLICAT     STOPPED     R_ORCL11     00:00:02      00:00:07   

REPLICAT     STOPPED     R_ORCL12     00:00:04      00:00:03

GGSCI> start replicat r_orcl11, aftercsn 12478584165405

GGSCI> start replicat r_orcl12, aftercsn 12478584165405

GGSCI> info all

Program     Status      Group       Lag           Time Since Chkpt

MANAGER     RUNNING                                          

REPLICAT     RUNNING     R_ORCL11     00:00:02      00:00:01   

REPLICAT     RUNNING     R_ORCL12     00:00:01      00:00:02

GGSCI>

 

3. CDC 제품(Oracle Goldengate)을 활용한 Zero Down-Time Migration 활용 사례들

 

      Oracle GoldenGate 을 운영하기 위해서 초기 데이터 구축을 위해서 사용

  - Source DB 에서 Target DB 로 데이터를 동일하게 일치 시키는 Initial Loading 작업

  - OGG을 이용한 조회 시스템, ODS/DW, 비상 시스템, 타 시스템 연계 시 사용

      System/DB 업그레이드 시 연속적인 서비스를 진행하기 위해서 사용

  - System 증설 또는 DB 버전 Upgrade 시 서비스 연속성 보장

      주 시스템의 PM 작업 (Planned Outage, Unplanned Outage) 시 사용

  - 주 시스템에 대해서 장시간 작업을 진행하기 위하여 임시 시스템에서 서비스의 연속성 보장

  - 주 시스템의 작업 완료 후 임시 시스템으로부터 주 시스템으로 서비스의 연속성 보장

      주 시스템/DB 을 이기종으로 변경하기 위해서 사용

  - 주 시스템의 H/W 또는 OS, DB 등을 이기종으로 변경 시 서비스의 연속성 보장


End of document.

+ Recent posts