안녕하세요. DB2 및 XpertMon 사용자 여러분!
㈜ 아이티엑스퍼트그룹 DB 사업부입니다.

현재 저희 XpertMon 개발부서는 고객분들이 원하시는 사항들을 좀 더 수렴하고
받아드리기 위해서 많은 노력을 하고 있으며, 그 중 하나가 사후 문제관리를
할 수 있는 실시간 모니터링 history 기능을 추가하는 것입니다.
앞으로 추가되는 기능들에 대해서는 뉴스레터를 통해서 자세하게 말씀드리도록
하겠습니다.

이번 시간에는 IBM WebSphere Information Integrator의 Q Replication을 사용하여 DB2의
데이터를 오라클이나 Sybase로 복제하는 방법에 대해 살펴보겠습니다.
아무쪼록 많은 도움되시길 바라며, 기존 뉴스레터들은 회사 홈페이지 ( www.iteg.co.kr)
게시판에 들어오시면 보실 수 있습니다.
혹시라도 알고 싶은 내용이나 주제가 있다면 메일로 보내주십시오. 참조하여 반영하도록
하겠습니다.

---

Quick Start for Q Replication to
Oracle and Sybase

소개

IBM WebSphere Infromation Integrator Q replication은 DB2의 commit된 트랜잭션
데이터를 오라클이나 Sybase로 복제할 수 있게 해 줍니다.

이 기능은 Q 복제와 WSII의 federation 기능을 통합하여 DB2 데이터베이스로의 복제시
낮은 대기시간과 높은 처리량을 보장해 줍니다.

[그림1] Federated target server를 통한 이기종 데이터베이스로의 Q복제

[그림1]에서 보듯이 이 기능은 원본과 목표가 모두 DB2 서버인 경우와 유사합니다.
Websphere MQ는 두 DB2 데이터베이스 사이에 있는 것처럼 설정됩니다.
트랜잭션은 Q capture 프로그램가 Q apply 프로그램을 통해 DB2 데이터베이스에서
오라클이나 Sybase 데이터베이스로 복제됩니다. Q capture 프로그램은 Db2 로그로부터
원본데이터의 변동사항을 읽어, Websphere MQ의 큐로 정보를 보냅니다.

DB2간의 Q복제와 가장 큰 차이점을 보이는 부분은 Q apply 쪽입니다. 오라클이나 Sybase
목표 데이터베이스의 경우, Q apply 프로그램은 WSII 에세 실행되며, 변경사항을 federation
환경의 nickname으로 설정된 오라클이나 Sybase 목표로 기록합니다. (Nickname은 비 DB2
데이터베이스의 실제 테이블이 아닌 포인터와 같은 개념입니다.)

Q복제의 federation 기능은 트랜잭션 연관성을 분석하여 Nickname을 통해 목표 데이터
베이스에서 병렬처리를 최대화하고 대기시간을 최소화하는 Q apply 엔진을 제공합니다.

Federated Q복제는 복제환경 구성에 있어서 마법사로 구동되는 GUI 방식과 CLP, 그리고
스크립트로 처리하는 방식을 제공합니다. 통합 모니터링 기능과 통계기능은 문제해결과
시스템 health 관리를 수월하게 해 줍니다.

다음의 federated Q 복제기능은 WSII V8.2.2 (Version 8.1 과 FixPack 9 적용) 에서
지원됩니다.
- 원본과 목표 : 단방향 복제는 z/OS 및 LUW용 DB2에서 해당 wrapper를 사용하여 federation
으로 구성된 오라클(NET8 또는 SQLNET wrapper) 또는 Sybase(CTLIB wrapper)를 지원합니다.
데이터는 Nickname에 쓰도록 만들어진 스토어드 프로시저를 통해 복제가 가능합니다.
Q apply 프로그램은 원본 데이터를 EXPORT 및 IMPORT를 사용하여 병렬로 하나 이상의
비 DB2 데이터베이스 테이블에 적재할 수 있습니다.

- 기반 구조 : 비 DB2 데이터베이스를 목표로 Q 복제를 설정할 때, 목표 시스템에 여러
개의 Q apply control 테이블이 생성되고, 목표 테이블 대신 Nickname을 통해 접속할
수 있습니다. 이는 목표 테이블이 변경되는 같은 UOW 안에서 Q apply 가 control table에
기록하기 때문입니다. Fedrated로 구성된 데이터베이스마다 한 세트의 control table이
필요합니다.

- 목표로의 데이터 적용 : 복제기능은 유사한 속성의 칼럼을 필요로 합니다. (예를 들어,
원본 테이블의 INTEGER NOT NULL 칼럼과 nickname의 INTEGER NOT NULL 칼럼) Q 복제는
원본 칼럼에서 칼럼 속성은 다르지만 유사한 nickname 칼럼으로 복제가 가능합니다.
예를 들면, 데이터 길이가 작은 소스 칼럼에서 길이가 큰 nickname 칼럼으로 복제할 수 있습니다.

- 유틸리티 : Replication Alert Monitor 및 table differencing, reconciliation 유틸
리티 (asntdiff 와 asntrep)는 비 DB2 목표 테이블을 지원합니다. asntdiff 유틸리티는
소스 테이블과 nickname과를 비교합니다. asntrep 유틸리티는 원본과 목표의 동기화를
위해 nickname을 update 합니다.

WSII와 WS MQ는 모두 비 DB2 데이터베이스로 접속을 지원합니다. [표1]에서는 SQL 복제와
Q 복제의 원본과 목표로 지원되는 플랫폼을 보여 줍니다.

복제 방법	원본 플랫폼	목표 플랫폼
SQL 복제	DB2 for LUW DB2 for z/OS DB2 for iSeries™ Informix® Microsoft® SQL Server Oracle Sybase	DB2 for LUW DB2 for z/OS DB2 for iSeries Informix Microsoft SQL Server Oracle Sybase Teradata
Q 복제	DB2 for LUW DB2 for z/OS	DB2 for LUW DB2 for z/OS Oracle Sybase

[표1] SQL 복제 및 Q 복제의 지원 플랫폼

소프트웨어 요구사항
Q capture 프로그램이 동작하는 서버의 소프트웨어 요구사항은 DB2 V8.2 에서 요구되는
사항과 같습니다. Q apply 프로그램이 동작하는 서버에는 WSII V8.2.2(V8.1 + FP 9)가
필요합니다.

Q apply 프로그램이 동작하는 서버에는 오라클이나 Sybase 클라이언트 소프트웨어 이외에
다음의 소프트웨어가 필요합니다.
- Websphere Information Integrator V8.2 (Relational Wrapper 포함) 와 FP9
- DB2 Universal Database Version 8.2
- Websphere MQ Version 5.3 (WSII 패키지에 번들로 포함)

Fedrated Q 복제 설정 작업

오라클 및 Sybase를 목표로 하는 Q 복제 설정 작업은 다음과 같습니다.
1. Websphere MQ 개체 생성
2. Q apply서버와 비 DB2 목표 서버 구성 및 federated object 생성
3. Q 복제 object 생성
4. 복제 시작

[그림 2]에서 위의 작업을 개괄적으로 보여줍니다.

[그림 2] 비 DB2 목표로의 Q 복제 설정 단계

용어에 관해서
'원본-source'과 '목표-target'라는 용어는 federated 복제환경에 있어서 다소 혼란스
러울 수 있습니다. 이 문서에서는 WSII federated 서버와 Q apply 프로그램이 트랜잭션을
nickname에 적용하는 서버, 그리고 목표 테이블을 가지고 있는 비 DB2 데이터베이스
모두를 '목료-target'이라고 통칭하겠습니다.


[그림 3] Federated Q 복제에 있어서 원본과 목표

WebSphere MQ 큐 매니저 생성

원본 데이터베이스의 Q capture 프로그램과 federated Q apply 서버간의 복제 데이터의
이동 및 통신을 위해 사용되는 큐, 채널 및 메시지를 관리하는 WebSphere MQ 큐 매니저를
생성합니다.

이 과정은 Q capture 및 Q apply 프로그램이 동작하는 서버에서 큐 매니저를 생성합니다.
Q 복제는 Q capture 및 Q apply 프로그램이 MQ 클라이언트가 설치된 시스템에서 원격
큐 매니저로 접속하면서 동작하는 WS MQ 서버-클라이언트 구성도 지원합니다.

권장사항 : 최적의 성능을 위해서는 큐 매니저를 Q capture 및 Q apply 프로그램과
동일한 서버에 구성하십시오.

순서
WS MQ 큐 매니저를 생성하려면 :
1. Q capture 프로그램이 동작하는 시스템의 OS 프롬프트 상에서 다음 명령을 수행하십시오.
     crtmqm quere-manager-name

2. 위의 명령을 Q apply프로그램이 동작하는 시스템에서 반복하십시오.

원본 및 목표 큐 생성

Q capture 및 Q apply 프로그램이 사용하는 큐를 WS MQ script(MQSC)를 통해 생성할 수
있습니다.

시작하기 전에 Q capture 및 Q apply 가 사용할 큐 매니저가 생성되어 있어야 합니다.

Q 복제는 DB2 원본에서 오라클 및 Sybase 목표로의 단 방향 복제만 지원하므로, 필요한
큐 역시 단 방향 복제를 위한 것입니다.

순서 원본 큐 및 목표 큐를 생성하는 과정은 다음과 같습니다.
1. 다음 명령을 통해 원본 시스템에서 큐 매니저를 시작합니다.
     strmqm queue-manager-name

2. 다음 명령을 통해 원본 큐 매니저와 통신하는 통신 MQSC 세션을 시작합니다.
     runmqsc queue-manager-name

3. [표2]에 있는 명령을 통해 원본 큐를 생성합니다.

큐	목적	MQSC 명령
Send Queue	Q capture 에서 Q apply로 트랜잭션과 Control 메시지를 전송	DEFINE QREMOTE('send-queue-name') RNAME('receive-queue-name') RQMNAME('remote-queue-manager-name') XMITQ('transmit-queue-name')
Administration Queue	Q apply에서 Q capture로의 control 메시지를 수신	DEFINE QLOCAL('Q-capture-admin-queue-name')
Restart Queue	재시작 후 Q capture가 읽기 시작할 DB2 log의 위치를 저장	DEFINE QLOCAL('restart-queue-name')
Transmission Queue	Q apply를 기다리는 Q capture부터의 트랜잭션 및 정보 메시지를 저장	DEFINE QLOCAL('transmit-queue-name') USAGE(XMITQ)

[표2] 원본 큐 생성 명령

4. end 명령을 사용하여 원본 큐 매니저와 통신 MQSC 세션을 중지합니다.

5. 다음 명령을 통해 목표 시스템의 큐 매니저를 시작합니다.
     strmqm queue-manager-name

6. 다음 명령을 통해 목표 큐 매니저와 통신 MQSC 세션을 시작합니다.
     runmqsc queue-manager-name

7. [표3]에 있는 명령을 통해 목표 큐를 생성합니다.

큐	목적	MQSC 명령
Receive Queue	Q capture 에서 Q apply로의 트랜잭션과 Control 메시지를 수신	DEFINE QLOCAL('receive-queue-name')
Administration Queue	Q apply에서 Q capture로 control 메시지를 전송	DEFINE QREMOTE('Q-apply-admin-queue-name') RNAME('Q-capture-admin-queue-name') RQMNAME('remote-queue-manager-name') XMITQ('transmit-queue-name')
Transmission Queue	Q capture를 기다리는 Q apply부터의 control 메시지를 저장	DEFINE QLOCAL('transmit-queue-name') USAGE(XMITQ)

[표3] 목표 큐 생성 명령

원본과 목표간 WebSphere MQ 채널 생성

원본 데이터베이스의 Q capture 프로그램과 federated Q apply 서버의 Q apply 프로그램
사이에서 메시지를 전송하기 위해 원본 및 목표 큐 매니저 사이에 WS MQ채널을 생성합니다.

시작하기 앞서, Q capture 및 Q apply 프로그램을 위한 큐 매니저와 원본 및 목표 큐가
있어야 합니다.

각각의 큐는 양쪽 끝이 있습니다. [그림 4]와 같이 송신 채널은 원본 큐 매니저 내부에
정의되며, 수신 채널은 목표 큐 매니저 내부에 정의됩니다.


[그림 4] 원본과 목표간 메시지 채널

순서 원본과 목표간 채널을 생성하는 절차는 다음과 같습니다.
1. 소스시스템의 큐 매니저가 다음 명령에 의해 동작 중인지 확인합니다.
     strmqm queue-manager-name

2. 다음 명령을 통해 원본 큐 매니저와의 통신 MQSC 세션을 시작합니다.
     runmqsc queue-manager-name

3. 다음 명령을 통해 원본 큐 매니저에서 목표 큐 매니저로의 (TCP/IP 프로토콜을 이용한)
송신 채널을 생성합니다.      DEFINECHL('source-sender-channel-name)CHLTYPE(SDR) TRPTYPE(TCP)
     CONNAME('target-IP-address(port)')
     XMIT('source-transmit-queue-name')

만약 위에서 port 값을 주지 않으면, WSMQ의 기본값인 1414가 사용됩니다. 소스시스템에서
UNIX/LINUX에서는 /etc/services 파일을, Windwos에서는 \etc\services 파일을 확인하여
포트번호 할당을 위해 사용되지 않은 포트번호를 확인할 수 있습니다.

4. 다음 명령을 통해 목표 큐 매니저에서 원본 큐 매니저로의 수신 채널을 정의합니다.
     DEFINE CHL('source-receiver-channel-name')CHLTYPE(RCVR) TRPTYPE(TCP)

5. end 명령을 사용하여 원본 큐 매니저와의 통신 MQSC 세션을 종료합니다.

6. 다음 명령을 통해 목표 시스템의 큐 매니저를 시작합니다.
     strmqm queue-manager-name

7. 다음 명령을 통해 목표 큐 매니저와의 통신 MQSC 세션을 시작합니다.
     runmqsc queue-manager-name

8. 다음 명령을 통해 목표 큐 매니저에서 원본 큐 매니저로의 (TCP/IP 프로토콜을 이용한)
송신채널을 생성합니다.
     DEFINE CHL('target-sender-channel-name') CHLTYPE(SDR) TRPTYPE(TCP)
     CONNAME('source-IP-address(port)')
     XMIT('target-transmit-queue-name')

9. 다음 명령을 통해 원본 큐 매너저에서 목표 큐 매니저로의 수신 채널을 정의합니다.
     DEFINE CHL('target-receiver-channel-name') CHLTYPE(RCVR) TRPTYPE(TCP)

Federated Q 복제를 위한 원본과 목표 시스템 구성

비 DB2 목표로 복제를 하기 위해 Q capture 프로그램이 동작할 곳에 DB2 원본 데이터
베이스를 구성하고, Q apply 프로그램이 수행될 곳에 DB2 인스턴스와 데이터베이스가
구성되어야 합니다.

순서
Federated Q 복제를 위한 원본과 목표 시스템을 구성하는 절차는 다음과 같습니다.
1. LUW : 다음 중 한가지 방법으로 원본 데이터베이스의 로그 방식을 archival logging
으로 변경합니다.
A. 복제센터 : Q Capture 서버 폴더에서 원하는 데이터베이스에서 오른쪽 클릭 후
"Enable Database for Q Replication"을 클릭합니다.

[그림 5] 복제센터를 통한 Archival logging 설정

B. CFG 변경 : 다음 명령을 수행합니다.
     UPDATEDB CFG FOR database-anme USING LOGRETAIN RECOVERY
여기서 database-name은 원본 데이터베이스 명을 말합니다.

위 명령을 수행하면 데이터베이스는 BACKUP PENDING 상태에 빠집니다.
BACKUP PENDING 상태에서는 OFF LINE 백업을 필요로 하므로, 다음 명령을 통해 데이터
베이스 백업을 받도록 합니다.
     BACKUP DATABASE database-name TO path
여기서 path는 백업 이미지가 저장될 경로를 말합니다.

2. 다음 중 한가지 방법으로 Q apply 서버의 federated 지원을 활성화 합니다.
A. 제어센터 : DBM CFG 창에서 Q apply 데이터베이스가 속한 인스턴스에서 오른쪽 클릭 후
나타나는 팝업 메뉴에서 Configuration Parameters를 클릭합니다. Environment 항목의
Federated를 클릭하고 '...'을 클릭하여 federated 지원을 활성화합니다.

[그림 6] 제어센터의 DBM CFG 창

B. CFG 변경 : Q apply 서버쪽의 인스턴스에 attach 한 후, 다음 명령을 실행합니다.
     UPDATE DBM CFG using FEDERATED YES
** 변경 사항을 적용하기 위해서는 인스턴스를 재시작해야 합니다.
3. Federated Q apply 서버에서 db2dj.ini 파일에 오라클 및 Sybase 환경변수를 설정합니다.
WSII를 설치하기 전에 오라클이나 Sybase 클라이언트가 설치되어 있다면, 필요한 환경변수가
db2dj.ini에 지정되어 있을 것입니다. 그렇지 않다면, 다음의 과정을 따르십시오.
A.자동 설정 : 'Typical' 오셥을 사용하여 WAII설치프로그램을 다시 수행하여 마법사의
지시에 따르십시오.
** WSII 설치는 필수 환경변수만 설정합니다. 선택적 환경변수는 수동으로 설정해 주어야 합니다.

B. db2dj.ini 파일을 편집합니다. 이 파일의 위치는
     ●UNIX/Linux 환경에서는 sqllib/cfg 디렉토리 입니다.
     ●Windows 환경에서는 sqllib\cfg 또는 %DB2PATH\cfg
     디렉토리 입니다.
db2dj.ini 파일은 federated 서버에 설치된 오라클 및 Sybase 클라이언트 소프트웨어의
구성정보를 담고 있습니다. 파일이 없다면, 에디터를 사용하여 db2dj.ini 파일을 새로
생성해야 합니다. db2dj.ini 파일에는 환경변수 값으로 절대경로 값을 입력해야 합니다.
그렇지 않으면 에러가 발생합니다.

4. Linux/UNIX : 목표 데이터베이스 DB2 인스턴스의 .profile 파일에 환경변수를 추가합니다.
●오라클 : 오라클 데이터베이스에 대해서는 다음 명령을 수행합니다.
여기서 oracle_home_directory는 오라클 클라이언트 소프트웨어가 설치된 디레토리를 의미합니다.
     export ORACLE_HOME=oracle_home_directory
     export PATH=$ORACLE_HOME/bin:$PATH

●Sybase : Sybase 데이터베이스에 대해서는 다음 명령을 수행합니다.
여기서 sybase_home_directory는 Sybase 클라이언트 소프트웨어가 설치된 디렉토리를
의미 합니다. OCS-version_release는 설치된 Sysbase Open 클라이언트 버전과 릴리즈
번호를 의미합니다.
     export SYBASE=sybase_home_directory
     export SYBASE_OCS=OCS-version_release
     export PATH=$SYBASE/bin:$PATH

5. Linux/UNIX : DB2 인스턴스 .profile을 다시 수행합니다.
     .$HOME/.profile
환경변수가 db2dj.ini 파일의 내용과 같은지 확인하고, Q apply 서버가 새로운 값들을
읽을 수 있도록 db2 인스턴스를 재시작합니다.

6. Q apply가 동작하는 목표 데이터베이스의 클라이언트 구성을 설정합니다.
A. 오라클 : 다음 경로의 tnsnames.ora 파일에 오라클 데이터베이스에 접속하기 위한
TCP/IP 주소, 포트 번호, 서비스 명 및 기타 정보를 등록합니다.
     ●Linux/UNIX : $ORACLE_HOME/network/admin
     ●Windows : %ORACLE_HOME\NETWORK\ADMIN
오라클 클라이언트 소프트웨어에 제공되는 ORACLE NET Configuration Assistant
유틸리티를 사용하여 tnsnames.ora 파일을 생성할 수 있습니다. 이 유틸리티에 대한
정보는 오라클 설치 문서를 참조하시기 바랍니다.
tnsnames.ora 파일의 SID(SERVICE_NAME)는 오라클 인스턴스 명이고, HOST는 오라클
서버가 위치한 머신의 호스트 명입니다.
B. Sybase : $SYBASE 디렉토리의 interfaces 파일에 Sybase SQL Server의 위치 또는
Adaptive Server Enterprise 인스턴스와 데이터베이스 서버로의 접속방식(프로토콜)을
등록합니다. interfaces 파일을 Q apply 서버에 위치한 DB2 인스턴스의 $HOME/sqllib
디렉토리로 복사합니다. interfaces 파일로의 링크를 생성하거나, CREATE SERVER 문에서
IFILE 옵션을 통해 해당 파일의 절대경로를 지정할 수도 있습니다.

7. 클리이언트 설정을 테스트합니다.
A. 오라클 : 접속 테이스를 위해 sqlplus 유틸리티를 수행합니다.
B. Sybase : 접속 테스트를 위해 isql 등 적절한 Sybase 쿼리 유틸리티를 수행합니다.


Oracle 및 Sybase Wrapper 등록
Federated Q apply 서버는 비 DB2 목표 서버와 통신 및 데이터 교환을 위해 wrapper를
사용합니다.
Wrapper를 생성하는 것은 실제로 사용자가 원하는 목표에 대해 이미 생성된 wrapper를
등록하는 것입니다.

시작하기 전에, Q apply 서버의 인스턴스가 federated를 지원하는 지와 wrapper가 비
DB2 목표로의 write access를 허용하는지 확인하십시오. 제한사항 : Q 복제는 비 DB2 목표로의 복제에 있어서 ODBC wrapper와 같은 일반적인
wrapper를 통한 복제는 지원하지 않습니다.

순서
오라클 및 Sybase wrapper를 생성하기 위해서 다음 중 한가지 방법을 사용하십시오.
A. 제어센터 : Create Wrapper창을 이용합니다. 창을 열기 위해서는 오브젝트 트리에서
federated Q apply database를 확장하고, Federated Database Object 폴더를 오른쪽
클릭한 후, 메뉴에서 Create Wrapper를 클릭합니다.

[그림 7] Create Wrapper 창

B. CREATE WRAPPER 문 사용 : 다음 SQL문을 실행하여 wrapper를 생성합니다.      CREATE WRAPPER wrapper-name

Q 복제는 오라클에 대해서 NET8 및 SQLNET wrapper를, Sybase에 대해서 CTLB wrapper를
지원합니다. Wrapper를 기본 이름으로 등록하면 federated 서버가 자동으로 Q apply 서버가
동작하는 시스템에 적합한 라이브러리를 사용합니다.
Wrapper 명으로 기본값이 아닌 특정 이름을 지정한다면, LIBRARY 파라미터를 사용하여
OS에 정확한 라이브러리를 지정해 주어야 합니다.

오라클 및 Sybase 목표에 대한 Server 정의 생성
federated Q apply 서버에 복제 목표가 될 오라클 및 Sybase에 대한 서버 정의를 해 줍니다.

시작하기에 앞서, Q apply서버를 보유한 DB2 인스턴스는 federated 를 지원하도록 설정
되어 있어야 하며, 비 DB2 목표에 대한 wrapper가 생성되어 있어야 합니다.

순서
오라클 및 Sybase 에 대한 서버정의를 생성하는 절차는 다음과 같습니다.
1. 노드 명을 지정합니다. (federated 용어로서, 노드는 서버 인스턴스입니다)
A. 오라클 : 노드 명은 tnsnames.ora 파일의 정의 행 위에 위치합니다.
B. Sybase : 노드명은 sqllib 디렉토리의 interfaces 파일에 위치합니다.

2. 서버 정의를 생성하기 위해 다음 중 한가지 방법을 사용하십시오.
A. 제어 센터 : 서버 정의 생성 창을 이용합니다. 창을 열기 위해서는 오브젝트 트리
에서 federated Q apply 데이터베이스를 확장하면 나타나는 wrapper 아이콘을 확장합니다.
Server Definition 항목을 오른쪽 클릭하여 나타나는 메뉴 중 create를 클릭합니다.
윈도우의 설정(Setting) 탭에서 오라클에 대해서는 NODE 항목을, Sybase에 대해서는
노드와 DBNAME 항목을 지정합니다.

[그림 8] 서버 정의 생성 창

B. CREATE SERVER 문 사용 : 다음 SQL 문을 사용하여 생성한다.
     CREATE SERVER server-definition-name TYPE target-type
     VERSION version_number WRAPPER wrapper
     OPTIONS (NODE 'node-name', DBNAME 'database-name');

target-type : 오라클인지 Sybase 인지를 지정합니다.
version_number : 비 DB2 목표 데이터베이스의 버전을 지정합니다. 오라클에 있어서는
8i, 9i, 10, 그리고 10g를 지원합니다. Sybase 에 있어서는 11.0,11.5, 11.9, 12.0,
그리고 12.5가 지원됩니다.
wrapper : 오라클은 NET8 또는 SQLNET, Sybase에 있어서는 CTLIB를 지정합니다.
node-name : 오라클은 tnsnames.ora 파일, Sybase 에 있어서는 interfaces 파일에서
노드 명을 찾을 수 있습니다. NODE는 오라클 및 Sybase 모두에서 필요한 옵션입니다.
database-name : Sybase 목표에서만 필요한 옵션입니다.

오라클 및 Sybase 목표에 대한 User mapping 생성
Q apply 프로그램이 오라클이나 Sybase에 접속하기 위해서는 federated Q apply 서버
에서 사용하는 사용자 ID와 패스워드와 비 DB2 목표 데이터베이스에서 사용하는 사용자
ID와 패스워드간에 매핑을 생성해 주어야 합니다.

순서
오라클 및 Sybase 목표에 대한 user mapping을 생성하려면 다음 중 한가지 방법을 사용
하십시오.
1. 제어 센터 : User Mapping 생성 창을 이용합니다. 이 창을 열려면, 비 DB2 목표
데이터베이스에 대한 서버 정의 항목을 확장하고, user mapping 폴더를 오른쪽 클릭하여
나타난 메뉴에서 CREATE 를 클릭합니다. Federated Q apply 서버의 사용자 ID를 선택한
후, Setting 탭에서 비 DB2 목표에 사용되는 사용자의 ID와 패스워드를 입력합니다.

[그림 9] User mapping 생성 창

2. CREATE USER MAPPING 문 사용 : 다음 SQL문을 사용하여 생성합니다.
     CREATE USER MAPPING FOR QApply_userID
     SERVER server-definition-name
     OPTIONS (REMOTE_AUTHID 'remote_userID',
     REMOTE_PASSWORD 'remote_password');

명령문에서는 OPTION 항목으로 나오지만 오라클 및 Sybase 데이터 소스에 접속하기
위해서는 REMOTE_AUTHID와 REMOTE_PASSWORD를 반드시 지정해 주어야 합니다.

Federated Q 복제를 위한 제어 테이블 생성
비 DB2 목표로 데이터를 복제하기 전에, Q subscription, 메시지 큐, operational
parameter 와 사용자 선택 등의 정보를 저장할 제어 테이블을 생성해야 합니다.

시작하기 앞서, 다음 항목들이 준비되어야 합니다.
- 복제센터가 원본 서버와 federated 서버에 접속할 수 있어야 합니다.
복제 센터는 비 DB2 목표 서버와 pass-through 및 nickname 기능을 통해 작업을 수행
하게 됩니다.
- 비 DB2 서버에 대해 wrapper, server정의, 사용자 mapping 등이 생성되어 있어야 합니다.
- 기본적으로, remote authorization ID 는 비 DB2 목표 데이터베이스에 생성되는
Q apply 제어 테이블의 스키마와 동일한 이름을 사용하여야 합니다.
- Q capture 제어 테이블에 있어서, Q capture 프로그램이 사용하는 Websphere MQ 큐
매니저의 이름과, 관리 큐로 사용되는 local 큐와 재시작 큐로 사용되는 local 큐의
이름이 필요합니다.
- Q apply 제어 테이블에 있어서, Q apply 프로그램이 사용하는 Websphere MQ 큐 매니저의
이름이 필요합니다.

참고로 복제 센터에서는 큐 매니저와 큐 이름에 대해 정확성 여부를 판별하지 않습니다.
제어 테이블을 생성할 때 MQ 오브젝트 명과 일치 하는지 확인하십시오. 그렇지 않으면
Q capture 나 Q apply가 정상적으로 수행되지 않을 수 있습니다. MQ 오브젝트 명은
대소문자를 구분합니다.

비 DB2 목표에서, 몇몇 Q apply 제어 테이블은 목표 시스템에 생성되며 목표 테이블처럼
nickname을 통해 접속됩니다. 나머지 제어 테이블들은 Q apply 서버에 생성됩니다.

[표4]는 제어 테이블의 위치를 나타냅니다.

Federated Server에 위치하는 테이블	비 DB2 목표 서버에 위치하는 테이블
IBMQREP_APPLYENQ IBMQREP_APPLYTRACE IBMQREP_APPLYMON IBMQREP_APPLYPARMS	IBMQREP_DONEMSG IBMQREP_EXCEPTIONS IBMQREP_RECVQUEUES IBMQERP_SAVERI IBMQERP_SPILLEDROW IBMQERP_SPILLQS IBMQERP_TRG_COLS IBMQERP_TARGETS

순서
다음 과정을 통해 복제센터에서 Q capture 프로그램 및 Q apply 프로그램을 위한 제어
테이블을 생성합니다.
1. Q capture 제어 테이블 마법사를 이용합니다. 마법사를 열기 위해서는 Q capture
servers 폴더에서 오른쪽 클릭 후, Create Q Capture Control Tables를 클릭합니다.

2. Q apply 제어 테이블 마법사를 이용합니다. 마법사를 열기 위해서는 Q apply servers
폴더에서 오른쪽 클릭 후, Create Q Apply Control Tables를 클릭합니다.
A. 선택사항 : 시작 페이지에서, Q apply 서버나 비 DB2 서버에서의 제어테이블 위치를
지정하려면 Custom을 클릭하십시오.
ⅰ. Q apply 서버에서 제어 테이블은 한 테이블 스페이스에 생성됩니다. 새로운 테이블
스페이스를 생성하거나, 기존에 있는 테이블 스페이스를 지정할 수 있습니다.
ⅱ. 비 DB2 서버에서 제어 테이블은 기본 테이블 스페이스 (오라클) 또는 기본 세그먼트
(Sybase)에 생성되거나, 기존에 있는 테이블 스페이스 또는 세그먼트를 지정할 수 있습니다.

B. 서버 페이지에서, federation 서버를 선택합니다.

[그림 10] Q apply 제어 테이블 생성 마법사의 서버 페이지

C. 목표 테이블 페이지에서, 목표 테이블이 비 DB2 데이터베이스에 있고 Q apply 서버에
mapping 되어있음을 지정하고, 다음을 확인하십시오.
ⅰ. 서버 명 (비 DB2 데이터베이스의 서버 정의를 말합니다.)
ⅱ. 오라클이나 Sybase에 생성되는 Q apply 제어 테이블의 원격 스키마 (비 DB2 데이터
베이스의 경우 스키마 항목은 remote authorization ID로 미리 채워져 있습니다. 필요한
경우 변경할 수 있습니다.)

[그림 11] Q apply 제어 테이블 생성 마법사의 목표 테이블 페이지

D. 큐 매니저 페이지에서, Q apply 프로그램이 사용하는 큐 매니저를 지정하십시오.

E. 요약 페이지에서 선택 내용을 확인한 후, 제어 테이블을 생성하는 스크립트를 작성
하도록 완료 버튼을 클릭하십시오. 스크립트를 실행하거나 작업센터에서 스케쥴링 하거나,
파일로 저장할 수 있습니다.

ASNCLP를 사용하여 제어 테이블 생성
ASNCLP를 사용하여 Q capture 및 Q apply 제어 테이블을 생성할 수도 있습니다.

CREATE CONTROL TABLES FOR 명령을 사용합니다. Q apply 제어 테이블에 있어서는
FEDERATED 키워드를 사용하십시오. 비 DB2 데이터베이스에 대해서 RMT SCHEMA 키워드를
사용하여 제어 테이블 스키마를 지정할 수 있습니다. 기본값은 remote authorization
ID 입니다. 원격 제어 테이블 생성시 테이블 스페이스(오라클)나 세그먼트(Sybase)를
지정할 수도 있습니다.

예를 들면, 이고, federated Q apply 서버 FED_DB를 통해, ORACLE_ID를 remote authorization ID로
사용하여 ORACLE_TARGET이라는 목표로 복제하기 위한 Q apply 제어 테이블을 생성하는
문장은 다음과 같습니다.

ASNCLP SESSION SET TO Q REPLICATION;
SET SERVER TARGET TO DB FED_DB NONIBM SERVER ORACLE_TARGET;
SET QMANAGER QM2 FOR APPLY SCHEMA;
SET APPLY SCHEMA ASN;
CREATE CONTROL TABLES FOR APPLY SERVER IN FEDERATED RMT SCHEMA ORACLE_ID;

위 명령은 스크립트를 생성하여 자동으로 실행되고, 명령이 발행된 디렉토리에 저장됩니다.

복제 큐 맵 생성

복제 큐 맵은 원본 측의 send 큐와 목표 측의 receive 큐를 연결하여 복제 데이터의
이동 통로를 정의 합니다. Administration 큐를 생성하여 Q apply 프로그램이 Q capture
프로그램으로 제어 메시지를 전송하도록 할 수도 있습니다.

시작하기 전에, Q capture 및 Q apply 제어 테이블이 생성되어 있어야 하며, send 큐,
receive 큐, 그리고 Q apply administration 큐의 이름이 있어야 합니다.

순서
복제 센터에서 복제 큐 맵을 생성하기 위해서는 다음의 과정을 따르십시오.
1. 복제 큐 맵 생성 창을 엽니다.
2. 큐 맵을 사용할 Q capture 프로그램에 해당하는 Q capture 스키마를 확장합니다.
3. 복제 큐 맵 폴더를 오른쪽 클릭하여 나타나는 메뉴에서 CREATE 를 클릭합니다.


[그림 12] 복제 큐 맵 생성 창

4. 옵션 페이지에서, 다음 옵션을 지정합니다.
A. Maximum message length : Q capture 프로그램이 send 큐에 올릴 수 있는 메시지의
최대 크기( KB 단위)
B. Queue error action : 큐에서 에러가 발생했을 때 복제 프로그램이 할 일
C. Number of Q Apply agents : Q apply 프로그램이 receive 큐로부터 트랜잭션을 동시에
적용하기 위해 사용하는 agent thread 수
D. Maximum Q Apply memory usage : Q apply프로그램이 receive 큐로부터 받은 메시지의
buffer로 사용할 메모리의 최대 용량(MB 단위)
E. Heartbeat interval : 복제할 트랜잭션이 없을 때 Q capture 프로그램이 이 큐가
동작 중인지 확인을 위해 신호를 보내는 주기(초 단위)

ASNCLP를 통한 큐 맵 생성
ASNCLP에서 CREATE REPLQMAP 명령을 통해 복제 큐 맵을 생성 할 수 있습니다.
예를 들면, send 큐 및 receive 큐의 이름이 모두 ASN.QM1_TO_QM2.DATAQ 이고,
administration 큐의 이름이 ASN.ADMINQ 이며 나머지를 기본값으로 하는 큐 맵
SAMPLE_ASN_TO_FED_DB_ASN을 생성하는 명령은 다음과 같습니다.

ASNCLP SESSION SET TO Q REPLICATION;
SET SERVER TARGET TO DB FED_DB NONIBM SERVER ORACLE_TARGET;
SET QMANAGER QM2 FOR APPLY SCHEMA;
SET APPLY SCHEMA ASN;
CREATE REPLQMAP SAMPLE_ASN_TO_FED_DB_ASN
USING ADMINQ ASN.QM1.ADMINQ RECVQ ASN.QM1_TO_QM2.DATAQ
SENDQ ASN. ASN.QM1_TO_QM2.DATAQ

Federated Q 복제를 위한 Q subscription 생성
Q subscription은 DB2테이블의 원본 데이터와 비 DB2 목표 데이터베이스의 테이블의
사본과의 매핑정보를 갖고 있습니다. Q subscription에는 큐 맵, 목표 테이블 옵션,
그리고 기타 선택정보를 지정합니다.
복제를 원하는 테이블 마다 Q subscription을 생성합니다.

시작하기 전에, Q capture 와 Q apply 제어 테이블 및 복제 큐 맵이 있어야 합니다.

제한사항
비 DB2 목표에 대해 다방향 복제는 지원되지 않습니다.
비 DB2 데이터베이스의 뷰나 스토어드 프로시저는 목표로 지원되지 않습니다.
적재방법으로 EXPORT / IMPORT 방식을 사용하기 위해서는 nickname으로 참조되는 목표
테이블이 비어있어야 합니다.
비 DB2 목표 테이블에 대한 참조 무결성 제한조건을 지원 받기 위해서는 해당 nickname에
대한 제한조건을 수동으로 정의해 주어야 합니다. 복제 센터에서는 이러한 제한조건을
자동으로 생성하지 못합니다. 그리고 Q apply 프로그램은 nickname에 대한 참조 무결성 제한조건을 적재과정에서 삭제
한 후 복구하는 기능이 없습니다. 권장사항 : 참조 무결성 제한조건이 있는 nickname에
대해서는 "no load" 옵션을 사용하고, 복제 관리 툴 밖에서 목표 테이블에 데이터를
적재하십시오.

여러 인덱스를 가진 목표 nickname에 대해서, IPMQREP_SUBS 테이블에 있는 Q subscription의
BEFORE_VALUES 속성은 Y , CHANGED_COLS_ONLY 속성은 'N' 이어야 합니다.

순서
Federated Q 복제 환경에서 Q subscription을 생성하기 위해서는 다음의 과정을 수행하십시오.
1. 복제센터에서 Q subscription 생성 마법사를 엽니다. 마법사를 열기 위해서는 오브
젝트 트리에서 원하는 Q capture 스키마 또는 Q apply 스키마를 확장한 후, Q subscriptions
폴더에서 오른쪽 클릭을 통해 나오는 메뉴의 Create를 클릭합니다.


[그림 13] Q subscription 생성 마법사 열기
2. 복제 페이지에서 기본값인 Unidirectional을 선택합니다.

3. Servers 페이지에서 :
A. 원본 서버를 지정합니다.
B. 목표 서버에 Q apply 서버를 지정합니다. Q apply 프로그램은 비 DB2 관계형 데이터
베이스에 매핑된 nickname 을 갱신합니다.
C. 복제 큐 맵을 지정합니다.

4. 원본 테이블 페이지에서, 복제하고자 하는 테이블을 선택합니다.

5. 목표 페이지에서, 복제하고자 하는 목표의 타입을 지정합니다.
A. Nickname을 통해 갱신될 비 DB2 데이터베이스의 테이블을 지정할 수 있습니다.
복제 센터를 통해 새로운 테이블을 생성할 수 도 있으며, 기존에 존재하는 테이블을
지정할 수 있습니다.
B. Nickname에 적용되기 전 원본 데이터에 조작을 가할 스토어드 프로시저를 지정할
수 있습니다. 이 프로시저는 Q apply 서버에 미리 존재하여야 하며, nickname에만 쓸
수 있어야 합니다.

** 복제센터에서는 비 DB2 목표 테이블에 대해 기존에 nickname이 있다고 하더라도,
새로운 항상 nickname을 생성합니다. 새로운 nickname은 복제센터에 nickname 변경에
대한 control 권한을 주기 때문에, 기존 nickname의 변경 없이 DB2 데이터베이스와
비 DB2 목표에 대한 속성 차이를 해결할 수 있습니다.


[그림 14] Q subscription 생성 마법사의 Target 페이지

6. 여러 Q subscription 에 대해 : 만약 하나이상의 원본 테이블을 지정한다면, Q apply
서버에 있는 비 DB2 목표 테이블, 인덱스, 테이블스페이스 또는 세그먼트 , 그리고
목표 nickname에 대한 profile을 사용해야 합니다. Change 버튼을 클릭하여 목표 오브젝트
profile 창을 열고 이름을 변경하십시오.

7. Rows and column 페이지에서는 다음 과정을 수행합니다.
A. 원본 테이블의 일부 칼럼 혹은 일부 행을 복제하고자 한다면, Source changes 를
사용하십시오.
B. 원본 컬럼과 비 DB2 목표 테이블 칼럼 사이의 기본 매핑을 변경하고자 한다면 Column
mapping 을 사용하십시오. 컬럼 매핑 창에서 Q apply 서버의 nickname과 비 DB2 목표
테이블 사이의 기본 데이터 유형 매핑 정보 및 원본 칼럼이 목표 칼럼으로 제대로 매핑
되었는지 여부를 확인하십시오.
C. Q apply 프로그램이 복제된 행을 인식하고, 트랜잭션의 순서를 조정하는데 사용하는
키 칼럼을 선택하려면, Index or primary key를 사용하십시오.

8. 돌발상황(Unexpected condition) 페이지에서, Q apply 프로그램이 에러에 어떻게
대응할지 지정하십시오.

9. 표 테이블 적재 페이지에서 :
A. 적재 옵션을 지정하십시오.

** Q apply 프로그램의 목표 테이블에 대한 자동 적재에 있어서, federated Q 복제에서는
EXPORT / IMPORT 만을 지원합니다.

B. Q subscription이 생성 후 바로 활성화 될 것인지 여부를 지정하십시오. 이 옵션을
사용하면, Q capture 및 Q apply 프로그램이 시작되면 Q subscription에 대한 복제가
시작됩니다.

10. 요약 페이지에서는, 지금까지의 설정을 확인합니다. 만약 변경할 것이나 빠뜨린
사항이 있다면, Q subscription을 선택한 뒤 Properties를 클릭합니다.

11. 요약 페이지에서 Finish 를 클릭하면, Q subscription을 생성하는 스크립트가
작성됩니다. 이 스크립트는 바로 실행하거나, 작업센터에서 스케줄링하거나, 파일로
저장할 수 있습니다.
ASNCLP 에서 Q subscription 생성
ASNCLP에서, CREATE QSUB 문을 사용하여 Q subscription을 생성합니다. TARGET NAME으로
비 DB2 목표 테이블을 지정합니다. FEDERATED 키워드를 사용해서 nickname 명과 owner를
지정하여 기본값을 변경할 수 있습니다.

예를 들면, 다음과 같은 특성으로 Q subscription을 생성하려면 아래의 명령문들을
수행합니다.
- 원본 서버는 SAMPLE 입니다. - Federated Q apply 서버는 (TARGET 키워드) FED_DB 입니다.
- 비 DB2 목표 서버는 (NONIBM SERVER 키워드) ORACLE_TARGET 입니다.
- 복제 큐 맵은(REPLQMAP 키워드) SAMPLE_ASN_TO_FED_DB_ASN 입니다.
- Q subscription 명은 (SUBNAME 키워드) FEDSUB 입니다.
- 오라클 데이터베이스의 목표 테이블은 EMPLOYEE 입니다.
- Federated Q apply 서버에서 EMPLOYEE 테이블을 가리키는 nickname은 EMPNICKNAME 입니다.
- Q subscription 은 수동 (E) 매뉴얼 방식을 사용합니다.(HAS LOAD PHASE 키워드)

ASNCLP SESSION SET TO Q REPLICATION;
SET SERVER CAPTURE TO DB SAMPLE;
SET SERVER TARGET TO DB FED_DB NONIBM SERVER ORACLE_TARGET;
SET CAPTURE SCHEMA ASN;
SET QMANAGER QM1 FOR CAPTURE SCHEMA;
SET QMANAGER QM2 FOR APPLY SCHEMA;
CREATE QSUB USING REPLQMAP SAMPLE_ASN_TO_FED_DB_ASN (SUBNAME FEDSUB
TARGET NAME EMPLOYEE FEDERATED EMPNICKNAME OPTIONS
HAS LOAD PHASE E);

비 DB2 목표에 대한 Q 복제 시작
비 DB2 목표에 대한 Q 복제를 시작하는 방법은 DB2 목표로의 복제와 동일합니다.
여기서는 WS MQ 채널과 리스너를 시작하는 방법을 설명하겠습니다.

시작하기 전에, 다음의 사항이 필요합니다.
앞서 설명한 WS QM 매니저, 큐, 채널 등이 생성되어 있어야 합니다.
Q capture 서버, 비 DB2 목표, federated Q apply 서버가 구성되어 있어야 합니다.
wrapper, server 정의, user mapping이 생성되어 있어야 합니다.
제어 테이블, 복제 큐 맵 및 Q subscription이 생성되어 있어야 합니다.
순서
비 DB2 목표로의 Q 복제를 시작하려면 다음의 과정을 수행하십시오.

1. Q capture에서 Q apply와 Q apply에서 Q capture 로의 WS MQ 채널을 시작하십시오.
A. 다음 명령을 통해 원본과 목표에 대한 큐 매니저가 동작중임을 확인하십시오.

     strmqm source_queue_manager_name
     strmqm target_queue_manager_name

B. 다음 명령을 수행하여 목표로부터 오는 메시지를 수신하는 소스 쪽 리시버의 리스너를
시작하십시오.
      runmqlsr -t tcp -m source_queue_manager_name -p source_port_numer

** 윈도우 환경에서는 runmqlsr 명령을 수행하면 새로운 명령창이 열리게 되어, 기존
명령창을 그대로 사용할 수 있습니다. UNIX 나 Linux에서는 명령문 끝에 '%'를 사용하십시오.

C. 다음 명령을 수행하여 원본 큐 매니저와 통신 세션을 시작하십시오.

     runmqsc source_queue_manager_name

D. 다음 명령을 수행하여 원본에서 sender 채널을 시작하십시오.

     start channel (source_sender_channel_name)

E. end 명령을 사용해서 원본 큐 매니저와의 통신 세션을 중지하십시오

F. 다음 명령을 수행하여 원본으로부터 오는 메시지를 수신하는 목표 쪽 리시버의
리스너를 시작하십시오.

      runmqlsr -t tcp -m target_queue_manager_name -p target_port_numer

G. 다음 명령을 수행하여 목표 큐 매니저와 통신 세션을 시작하십시오.

     runmqsc target_queue_manager_name

H. 다음 명령을 수행하여 목표에서 sender 채널을 시작하십시오.

     start channel (target_sender_channel_name)

2. Q capture 프로그램을 시작하십시오.

3. Q apply 프로그램을 시작하십시오.

Federated Q 복제의 제한사항
다음 사항은 WSII V8.1 FP9의 일반 및 데이터 유형 제한사항입니다.

일반 제한사항
- asntdiff 와 anstrep 유틸리티는 DB2 원본 테이블과 federated Q apply 서버의
nickname간의 데이터 타입이 일치해야 합니다.
- 기존에 존재하는 Q subscription 에 ADDCOL 시그널을 사용하여 칼럼을 추가하고자
할 경우, 목표 테이블 및 nickname에 해당 칼럼이 존재해야 합니다.
(nickname에는 칼럼을 추가할 수 없습니다.)

데이터 유형 제한사항
- LOB 유형은 오라클 목표에 대해서만 지원되며 NET8 wrapper를 필요로 합니다.
- GRAPHIC, VARGRAPHIC, DBCLOB 데이터 유형을 복제하기 위해서는, 오라클 버전이 9
이상이어야 합니다. 서버 매핑 역시 버전 9이상이어야 합니다.
- 오라클 및 Sybase로의 LONG VARGRAPHIC 유형의 복제는 FP 9에서는 지원되지 않습니다.
- Sybase : 원본 테이블의 칼럼이 LONG VARCHAR로 정의된 경우, nickname은 VARCHAR(32672)
형태로 생성됩니다. LONG VARCHAR의 길이 제한이 32672 이상이므로, 데이터가 절단될
수 있습니다.

---

XpertMon for DB2 UDB V2
DB 사업부
Tel : 02-2108-1458
Fax : 02-2108-1459
Mobile : 011-896-6545
E-mail : hjlee@iteg.co.kr
URL : http://iteg.co.kr

출처 : http://www.iteg.co.kr/a/b/content.asp?tb=i2&page=1&num=54