Data Propagator Relational ( DpropR)

Agenda

I. IBM DB Data Propagator Relational (DpropR)소개

II. Data 복제의 개념

1. Data 복제 Process의 2가지 형태

2. DpropR Architecture

3. DpropR 의 구성 요소들

4. DpropR 의 기본 용어

5. Target Table Type의 종류 및 특징

6. 복제 복사 작업 (subscription) 정의

7. Data Repliaction 실행시 필요한 사전 작업

III. Replication Process

1. 복제 Source 정의

2. Subscription (복제 작업 정의)

3. Capture Process Start

4. Apply Process Start

IV. 복제 작업 정의 및 실행 예제

부록.

I. IBM DB2 Data Propagator Relational (DpropR) 소개

Data 복제는 여러 위치에서 정의된 데이터 세트를 유지보수하는 프로세스입니다.

여기에는 한 위치(Source DB)에서 다른 위치(Target DB)로의 지시된 변경사항

복사와 두 위치에서의 데이터 동기화 작업이 관련됩니다. Source DB 와 Target DB 는

분산 네트워크에서 같은 machine 이나 다른 machine 에 있는 (DB2 UDB

데이터베이스나 OS/390 서브시스템 과 같은) 논리 서버에 있을 수 있습니다.

IBM 의 여러 제품은 사용자가 데이터를 복제할 수 있게 합니다. 이 다큐먼트의 중심이

되는 제품(DB2 DataPropagator)은 데이터 복제를 위한 복제 제품입니다. 이를

사용하여 DB2 관계형 데이터베이스들 사이의 변경사항을 복제할 수 있습니다. 또한,

다른 IBM 제품(예: DB2 DataJoiner 및 IMS DataPropagator)이나 타사 제품(예:

Microsoft SQL Server 및 Sybase SQL Server, Oracle, Informix 등)과 함께

사용하여 커져가는 여러 데이터베이스 제품(관계형 및 비관계형) 사이에 데이터를

복제할 수도 있습니다.

II. Data 복제의 개념

1. Data Replication (복제) Process 의 2 가지 형태

1. Refresh 방식

A. Target Data 를 지정된 Source Data 로 완전히 대체하는 방식

(Replacement)

B. 단순한 Data 의 Export, Import 과정이므로 개념이 간단하고 사용하기

쉽다.

C. 적은 양의 Data 복제시에 적합하다.

2. Update 방식

A. Source Data 의 변경된 부분이 비동기적으로 (Asynchronous) Target

Data 에 적용되는 방식

B. Source Data 가 비교적 용량이 커서 Refresh 의 형태로 이동하기

곤란하며, 전제 Data 중 변경되는 부분은 적으나, 횟수가 높을 경우

적용하기 적합하다.

C. Source DB 의 update 된 부분만을 복제하므로 개념상 historical Data

를 지원한다.

DpropR 은 Refresh 및 Update 방식을 모두 사용하며, 일반적으로 Update

방식에서의 Data 복제에 적합한 Tool 이다.

2. Data Propagator Relational (DpropR) Architecture

그림 1. DpropR Architecture 및 구성 component

Source DB에는 각각 복제 대상이 되는 Source Table과 Source DB의 log,

Capture Process 및 DpropR Control Tables가 존재한다.

Target DB에는 복제 적용 대상이 되는 Target Table과 변경된 Data를 Target

Table과 복사하는 Apply Process가 존재한다.

Source DB 및 Target DB사이의 전체적인 Process 및 작업의 관리는 DB2

UDB 제어센터를 통해서 이루어진다.

3. Data Propagator Relational (DpropR) 구성 요소들

1. Source DB

Log 또는 DB2/400 Journal

Source Table의 변경 사항 및 이와 관계된 정보는 DB log에 기록

된다

Capture Process

Capture는 Log로부터 변경된 record 및 이와 관계된 정보를 read

하여 Source DB상의 Staging Tables (CD Table, Unit or Work

Table) 에 기록한다.

Control Tables

Capture에 의해 변경된 data 정보가 기록되는 CD Table 및 UOW

Table 및 그와 관련된 추가적인 Tables가 Source DB상에 있다.

그림 2. Source DB내 DpropR 구성 요소들의 Process

2. Target DB

Apply Process

1. Apply는 Source DB의 Base (Source) Table로부터 전체 Data를

복사하여 Target Table을 구성한다. (Refresh 방식의 Data 복제)

2. Apply는 Source DB의 Staging Tables (CD, UOW Table)로부터

변경된 Data 만을 복사하여 Target Table에 적용한다. (Update

방식의 Data 복제)

Control Tables

Source Table 과 Target Table의 mapping 및 Apply의 작업과

관련된 Control Tables가 Target DB상에 존재한다.

그림 3. Target DB내 DpropR 구성 요소들의 Process

4. Data Propagator Relational 의 기본 용어

Source Server : Source Table이 위치한 DB (또는 이의 machine)

Target Server : Target Table이 위치한 DB (또는 이의 machine)

Control Server : Apply Process의 Control Table이 위치한 DB (또는 이의

machine) – Control Server는 Source 또는 Target에 위치할 수 있으나,

Target의 경우가 일반적임

Subscritption : Source Table과 Target Table의 mapping 정보 및 이를

설정하는 작업

5. Target Table Type의 종류 및 특징

1. User Copy

Base Table의 column, row의 전부 또는 일부분의 update를 복사하여

Target Table 구성. 가장 일반적인 경우의 구성 방식이다.

2. Point-in-time Copy

User Copy와 같은 형태나, 추가로 timestamp column이 추가된 형태의

Target Table 구성

3. Staging Copy

Base Table의 column, row의 전부 또는 일부분의 update를 복사하여

중간 단계의 Staging Table (CCD Table)을 구성하며, CCD Table로부터

또다른 Apply Process에 의해 또다른 위치의 Target Table을 구성할 수

있는 형태

CCD Table (Consistent Change Data) : User Copy와 같은 방식으로

구성된 Target Table에 4개의 추가적인 column이 추가된 형태의 Target

Table

4. Base Aggregate Copy

Base Table의 요약 data로 구성된 Target Table. Source Table에 대한

column function의 output data로 Target Table을 구성하며, 이는 계속

적으로 쌓이는 (appended) 형태이다. 따라서 Capture Proceess에 의해서

Log로부터 Source Data을 read하는 방식이 아니라, Source Table 자체

가 Apply Process의 input이 된다.

5. Change Aggregate Copy

CD (Changed Data) Table의 요약 data로 구성된 Target Table. Base

Aggregate 형식의 Target Table과 같으나, Apply Process의 input

Table이 Source Table이 아니라, CD Table이 된다. 즉, CD Table에 대

한 column function의 output data이 계속적으로 쌓이는 (appended)

형태로 구성되는 Target Table

6. Replica Copy

User Copy와 같은 형태의 Target Table이나, 이 Target Table에 대한

update가 다시 기존의 Source Table로 복제되는 “Update Anyware

Replication” 복제 방식에서의 Target Table 형태

참고. 1 User Table과 Point-in-time Table에서는 반드시 Primary Key가 필요

하며, CCD Table에서는 경우에 따라 필요할 수 있다.

6. 복제 복사 작업 (Subscription) 정의

subscription 정의 : 하나 또는 그이상의 Source Table과 Target Table사이의

관계(relationship)에 대한 정의의 집합 (set)

각각의 정의는 subscription member가 되며, 연관된 정의는 Group

을 이룰 수 있다.

사용자에 의해서 정의되며, Apply Process가 이의 내용에 따라

작동한다.

Subscription 정의 항목들

1. Name: 18자이하로, 각 subscription에 대한 유일한 (Unique) 이름으로

명명한다.

2. Apply Qualifier : Apply Program의 Unique instance로 명명하며,

Apply Process 실행시 반드시 입력하여야 할 parameter이다.

(반드시 대문자로 지정되어야 한다.)

3. Target Table Name 및 Create Table, Advanced option : Target Table

을 새롭게 구성할 경우 이의 이름(schema 포함) 및 Target Table

Type을 정의하고, 이의 구성 column (before image data에 대한

column 포함) 및 primary key, Source Table의 원하는 Row를

거르기 위한 predicate을 설정할 수 있다.

4. Timing : Subscription set이 적용될 timing은 시간별 또는 특정 event

별로 지정할 수 있다. Timing에 대한 특정 interval을 두고

지속적으로 Apply Process가 동작하는 시간을 설정한다.

7. Data Repliaction 실행시 필요한 사전 작업

그림 4. DpropR 의 운영 Process Cycle

DPropR은 위와 같은 Process cycle을 거쳐서 운영되며, 실제 운영되기 전에

사전에 이루어져야할 사전 작업은 다음과 같다.

1. Capture 및 Apply Program Binding

Capture, Apply 프로그램이 해당 DB에서 작동하기 위해서는 각각

의 bind file이 DB에 bind하는 과정이 필요하다. 각 bind file의 위

치는 $DB2INSTANCE HOME/sqllib/bnd 위치에서 찾을 수 있다.

Capture Program Binding : 해당 디렉토리로 가서 DB2CLP 화면에

서 다음과 같이 입력한다.

“db2 connect to SOURCE_DB”

“db2 bind @capture.lst isolation ur blocking all grant public”

cf) .lst file은 각 bind file들의 list이며 이를 bind하기 위해서는

해당 file 이름 앞에 @를 붙인다.

Apply Program Binding : 해당 디렉토리로 가서 DB2CLP화면에서

다음과 같이 입력한다.

“db2 connect to SOURCE_DB”

“db2 bind @applyur.lst isolation ur blocking all grant public”

“db2 bind @applycs.lst isolation cs blocking all grant public”

마찬가지의 작업을 Target DB에 대해서도 수행한다.

“db2 connect to TARGET_DB”

“db2 bind @applyur.lst isolation ur blocking all grant public”

“db2 bind @applycs.lst isolation cs blocking all grant public”

2. Control Tables 생성 (Optional)

Capture 및 Apply에서 사용되는 Control Tables은 일반적인 UDB

운영 체제에서는 최초 복제 Source 및 Subscription 정의시 해당

DB에 자동적으로 생성이 되나, OS/400 등과 같은 일부 운영체제

또는 해당 Control Tables에 대한 내용을 Customization하고 싶을

경우에는 다음의 절차를 따른다.

A. $DB2INSTANCE_Home/sqllib/samples/repl 디렉토리에서

“DPCNTL.XXX” file을 찾는다. (XXX는 운영체제에 따라

UDB, MVS, VM 등이 있다.)

B. 해당 File은 DDL 스크립트이므로 DB2CLP에서 다음과 같이

실행하면 된다.

“db2 –svtf DPCNTL.UDB”

(Customization 작업은 스크립트의 내용을 수정함으로써 이루

어진다.)

3. Password File 생성

다음 조건이 아닌 경우, Apply Process가 제대로 수행되기 위해서는

Apply가 수행될 Working Directory에 Password File을 생성하여야

한다.

DB2 Source DB가 “Authentication=client”로 Catalog되어 있는

경우, MVS CPI-C 노드에 대해 SECURITY=SAME으로 설정되어 있

는 경우, Apply Process를 실행할 Subscriber ID가 root 권한을 가

지고 있거나, 시스템 그룹에 속할 경우

위 조건에 해당하지 않는 경우 Password File을 생성한다.

Password File의 이름은 다음과 같이 Naming 되어야 하며, Apply

프로그램을 수행하는 사용자 ID는 Source 및 Target DB에 대해 접

속할 수 있는 권한 (최소 DBADM 이상)이 있어야 한다.

Passw1ord File의 Naming 규칙 :

<Apply_Qualifier><DB2Instance_Name><Target_DB_Name>.P

WD

Password File의 내용은 다음의 예와 같다.

Ex) QUAL01DB2COPYDB.PWD

내용:

SERVER=TARGET_DB USR=TARGET_ID PWD=PASSWD2

SERVER=SOURCE_DB USR=SOURCE_ID PWD=PASSWD1

4. Database Logging 방식 check

Capture는 해당 Source DB의 Log를 read하여 동작하며, 해당 DB의

Logging 방식은 Archive Logging 방식이어야 한다. 따라서 Circular

Logging 방식의 Source DB는 Archive Logging 방식으로 바꾼 후,

DB를 backup 받아야 추후 Capture Proecess를 진행할 수 있다.

해당 Source DB의 Logging 방식은 DB2CLP에서 다음의 명령문으로

확인할 수 있다.

“db2 get db cfg for SOURCE_DB | more”

DB의 구성 변수 값중 “LogRetain=RECOVERY”나

“UserExit=OFF”의 값인지를 확인한다. 둘중의 하나라도 그렇지 않

을 경우 다음의 명령문을 입력하여 해당 변수 값을 조정다.

“db2 update db cfg for SOURCE_DB using LOGRETAIN ON”

또는

“db2 update db cfg for SOURCE_DB using USEREXIT OFF”

참고) DB 전체에 대한 구성 변수 값을 변경하는 것이므로, 변경 사

항을 적용받기 위해서는 해당 DB에 연결되어 있는 모든 어

플리케이션이 연결 해제되어야 하며, Loggng 방식이 바뀌었으

므로 해당 DB는 backup pending에 걸리게 된다. 따라서, DB를

backup 받아야 추후에 DB 연결을 할 수 있다.

III. Replication Process

그림 4. 에서 보았던 경우처럼 각각의 Process에서 실행 방법을 살펴보면

각각 다음과 같다.

1. 복제 Source 정의

복제 Source의 정의는 UDB 제어 센터에서 이루어진다.

그림 5. DB2 UDB 제어 센터에서의 복제 Source 정의 화면

위의 그림에서는 SRCDB의 Employee TABLE을 복제 소스로 정의하는 모습을

보여주고 있다. 복제하고자 하는 대상을 point하고 오른쪽 마우스를 click하면 위의

화면과 같은 pop-up 메뉴가 등장한다. 여기서 “복제 소스로 정의 – 사용자 정의”를

선택한다.

그림 6. 복제 소스 정의 화면

앞의 “복제 소스 정의” 선택 창에서 “사용자 조정”을 선택하면 선택한 복제 소스에 대해

위와 같은 화면이 등장한다.

위의 예에서는 “db2admin.employee”라는 table을 복제 소스로 정의하여, 모든

column에 대해서 After Image를 Capture하는 것으로 정의하였으며, EMPNO,

WORKDEPT, PHONO column에 대해서는 Before Image까지도 DB log에서

Capture하는 것으로 정의하였다. 따라서 이의 복제 Source에 대한 Target Table

구성시 Before Image에 대한 column을 추가하여 구성할 수도 있다.

그림 7. SQL 스크립트로의 저장 또는 바로 수행 화면

참고 ) 일반적인 경우, 해당 작업 내용을 SQL script로 file로 저장하여 그 내용을

사용자의 환경에 맞게 수정하는 것이 바람직하다. 수정 내용의 가장 중요한

부분은 생성될 CD Table의 이름을 사용자가 알아보기 쉽게 naming하는 것

이며, 이는 별다른 수정을 하지 않았을 경우 DB2 UDB가 생성하는 CD

Table의 이름이 CD20000926580860과 같은 timestamp값과 관련된 형태

로 지정되어 복제 Source를 여러개 지정하였을 경우, 해당 복제 Source와

CD Table사이의 관계를 복잡하게 할 수 있기 때문이다. 따라서 SQL script

로 저장하여 CD Table의 이름을 복제 Source Table 이름과 연관되게 작성

하여 나중의 Table 관리를 쉽게 하는 것이 바람직하다. 또한 CD Table이

저장될 특정 Tablespace를 지정하여 각 CD Table을 관리할 수 있다.

복제 소스에 대한 정의 작업이 끝난 후 “확인” 버튼을 누르면 위와 같이 수행 시기를

묻는 화면이 등장한다.

그림 8. 복제 소스 정의의 정상적인 수행 결과 화면

성공적으로 복제 Source 정의가 수행되었을 때의 최종 화면은 위와 같으며, 복제

소스가 제대로 생성되었는지는 제어 센타의 “복제 소스”를 “갱신”함으로써 확인 할 수

있다.

그림 9. DB2 UDB 제어 센터에서의 복제 소스 확인

참고 ) 위와 같은 복제 Source 정의는 위와 같은 수동적인 방법에 의해서 정의할

수도 있으나, 미리 정의된 default 값을 사용하여 정의할 수도 있다. 이는

복제 소스 정의 tab에서 “사용자 조정”이 아닌 “복제 소스로 정의 – 빠

른 정의”로 선택하여 작성한다. 빠른 정의에서 사용될 default 값은 다음

화면에서와 같이 제어 센터의 “도구 - 도구 설정”의 복제 tab에서 값을

지정하여 사용할 수 있다. 이는 정형화된 복제 작업의 복제 Source 선택시

매우 간편하게 사용될 수 있다.

참고 ) 복제 Source을 정의하는 SQL 스크립트의 내용을 들여다 보면, Source

Table이 “DATA CAPTURE CHANGES”라는 항목으로 “altered” 되었 을

확인할 수 있다. (즉 Employee Table에 대해 수동으로 “db2 ALTER

TABLE EMPLOYEE DATA CAPTURE CHANGES” 명령을 수행한 것과

같다.) 이렇게 함으로써 Source Table에 변경이 이루어졌을 경우, DB2는

이에 관한 부가적인 정보를 DB2 Log에 기록하며, 이 정보는 Capture

Process가 작동시에 사용된다.

2. 복제 작업 (Subscription) 정의

1의 복제 Source 정의 작업이 끝나면 Subscription 정의를 할 수 있다.

그림 10. DB2 UDB 제어 센터에서의 Subscription 정의 화면

앞의 1에서 정의한 employee Table에 대해 오른쪽 마우스를 클릭하여 “복사 작업

내역 정의”를 선택한다.

그림 11. Subscription 정의 main 화면

위의 화면은 복사 작업 내역 (Subscription) 을 정의하는 main 화면이다.

“변경” 단추를 선택하여 Target Table의 이름을 “EMP_COPY”로 변경하여 새로운

Table을 생성하도록 정의하였다.

그림 12. Subscription 고급 작업 내역 정의

앞의 화면에서 “고급” 버튼을 선택하면 위와 같은 화면이 나타난다. 여기서 Target

Table의 Type과 Target Table의 Column 및 Source Table에서 선택할 수 있는 Row

에 대해서 각각 정의할 수 있다. 여기서는 Target Table의 Type을 가장 일반적인 User

Copy (사용자 복사)로 선택하였다.

그림 13. Subscription 목표 컬럼 정의 화면

Target Column을 정의하는 항목에서는 이전의 복제 Source 정의에서 EMPNO,

WORKDEPT, PHONO Column에 대해서는 After Image 뿐만 아니라 Before Image

도 Capture하는 것으로 선택하였으므로, Target Table의 column 생성 정의 화면에서

이를 반영하여 각 column이 만들어졌다. 그 중에 WORKDEPT, PHONO Column

만을 생성하여 각각의 Before Image의 값을 저장하도록 정의하였다.

그림 14. Subscription 행 정의 화면

Row에 대해서는 Source Table의 Row 중 EMPNO가 300번 미만인 경우를 where

조건절의 predicate으로 지정하여 Target Table의 data를 구성하도록 설정하였다.

그림 15. Subscription 시간 제어 정의 화면

Subsciption 정의 main 화면에서 “시간 제어”를 선택하면 위와 같은 시간 및 Event를

정의하여 Apply Process의 실행 timing을 제어할 수 있다.

위에서는 시간으로 Apply Process를 제어하며, 5분의 의미는 Apply Process가

Subscription에 정의된 member (현재는 employee Table 1개)에 대한 처리가

끝나면 5분동안 비활성화 된 후에, 다시 Subscription 정의 작업을 실행하라는 실행

cycle사이의 interval을 설정한 것이다.

그림 16. Subscription SQL 정의 화면

Subsciption 정의 main 화면에서 “SQL...”를 선택하면 위와 같은 화면이 나타난다.

여기서는 Apply Process의 실행 전후에 Target Table 또는 Source Table에 대한

SQL 작업 (또는 Stored Procedure 실행)을 정의하고, 해당 SQL 및 Stored

Procedure를 지정할 수 있다. 또한 수행 후의 SQLSTATE값을 지정하여 이 값에 따른

처리 Logic을 추가 할 수도 있다.

그림 17. Subscription 최종 정의 화면

앞서의 과정에서 모든 복사 작업 내역 (Subscription)을 정의하면, 정의 내용은 각

Control DB의 여러 관련 Control Table에 작업 정의가 저장된다. 여기서는 Control

DB를 Target DB인 COPYDB로 설정하였으나, Source DB 또는 또다른 DB에

지정하여 저장할 수 있다. 또한, 여기에서 실제로 정의 내용에 따라 Target Table을

작성할 DDL 및 관련 Script가 만들어지게 된다. 이를 File로 저장하여 나중에 실행할

수도 있으며, 바로 직접 수행할 수도 있다.

그림 18. Subscription 정의의 성공적인 실행 화면

앞의 화면에서 확인 버튼을 눌러서 정상적으로 실행이되면 위와 같은 화면이 나타나며,

Subsciption 정의 내역은 다음 화면에서처럼 제어판에서 확인 할 수 있다.

그림 19. DB2 UDB 제어 센터에서의 Subscription 정의 확인 화면

3. Capture Program 시작

그림 4. 에서 보았던 Replication Process Cycle 에서처럼, Capture 와

Apply Process가 구동하기 전에 Source Table 및 복제 복사 작업 (Subscription)

정의가 되어야 각 Process가 정상적으로 작동할 수 있다. Capture Process를

시작하는 명령 과정은 다음과 같다.

A. Capture Program 시작 명령

작업 과정 사용 예

1) Administrator UserID로 Login 한다. “db2admin”으로 login

2) DB2INSTANCE 환경 변수를 setting한다. “set DB2INSTANCE=db2admin”

3) DB2DBDFT 환경 변수를 setting 한다. “set DB2DBDFT=SRCDB”

4) ASNCCP parameter “asnccp trace cold”

4)의 asnccp 명령어에는 다음과 같은 parameter가 있다.

SOURCE SERVER (Source DB) : asnccp의 첫번째 parameter로 Source

DB를 입력 한다. Default 값은 DB2DBDFT의 값이다.

PRUNE / NOPRUNE : CD (Changed Data) 및 UOW (Unit of Work) Table

을 Pruning 하거나, 하지 않는다. Defautl값은 PRUNE이다.

TRACE / NOTRACE : Capture Process의 동작에 대한 Trace 메세지를

Standard Output으로 기록한다. Default값은 NOTRACE이다.

COLD / WARM / WARMNS : Capture Start에는 “Cold” Start와

“Warm” Start라는 2가지 종류가 있다. 최초의 Capture Process

Start 시에는 Cold Option을 사용하며, 이후의 실행에서는 WARM

Option을 사용하여 시작한다. Default 값은 WARM이다.

위의 사용 예(1, 2, 3)는 Windows 환경을 기초로 하였으며, AIX, Sun

Solaris, Linux와 같은 Unix 운영 체제에서는 각각 그에 맞는 command로

환경 설정을 하여준다. 1, 2, 3의 환경이 이미 설정되어 있는 상황에서라면

“ASNCCP parameter” 명령만을 사용하면 된다.

B. Capture Process의 Stop 및 Optional Command

이미 실행중인 Capture Process를 Stop하기 위해서는 “ASNCMD stop”이라는

명령어를 발행하며, stop 외에 다음과 같은 Optional Command가 있다.

ASNCMD STOP : Capture Process를 정지한다.

SUSPEND : 일시 정지 시킨다.

RESUME : 일시 정지된 Capture Process를 재시작한

다.

REINIT : Capture Process는 start 시에 참조하는

Control Table의 정보를 읽어서 Memory

보관하여 계속 사용한다. 이 Control Table의

정보를 강제로 다시 읽어서 Capture Process

가 수행되도록 하는 option이다.

PRUNE : CD, UOW Table에서 더이상 사용되지 않

는 불필요한 row를 삭제한다.

GETLSEQ : Capture Process에 의해서 마지막으로

수행된 Log Entry의 Sequence 번호를

가져온다. 이는 Capture가 Log의 어느

정도까지를 읽어서 수행했는가를 아는데

도움이 된다.

4. Apply Program 시작

Apply Process를 시작하는 명령은 다음과 같다.

A. Apply Process 시작 명령

작업 과정 사용 예

1) Administrator UserID로 Login 한다. “db2admin”으로 login

2) DB2INSTANCE 환경 변수를 setting한다. “set DB2INSTANCE=db2admin”

3) DB2DBDFT 환경 변수를 setting 한다. “set DB2DBDFT=TARGETDB”

4) ASNAPPLY parameter “asnapply QUAL01

COPYDB”

4)의 ASNAPPLY 명령어에는 다음과 같은 parameter가 있다.

Apply Qualifier : ASNAPPLY 명령의 1번째 parameter이다. Apply

Qualifier는 여러 개의 복제 복사 작업 정의(Subscription)를 그룹화

하여 특정 Apply Process에 의해서 실행되게 하기 위한 instance

이름과 같다. 즉, 위의 예에서처럼 발행한 Apply 명령어는 Apply

Qualifier “QUAL01”로 정의된 Subscription에 대해서만 Apply가

실행되며, “QUAL02”, “QUAL03”으로 정의된 Subscription에

대해선 실행하지 않는 것이다.

Control_Server : ASNAPPLY 명령의 2번째 parameter이다. Apply

Process가 동작시 참조할 control Server (Control Table이 저장된

Control DB)를 지정한다. 이는 이미 Subscription 정의시 지정되어

있으며, 여기서는Subscription에서 지정된 값과 일치시켜주면 된다.

보통의 경우 Subscription시 Target DB를 Control DB로 지정하는

일반적이다.

NOTRC / TRCERROR / TRCFLOW : Apply Process의 작동시 발생하는

error를 standard output으로 뿌려주는 option이다. TRCERROR는

Error Message만을 뿌려주며, TRCFLOW는 Error 메세지 및

Apply의 작동시 실행 내용을 함께 뿌려준다. Default값은 NOTRC

이다.

LOADX / NOLOADX : Apply Process의 일반적인 형태는 Table과 Table

사이의 Export, Import 과정을 거쳐서 Target Table을 구성하는 것

이다. 그러나 Target Table 구성을 Import 가 아닌 Load 의 형태

로 하게 되면 performance상의 이점을 기대할 수 있다. 이럴 때,

LOADX option을 사용하게 되면 Apply Process가 “ASNLOAD”

프로그램을 호출하여 Load 과정을 거쳐 Target Table을 구성한다.

Default 값은 NOLOADX이다.

B. 실행중인 Apply Process 의 중지

Apply Process가 실행되는 화면에서 “Control-C”로 Process를 중지하거나 asnapply

Process를 kill하면 된다.

IV. 복제 작업 정의 및 실행 예제

이제까지의 내용을 중심으로 실제 Table의 변경 내용을 복제하는 간단한 예제를 실행해

보도록 하자. DB2 UDB를 설치하게 되면 “SAMPLE” Database가 구축이 된다.

Sample DB의 Table 중 Employee Table과 Project Table을 대상으로 별도의 DB인

COPY DB에 복사 작업 정의를 하여 실제 변경된 내용이 update되어 Target Table을

구성하는 면을 살펴본다.

그림 20. DpropR 실행 예제의 데이타 복제 구성도

1. 작업 시나리오

RS/6000 System의 “Sample” Database의 Source Table인 Employee와

Project Table을 복제 소스로 정의한다.

Employee Table에 대해서는 User Copy, Project Table에 대해서는 CCD

Copy로 Subscrition을 정의하고 각 Table의 일부 Column에 대해서만 새롭게 Target

Table을 구성하는 것으로 정의한다.

2. 작업 절차

1) 복제 Source Table 정의

Employee Table을 “복제 소스 정의 – 사용자 정의”의 방식으로 복제 소스로

정의 한다.

Employee Table의 전체 컬럼 중 일부 컬럼 (MIDINIT, EDLEVEL, SEX...등)을

제외한 나머지 컬럼과 WORKDEPT, PHONO, JOB, SALARY에 대해서는

Before Image도 저장할 컬럼을 추가하여 Target Table의 전체 컬럼을

구성하도록 정의하였다.

참고) 여기서 실제로 Target Table의 구성을 저장하는 것은 아니고,

Capture Process가 수행할 Source Table의 컬럼 Data를 지정하는 것이

다. 따라서 다음 단계인 “복제 작업 정의(Subscription)”에서 구성할 실

제 Target Table의 컬럼 구성은 이와 같은 형태로 구성하는 것이 당연하

나, 반드시 서로 일치할 필요는 없다.

Project Table을 “복제 소스 정의 – 사용자 정의”의 방식으로 복제 소스로 정의

한다.

Project Table의 전체 컬럼과 일부 컬럼 (PROJNAME, RESPEMP, PRSTAFF,

PRSTDATE)에 대해서 Before Image도 저장할 컬럼을 추가하여 Target

Table의 전체 컬럼을 구성하도록 정의하였다.

정의된 각 복제 소스 Table을 확인한다.

2) 복제 복사 작업 (Subscription) 정의

A) Employee Table

“고급” 화면의 목표 유형 (Target Table Type) 탭에서 목표 테이블 유형을

“User Copy (사용자 복사)”로 선택한다.

“고급” 화면의 목표 컬럼 탭에서 목표 테이블의 컬럼을 다음의 그림과 같이

조정한다.

사용자 복사 방식의 Target Table에서는 반드시 Primary Key를

지정하여야 하며 EMPNO 컬럼에 대해서 지정하였다. 그리고, “복사 작업

내역”에는 복제 소스 정의시 정의하였던 모든 컬럼이 나타나며, 이중 기본

컬럼에 체크 V자 표시가 되어 있다(Default 정의값). 따라서 Before

Image를 저장할 컬럼에 대해서도 체크 표시를 하여 Target Table의 컬럼

구성을 지정한다.

참고) 새롭게 추가할 컬럼을 작성하거나 기존 컬럼 이름을 변경하고자 할

때, “컬럼 작성”, “변경” 화면에서 이를 지정한다. 여기서는 지정하지

않았다.

B) Project Table

“고급” 화면의 목표 유형 (Target Table Type) 탭에서 목표 테이블 유형을

“CCD Copy (올림 테이블 – 작업 단위(UOW) 테이블 컬럼 포함)”로

선택한다.

“고급” 화면의 목표 컬럼 탭에서 목표 테이블의 컬럼을 다음의 그림과 같이

조정한다.

Primary Key는 default로 설정이 되어 있으며, 마찬가지로 Before Image

를 저장할 컬럼에 대해 복사 작업 내역 항목에 모두 체크 표시를 한다. (

새로운 컬럼 및 기존 컬럼 변경은 하지 않았다.)

참고) CCD (Consistent Change Data) Copy로 Target Table을 구성하

면 위의 화면에서처럼 기존의 복제 소스에서 정의된 Table 컬럼 구

성외 4개의 컬럼이 추가된다. (IBMSNAP_REJ_CODE는 DB2 UDB

v7에서 새롭게 추가) 이중 IBMSNAP_UOWID, IBMSNAP_AUTHID

등의 컬럼 값이 CCD Table을 이용한 어플리케이션 작성시 많이 이

용된다.

위에서 정의한 두 Table은 모두 ‘SUB01’이라는 이름의 Subscription

Set의 부분으로 Subscription이 Apply Process에 의해서 실행될 때마다 함

께 변경된 부분이 적용될 것이다. 두 Table의 적용 시간은 “복사 작업 내

역 시간 제어” 화면에서 다음의 그림과 같이 설정하였다.

여기서는 테스트 예제이므로 5분 단위로 Apply Process가 구동하여 5분내의

변경된 Data를 Apply하도록 설정하였으나, 이 부분은 실제 업무에 구현

시 적용 업무의 특성에 따라 다양하게 설정할 수 있다.

“복제 복사 작업 내역 정의” 화면에서 최종 점검이 끝나면 “확인” 버튼

을 눌러 Control Table을 저장할 Control DB를 지정하여 설정을 마치고, 제어

센터에서 작업 정의를 확인한다.

3) Capture Process 실행

1. Capture Program Bind

Capture program이 제대로 작동하기 위해서는 Source DB에 Capture

Program이 동작할 때 필요한 DB Package가 작성이 되어 있어야 한다. 이를

위해서 Capture Program bind 작업이 필요하다.

Bind할 file : ../sqllib/bnd/capture.lst

Bind 방법 : 다음의 command를 입력한다.

Db2 connect to SOURCEDB

Db2 bind @capture.lst isolation ur blocking all grant public

Bind 작업은 Source DB에 한번만 필요하며, 이후에는 필요할 때마다 바로

Capture을 구동하면 된다.

2. Capture Program 실행

다음의 명령에서와 같이 Source DB (SAMPLE) System에서 적절한 권한

(SYSADM 또는 DBADM)을 가진 사용자로 login하여 DB2 환경 변수를 설정한

뒤, Capture Program을 실행한다.

Source DB가 있는 Win95의 DB2 UDB Personal Edition (v7)에서 Capture

Program을 구동하였다. 처음 구동하는 것이므로 COLD 로 start한다.

3) Apply Process 실행

1. Apply Program Bind : Capture 와 마찬가지로 Apply Program을 bind한다.

Bind할 file : ../sqllib/bnd/applycs.lst, applyur.lst

Bind 방법 : 다음의 command를 입력한다.

DB2 connect to TARGETDB

Db2 bind @applycs.lst isolation cs blocking all grant public

Db2 bind @applyur.lst isolation ur blocking all grant public

2. Apply Program 실행

다음 화면에서와 같이 Target DB (TARGETDB) system에서 적절한 권한

(SYSADM 또는 DBADM) 권한을 가진 사용자로 login하여 DB2 환경 변수

를 설정한 뒤, Apply Program을 구동한다.

SET DB2INSTANCE=DB2SET DB2DBDFT=SAMPLEASNCCP COLD

SET DB2INSTANCE=DB2SET DB2DBDFT=SAMPLEASNAPPLY QUAL01 TARGETDB TRCFLOW

ASNAPPLY의 parameter로 Apply Qualifier의 이름은 Subscription에서 정의된

것처럼 “QUAL01”로, Control DB의 이름은 TargetDB, 작업 trace가 화면에

출력이 되도록 parameter를 지정하였다.

1) ~ 4)의 방법으로 SAMPLE 데이터베이스의 Employee 및 Project Table에 대한

복제 작업이 모두 이루어 졌다. 이제는 실제 데이터 변경이 이루어졌을 때, 이의

내용이 올바른 프로세스를 거쳐서 Target Table에 적용되는지 여부를 확인하면

된다.

여기서 말하는 올바른 프로세스란 Employee Table의 경우, 사용자 복사 (User

Copy)의 Target Table 형식을 가지므로, Source System (NT)의 Capture

Process에 의해서 변경된 내용이 CD Table에 쌓이고, Target System (AIX)의

Apply Process에 의해서 CD Table의 내용이 정의된 Target Table

(CP_EMPLOYEE)에 반영되는 것이다. 따라서, employee Table의 내용을 변경하여

이의 CD Table에 쌓이는 가를 확인해본다. 또한 매 5분으로 설정한 Apply Process

interval time 후에 CP_EMPLOYEE Table의 내용을 확인하여 실제 작업이 잘

수행되었는지를 확인하면 된다.

Project Table의 경우는 약간 다르다. 이는 Target Table Type이 CCD (Consistent

Change Data) type으로 정의되어 있기 때문이며, CCD는 Apply가 실행되어

최초에 Access될 때, Source Table을 Full Refresh (Full Copy)하고, 그

이후부터는 변경된 내용에 대해서만 CD Table로부터 update가 된다. 따라서

Subscription에 정의된 대로 Data가 제대로 복제되었는지 CCD Table (Target

Table)을 확인한 후, Source Table에 변경을 가해, 변경된 부분에 대해서 다시

확인하면 된다.

부록 (Appendix)

* Subscription 정의의 SQL 스크립트의 내용

Subscription Control Table (Control DB)에 추가되는 내용

ASN.IBMSNAP_SUBS_SET : 각 Subscription Set에 대한 관련 정

보가 하나의 row로 삽입된다.

ASN.IBMSNAM_SUBS_MEMBER : 각 Subscription Set 내의

member에 대한 관련 정보가 member 당 하나의 row로 삽

입된다.

ASN.IBMSNAP_SUBS_COLS : 각 Subscription Set Member내의

각 column 에 대한 관련 정보가 column 당 하나의 row로

삽입된다.

Source DB의 Control Table에 추가되는 내용

ASN.IBMSNAP_PRUNCNTL : Pruning Control Table에 하나의

row가 삽입된다. 이는 CD 및 UOW Table에서 더이상

Apply에 의해서 사용되지 않는 data을 삭제하기 위한 과정

중의 일부이다.