ProSync는 Archiving되지 않은 온라인 Redo Log는 추출하지 않고, Archiving이 완료된 Archive Log만을 추출하여 Apply 프로세스로 전달할 수 있다.

EXTRACT_ARCHIVE_LOG_ONLY=[Y|N]

ProSync의 Flow Control을 위해 사용되는 기능들을 정리한 문서이다. 데이터가 동기화되는 일련의 과정이 안정적으로 운영되기 위해선 데이터 처리 속도가 관건이다.

처리가 너무 느리다면 동기화 로직 상 데이터는 계속해서 쌓이게 된다. 쌓인 데이터를 계속해서 메모리에 적재하면 당연히 문제가 발생하기 때문에 임계값을 통해 데이터를 파일로 저장하거나 일시적으로 지연시키는 동작이 수행된다.

또한 처리 속도를 올리기 위해서 사용되는 기능들도 존재한다. 처리 속도가 빠르면 그만큼 추출한 데이터가 실시간성이 높게 반영이 된다는 의미이므로, 이 부분을 고려하여 환경 설정을 하는 것이 좋다.

마지막으로 에러가 발생했을 때, 정합성을 위해 기본적으로 동기화가 멈추게 되어있는데, 이렇게 되면 데이터가 더이상 처리될 수 없어서 영구적인 지연이 발생할 수 있다. 따라서 에러가 발생했을 때, 이를 자동으로 생략하거나 Rule에 맞춰서 데이터를 처리하는 방법에 대해서도 알아본다.

Process 설명

Apply 프로세스는 제품 설계에서도 언급했듯이 Chunk 단위로 레코드를 전달받고 해당 레코드를 트랜잭션별로 모아준다. 트랜잭션에 Commit이 오면 해당 트랜잭션은 실제 반영 단계에 들어가 대상이 되는 데이터베이스로 반영된다.

본 장에서는, 실제 apply 프로세스의 구조를 상세히 설명한다.

Threads

Apply 프로세스는 위와 같은 구조를 가지고 있다. 앞서 에서 ProSync의 기본 Thread 구조를 언급한 바 있는데, Apply도 마찬가지로 Main이 되는 Control Thread가 있고 이외에 Worker Thread들이 Control Thread 하위 계층에 구성되어 있다.

동기화에 필요한 Thread는 Construct Thread와 Replay Thread로 크게 두 가지이며, 나머지는 모두 Worker Thread로 구분된다.

Control Thread

Control Thread는 다른 프로세스와 마찬가지로 모든 통신과 관련된 Multiplexing I/O를 담당한다. 리눅스에선 epoll을 사용하며, 플랫폼별로 k-queue나 pollset 등 각 운영체제에 알맞은 Mux I/O 기능을 사용하도록 설계되어 있다.

Construct Thread는 _Chunk_로 들어오는 레코드 데이터들에 대해 트랜잭션으로 재조립한다. Construct라는 말의 의미는 트랜잭션을 다시 조립(Construct)하기 때문에 사용된다고 생각하면 된다.

각 레코드에는 본인이 속한 트랜잭션을 구분할 수 있는 일종의 key 값이 존재하는데, 이게 트랜잭션의 ID 일명 (xid)라고 불린다.

Construct는 레코드의 xid 값을 보고 트랜잭션별로 재조립한다.

Replay Thread는 Commit 레코드가 도달하여 Construct로부터 조립이 완료된 트랜잭션을 전달받는다. 전달받은 트랜잭션은 Commit 레코드의 DB Time(Oracle의 SCN / Tibero의 TSN / ..)에 맞게 직렬화되어 반영되거나, 트랜잭션 내 레코드들의 의존성을 모두 체크하여 병렬로 처리된다.

병렬로 처리하게 될 경우 Replay Thread의 개수가 많아지게 되며, 각 스레드가 DB의 한 세션을 담당하게 된다. 병렬 처리 가능 여부는 Control Thread에서 실시간으로 판단하며, 병렬 처리가 가능할 때 여러 Replay Thread에 일감을 부여하게 된다.

프로세스의 CPU / Memory 사용량을 실시간으로 수집한다. 수집된 내용은 로그상에 계속해서 남게 되며, 프로싱크 매니저와 연동 중일 경우, Agent 프로세스를 통해 수집한 값을 프로싱크 매니저로 전송한다.

프로세스에서 발생하는 트랜잭션의 시간당 처리량, 일종의 Throughput을 계산한다. 프로싱크 매니저와 연동 중일 경우, Agent 프로세스를 통해 수집한 값을 프로싱크 매니저로 전송한다.

ProSync에는 DML 이력을 확인할 수 있는 다양한 기능들이 있다. config파일에서 로그 레벨을 5레벨로 높이면, 반영하고 있는 SQL과 Bind할 Value들이 byte array 형태로 남게 된다. 다만 로그 레벨을 반드시 높여야 한다는 점과, bind value들이 별도로 남으므로 실제 SQL로 바로 처리할 수 없다는 단점이 있다.

본 장에서는 위와 같은 상황에서 확인할 수 있는 SAM(Sequential Access Method) 파일 기능과 DML 에러 발생 시의 report 파일, DML 이력 확인 기능 등에 대하여 기술한다.

커밋이 요청 트랜잭션은 반영을 할 수 있으면 반영을 하고, 반영을 할 수 없으면 큐에서 대기하게 된다. 반영 가능 여부는 반영하고자 하는 트랜잭션과 반영 중인 트랜잭션 간의 의존성 체크를 통해 서로 독립적일 경우 반영이 가능하다고 판단한다.

의존성 체크는 Table과 Row 단위 모두 확인을 한다. 트랜잭션은 레코드로 이루어져 있고, 레코드에는 레코드가 접근하는 Row가 정해져 있기 때문에, 해당 데이터를 기반으로 다른 트랜잭션과 의존 관계인지 여부를 판단한다.

의존성 확인 동작은 RedBlack Tree(RBT)와 Linked List로 관리가 되고 있다. Table 단위로 RBT를 확인하고, Table이 확인되면, 해당 Table 노드 내의 RBT에서 Row를 확인한다. 이 위치엔 Linked List가 존재하며, 트랜잭션은 해당 List에 의존성 객체(TX Dependency )를 달아 놓는다.

이 동작을 통해 트랜잭션이 접근하는 모든 Row에 대한 Linked List에 TX Dependency가 등록이 된다. 반영 중인 트랜잭션이나 반영 대기 중인 트랜잭션 모두 이 구조 안에서 관리된다.

반영 가능 여부는 트랜잭션의 모든 TX Dependency가 Linked List의 front에 존재하는 지의 여부로 확인한다. 하나라도 front에 존재하지 않는다면 반영이 불가능하고, 앞서 반영 중인 트랜잭션의 완료를 대기하게 된다.

반영이 가능한 경우는 위 그림과 같이 모든 의존성 체크를 했을 때 Linked List 상에 TX Dependency 가 가장 앞선 경우이다.

만약 위 그림과 같이 xid: 111인 트랜잭션이 아직 반영이 끝나지 않았다면 대기하게 된다. 반영이 완료된 트랜잭션은 위 Linked list에서 제거가 되고, xid: 112가 반영 가능하게 되면 반영 작업을 진행한다.

관련 파라미터는 REPLAY_THREAD_CNT 로, 해당 값이 올라가면 병렬 세션의 수가 많아진다. 하지만 위 로직에서 알 수 있듯이 결국 RBT 내에서 Table, Row단위로 TX Dependency가 잘 풀려야 병렬 반영이 가능하다. 이로 인해 숫자를 올린다고 반드시 올린 숫자만큼 정비례하게 증가하지 못하는 경우도 발생한다.

ProSync는 Extract 프로세스에서 Apply 프로세스로 데이터를 전송할 때 보안을 위한 데이터 암호화를 사용할 수 있다.

AES-256-CBC 암호화를 사용하며 Redo(Archive)log 에서 추출한 변경 데이터에 대한 암호화만을 제공한다.

사용

ENABLE_NETWORK_ENCRYPT=[Y|N]

해당 파라미터를 Y로 설정하는 경우 데이터 암호화 및 복호화 과정이 추가되므로 동기화 성능에 영향을 미칠 수 있다.

데이터가 처음 생성되는 위치는 Source DB의 Redo Log이다. Redo Log에서 발생된 데이터를 Extract 가 추출하여 Chunk 단위로 데이터를 적재한다.

적재된 데이터는 TCP Socket을 통해 전송이 된다. Non Blocking 통신이기 때문에 전체 데이터에 대한 전송이 실패하면, 이후의 데이터들은 Non Blocking Queue에 쌓이게 된다. 이 Queue에 쌓인 데이터는 커널로부터 반대쪽 TCP Recv Buffer가 비어있다는 신호가 올 때, 순서대로 다시 데이터를 보내게 된다.

Apply는 받은 데이터를 모두 객체화 (역직렬화) 하여 TX_HASH에 쌓이게된다. xid 는 트랜잭션 고유의 id 를 의미하며, ACID를 지켜주기 위해 트랜잭션의 커밋까진 이 위치에서 데이터를 계속 보관한다. 트랜잭션의 커밋이 들어오면 해당 트랜잭션은 Target Database에 반영이 가능한 상태로 판단하고 Replay Queue로 데이터를 넘겨준다.

Wait Queue에 쌓인 데이터는 트랜잭션들이 커밋된 순서에 맞게 Target Database로 반영이 된다. 이 때 반영 중인 트랜잭션과 반영 대기 중인 트랜잭션이 있을 텐데, 이들간의 의존성 검사를 통하여 시간 순서에 맞고, 의존성이 없는 트랜잭션들은 병렬 처리하여 성능을 높인다.

TX_HASH 에 데이터가 계속 쌓인다면 Out of Memory 를 피할 수가 없다. 따라서 특정 임계치를 넘어갈 경우 Part File이라는 이름으로 된 파일을 생성하여 이 위치로 데이터를 옮겨준다.

데이터를 옮기는 기준은 현재 TX_HASH

Data Conflict를 확인하려면 Row를 특정할 수 있어야 한다. ProSync에서는 이에 대한 기준을 Primary key로 두고 있다. Primary key 로 인해 충돌이 발생할 경우, Source Database, Target Database, Column Min(Max) 기준으로 데이터 Conflict에 대한 처리를 결정한다.

Insert문에서 충돌이 발생한다는 것은, 이미 데이터가 존재한다는 의미이다. 따라서 존재하는 데이터를 모두 Source Database 기준으로 맞춰주어야 한다.

Insert문을 Update로 변경하여 Conflict 을 해소해준다.

Update에서의 데이터 충돌은 원하는 Row가 없다는 의미이다.

Update문을 Insert로 변경하여 Conflict 을 해소해준다.

Delete에서의 데이터 충돌 또한 마찬가지로 Row가 없다는 의미가 된다.

Delete에 대한 추가적인 처리가 없이 넘어가면 된다.

Insert문의 충돌은 이미 데이터가 있을 때 발생하는데, Target Database 기준으로 맞춰야 하므로, 별도의 작업 없이 해당 처리를 건너뛴다.

APPLY 프로세스에서 DML 반영 시 MAP 파라미터로 지정한 History 테이블에 반영된 history 를 남기는 기능이다.

해당 기능을 사용하기 위해서는 기존 ProSync 동기화를 진행하는 인스턴스 이외에 DML History 기능 작동을 위한 인스턴스가 추가로 하나 더 필요하다.

APPLY 프로세스의 config 파일인 [inst_id]_apply1.cfg 파일에 다음의 파라미터를 설정해야 한다.

추가적으로 동기화 대상 테이블에 추가적인 column들이 필요하다.

Redo Log는 물리적인 위치에 대한 변경분이 남는다. RDBMS (주로 Oracle, Tibero) 에서는 row 데이터가 ROW_ID 라는 고유의 값을 가지게 되는데, 이 ID에는 데이터 파일의 위치, 파일 내 데이터 블록의 위치, 블록 내 row의 위치 에 대한 정보가 저장되어있다.

ProSync는 이 물리적으로 정해진 ROW_ID만 가지고는 Target Database에서 정확하게 어떤 row인지 판별할 수가 없다. 왜냐하면 데이터 파일도 다를 것이고, 블록 위치나 row 위치 정보도 모두 다르기 때문에 ROW_ID로는 서로 다른 Database의 row를 매칭 시키기가 어렵다.

따라서 SUPPLEMENTAL_LOGGING옵션 등을 통해 row 데이터의 추가적인 정보를 Redo Log상에 함께 남기게 된다. 예를 들면, 사용자가 Where Clause에 1개의 Column정보만 넣었다고 하더라도, Redo Log에는 해당 Row 내에 있는 모든 Column 정보가 다 남도록 해준다.

Target Database와 Apply 프로세스는 이 정보를 가지고 쿼리를 재구축한다. 다만 이렇게 되면, Primary key 를 가지고 있는 테이블 입장에선 불필요한 다른 컬럼 정보들을 Where Clause에 입력해주는 경우가 생긴다. Database의 플랜 별로 최적화되어 잘 처리될 수도 있지만, 불필요한 상황 자체를 방어하기 위해 ProSync에선 Primary key만 사용할지에 대한 여부를 파라미터로 관리한다.

Parameter 관련

USE_PK_FOR_WHERE 이 파라미터를 사용하면 Primary key가 있는 테이블에 대한 Update나 Delete 시에 Where Clause에는 Primary key만 입력하게된다.

APPLY 프로세스가 동기화 진행 중 DML 반영을 실패 또는 장애 상황이 발생했을 때 일정 횟수를 재시도 한 뒤 report 파일로 write하는 기능이다.

DML에 관해서만 기록이 가능하며, APPLY 프로세스의 config 파일인 [inst_id]_apply1.cfg 파일에 다음의 파라미터를 설정해야 한다.

Batch Execution은 RDBMS 상에서 우리가 사용하는 Batch 관련 API라고 이해하는 것이 용이하다. DML 각각을 모두 쿼리 형태로 변환하여 전달하기보단, 같은 형태의 쿼리라면 데이터를 Batch단위로 모아서 서버에서 사용하도록 하는 기능이다.

이 기능을 사용하면 Insert 와 같은 DML이 연속해서 들어올 때, Target Database 의 성능을 향상 시킬 수 있다. 이를 통해 데이터 처리 속도를 증가 시키고 동기화 속도를 끌어 올려줄 수 있다.

하지만 제약사항도 존재하는 기능으로, 아래와 같은 두가지 관점에서 고려할 수 있다.

• 같은 형태의 쿼리

• Batch로 모았을 때의 한계

ProSync는 한 트랜잭션에서 DML이 연속해서 들어올 때 이 순서를 임의대로 바꾸지 않는다. 입력되는 모든 쿼리를 순서대로 적용해야 정합성이 깨지지 않는다는 대전제 때문에 이와 같이 처리가 된다.

성능 향상을 위해, Apply 프로세스의 요청에 따라 Source DB에서 데이터 조회를 수행할 Read Thread의 개수를 설정할 수 있다.

LLOB_THREAD_CNT=[1-4]

Source DB가 Tibero인 경우, 암호화된 테이블에 대한 동기화를 지원한다. 암호화된 테이블 동기화를 위해서는 복호화를 위한 Wallet file 접근 권한이 필요하다.

TDE_FOR_EXT=[Y|N] TDE_WALLET_FILE=file_path TDE_WALLET_PWD=wallet_password TDE_FOR_APPLY=[Y|N] TDE_FOR_TABLESPACE=[Y|N]

ProSync는 Extract 프로세스에서 Apply 프로세스로 데이터를 전송할 때 네트워크 부하 감소를 위한 데이터 압축을 사용할 수 있다.

ENABLE_NETWORK_COMPRESS=[Y|N] NETWORK_COMPRESS_LEVEL=compress_level

ProSync Admin Utility

ProSync Admin Utility는 ProSync의 효율적인 사용을 위한 대화형 유틸리티이다. 이 유틸리티로 ProSync 프로세스의 기동, 정지, 일시정지와 같은 관리를 할 수 있다. 또한, ProSync 관리자는 시스템 관리를 위한 명령을 실행할 수 있다.

ProSync Admin Utility는 이러한 기본 기능 외에도 운영체제 관련 명령어의 실행, ProSync Admin Utility의 파라미터 확인, 스크립트 기능 등을 제공한다. 특히 스크립트 기능은 여러 ProSync Admin Utility 명령어를 하나의 스크립트 파일로 생성할 수 있어 편리하다.

ProSync Admin Utility는 다음과 같은 기능을 제공한다.

• ProSync INSTANCE_ID별 기동, 일시정지, 재개, 정지

• 특정 프로세스의 기동 및 정지

• 스크립트를 통한 일괄 작업의 실행

• ProSync 프로세스들의 상태 조회

• 운영체제 관련 명령어의 실행

• ProSync Admin Utility의 파라미터 설정 및 조회

• 수행한 명령어에 대한 이력 관리

Agent 프로세스는 Admin 프로세스 또는 ProSync Manager로부터 메시지를 수신하면, 이를 ext, apply, llob 프로세스에 전달하고, 처리 결과를 다시 Admin 프로세스 및 ProSync Manager에 전달한다. 또한, ext, apply, llob 프로세스의 기동, 종료 등의 작업을 수행한다. 추가적으로 CM Failover 기능을 사용하는 경우 CM 모니터링 및 하위 프로세스 모니터링 작업도 수행한다.

기동 시 다른 Thread 시작, 메시지 수신 및 전송 등의 작업을 수행한다.

ext, apply, llob 프로세스의 기동, 종료 등의 작업을 수행한다.

CM Failover 기능을 사용하는 경우 CM을 모니터링하여 CM 상태에 따라 하위 프로세스의 기동, 종료 작업을 수행한다. CM Failover 기능에 대한 자세한 내용은 을 참고한다.

Llob 프로세스는 Apply 프로세스의 요청에 따라 Source DB의 Long, Clob, Blob 등의 대용량 데이터를 전달하는 동작을 수행한다.

기동 시 다른 Thread 시작, 메시지 수신 및 전송 등의 작업을 수행한다. Apply Thread의 요청이 오는 경우, 적절한 Read Thread에 전달한다.

Apply Thread의 요청에 따라 Source DB에 flashback query를 통해 llob 데이터를 조회하고 이를 Control Thread를 통해 요청한 Apply 프로세스에 전달한다.

해당 시점으로 flashback query를 할 수 없다면, 현재 시점의 데이터를 조회한다.

ProSync Admin Utility는 다음과 같은 특성을 가진 인터페이스로 실행한다.

• ProSync Admin Utility가 정상적으로 실행되면 위와 같은 Admin 프롬프트가 출력된다. 프롬프트에서 ProSync Admin Utility 명령어를 입력할 수 있다.

• 대소문자를 구분하지 않는다.

다음은 ProSync Admin Utility 실행 화면이다.

위의 예에서는 ProSync Admin Utility를 실행한 뒤 HELP 명령어를 통해 ProSync Admin Utility가 지원하는 명령어를 확인할 수 있다. 이처럼 ProSync Admin Utility는 텍스트 모드의 화면에서 입력을 받고, 사용자의 요구에 따라 결과를 출력한다.

DML DISCARD

ProSync가 동기화 과정 속에 DML을 Target DB에 반영 중 에러가 발생할 수 있다. 일반적인 경우에는 ProSync가 해당 DML에 대한 반영을 성공할 때 까지 재시도하게 된다.

해당 기능을 사용하면 특정한 에러에 대해 재시도하는 대신 해당 DML에 대한 반영을 생략하고 이후의 동기화를 진행하도록 설정할 수 있다.

또한 DISCARD 기능이 발생한 이력을 기록하는 Discard file 을 작성할 수 있다.

해당 기능을 사용하기 위해선 config 파일에 다음과 같은 Parameter를 설정해야 한다.

DISCARD_YN=[Y|N]
DISCARD_EC=2 10007 8033
DISCARD_FILE_YN=[Y|N]

DISCARD_FILE_DIR=/directory/to/save/file
DISCARD_FILE_SIZE=200M
DISCARD_BACKUP_DIR=/directory/to/save/backup/file
DISCARD_BACKUP_SIZE=10G

DDL도 DML과 마찬가지로 Target DB에 반영 중 에러가 발생할 수 있다. 일반적인 경우에는 ProSync가 해당 DDL에 대한 반영을 성공할 때 까지 재시도하게 된다.

해당 기능을 사용하면 재시도하는 대신 해당 DDL에 대한 반영을 생략하고 이후의 동기화를 진행하도록 설정할 수 있다.

또한 DISCARD 기능이 발생한 이력을 기록하는 Discard file 을 작성할 수 있다.

해당 기능을 사용하기 위해선 config 파일에 다음과 같은 Parameter를 설정해야 한다.

개요

ProSync는 Source 데이터베이스의 Sequence 객체 값을 Target 데이터베이스로 실시간 동기화하는 기능을 제공한다. Sequence의 NEXTVAL이 호출되며 속성값이 갱신될 때 마다 Target으로 전달된다.

지원 환경

Source Tibero에서 Sequence의 NEXTVAL이 호출되면, 해당 값이 Target Tibero의 동일 Sequence에 실시간으로 반영된다.

1. Source와 Target에 동일한 이름의 유저 아래에 동일한 이름의 Sequence가 생성되어 있어야 한다.

2. ProSync 설치 스크립트가 정상적으로 수행되어 있어야 한다.

3. 동기화 대상 리스트 파일(기본값: prs_obj_group1.list) 파일에 SYS._DD_SEQ 테이블이 기재돼 있어야 한다.

4. 동기화 대상 리스트 파일(기본값: prs_obj_group1.list) 파일에 동기화하고자 하는 SEQUENCE가 기재돼 있어야 한다.

1. Sequence 생성 시 NOCACHE 옵션으로 생성 필요하다.

2. Source, Target DB 의 동기화 대상이 되는 SEQUENCE 짝의 설정값은 일치해야 한다.

3. 프로싱크에서 Sequence ALTER 수행 시 타겟 DB에서 SYS._DD_SEQ NEXTVAL 값을 기준으로 Boundary Check를 수행하기 때문에, 타겟 NextVal 값보다 MAX/MIN 값이 더 작은/큰 경우, TBR-7134 에러가 발생한다.

Source Oracle에서 Sequence의 NEXTVAL이 호출되면, 해당 값이 Target Tibero의 동일 Sequence에 반영된다. Target의 Sequence 값이 Source 와 겹치지 않고, 동일하거나 앞서가도록 동기화가 진행된다.

1. Source Oracle과 Target Tibero에 동일한 이름의 Sequence가 생성되어 있어야 한다.

2. ProSync 설치 스크립트가 정상적으로 수행되어 있어야 한다.

3. 동기화 대상 리스트 파일(기본값: prs_obj_group1.list) 파일에 SYS.SEQ$ 테이블이 기재돼 있어야 한다.

4. 동기화 대상 리스트 파일(기본값: prs_obj_group1.list) 파일에 동기화하고자 하는 SEQUENCE가 기재돼 있어야 한다.

1. Source, Target DB 의 동기화 대상이 되는 SEQUENCE 짝의 설정값은 일치해야 한다.

2. SEQUENCE 값의 정합성을 위해 ORDER 옵션의 사용이 권장된다.

ProSync는 특정 사용자에 의해서 발생된 DML 및 DDL을 동기화에서 제외할 수 있는 기능을 제공한다.

양방향 동기화

같은 테이블에 대해 Source DB에서 Target DB로, Target DB에서 Source DB로 동기화 하도록 2개의 Prosync 인스턴스를 사용하여 구성할 수 있다. 이 경우, 별 다른 설정이 없다면 상대방의 PRS_USER가 반영한 동기화 데이터가 다시 추출되어 Source DB로 전송될 수 있다.

Redo Log에는, tx에 대해 이를 수행 한 User를 알 수 있는 정보가 있으며 ProSync는 이 정보를 활용해 상대방의 PRS_USER로 EXCLUDE_USER 파라미터를 설정하여 이미 반영한 데이터를 재반영하는 현상을 막을 수 있다.

사용

다음은 TEST 사용자와 PRS_USER 사용자를 동기화에서 제외하는 예제이다.

EXCLUDE_USER=PRS_USER.TEST

설치

ProSync Admin Utility는 ProSync를 설치하는 과정에서 함께 설치된다.

실행

ProSync Admin Utility를 실행하는 명령어의 문법은 다음과 같다.

prs_adm [options] [script]

options

ProSync Admin Utility 실행 과정은 다음과 같다.

ProSync Admin Utility가 정상적으로 실행되면 위 예제처럼 Admin 프롬프트가 나타난다.

이 프롬프트에서 데이터베이스 사용자는 ProSync 관리를 위한 명령을 실행할 수 있다.

Process 설명

Extract 프로세스는 Source DB의 변경 로그를 추출하여 Apply 프로세스로 전달하는 동작을 수행한다.

Source DB가 Tibero 또는 Oracle인 경우, redo log를 읽어 변경 로그를 추출하므로 반드시 redo log에 접근 가능한 위치(일반적으로 Source DB가 존재하는 장비)에서 기동되어야 한다.

변경의 최소 단위는 LCR로, 레코드 단위의 변경을 의미하며 네트워크 부하를 고려하여 여러 LCR을 Chunk로 만들어 Apply 프로세스에 전달한다.

Threads

Control Thread

기동 시 다른 Thread 시작, 메시지 수신 및 전송 등의 작업을 수행한다.

Resource Thread

프로세스의 CPU/Memory 사용량을 수집한다. ProSync 매니저 사용 시, Agent 프로세스를 통해 수집한 값을 프로싱크 매니저로 전송한다.

동기화 테이블 추가, 동기화 할 테이블 및 컬럼들의 정보인 DD image 조회, DB의 상태 파악을 위한 dummy tx 생성 등 변경 데이터 추출과는 상관없는 메타데이터 조회나 수정과 같은 작업을 수행한다.

추출한 변경을 Text 파일로 출력하는 SAM 기능을 수행한다.

변경 데이터를 추출하고 이를 Chunk형태로 만든 뒤 Control 스레드를 통해 Apply 프로세스에 전달한다.

Log Reader 라이브러리를 사용해 redo log에 접근하며 비정상 종료, Apply 프로세스 재연결 등의 장애 상황 발생 시, 마지막으로 읽고 있던 redo를 처음부터 다시 읽기 시작한다.

추출 시작 지점은 Apply 프로세스에 저장되어 있기 때문에, Apply 프로세스와 연결 전까지는 추출을 시작하지 않는다.

PRS_OBJ_LIST

동기화할 object들의 Type, Owner, Name, 등록 시기를 저장한다.

PRS_TXINFO

tlr(olr)파일의 위치, seq 정보를 저장한다.

tlr(olr)파일은 Redo Log를 모두 읽고 다음 Log를 읽기 전 아직 commit되지 않은 tx 정보를 저장한 파일로 ProSync는 Begin이 없는 tx에 대해서는 추출하지 않기 때문에, 기동 시점에 따라 누락되는 tx가 없도록 이전 Redo Log를 읽었을 때 아직 commit되지 않은 tx 정보를 저장한다.

PRS_DDL_HIST

발생한 DDL의 시점, DDL 종류, 메타 테이블 업데이트 여부, 이후 ProSync가 사용하는 DD의 Sequence 정보를 저장한다.

PRS_DICT_HIST

Source DB가 Oracle이며 Log Miner를 사용하여 동기화 하는 경우 사용한다. DD 정보를 저장한 dict파일 정보를 저장한다.

PRS_DD_USR

Source DB에 존재하는 USER들의 이름과 USER_ID를 저장한다. User Filtering 기능을 사용하기 위해 저장한다.

PRS_DD_TBL

동기화 테이블의 DD sequence, object id, 테이블명 정보를 저장한다. Redo Log는 object id만 남기기 때문에, 해당 정보를 Apply 프로세스에 전달하여 적절하게 반영 쿼리를 생성한다.

특정 object_id가 어느 테이블에 속하는지 정보를 저장한다.

파티션 등에 저장되는 데이터는 테이블과는 다른 object_id를 남기기 때문에, 해당 데이터를 문제없이 추출하기 위해 파티션의 object_id와 테이블의 object_id를 매핑한다.

컬럼의 속성과 어느 테이블에 속하는지 정보를 저장한다. Redo Log는 컬럼 속성 정보를 남기지 않기 때문에, 해당 정보를 Apply 프로세스에 전달하여 적절하게 반영 쿼리를 생성한다.

컬럼의 제약 조건 정보를 저장한다. Apply 프로세스의 Parallel Replay에서 적절하게 반영 순서를 조합하기 위하여 사용된다.

테이블의 암호화 정보를 저장한다. Apply 프로세스에서 복호화하기 위해 저장한다.

변경 데이터가 없는 경우에도 추출, 반영에 문제 없는지 확인용으로서 주기적으로 부하를 발생시키기 위한 목적으로 사용된다. 부하가 없는 경우, 주기적으로 해당 테이블에 대한 부하를 발생시킨다.

Source DB가 Oracle이며 Log Miner를 사용하여 동기화 하는 경우 사용한다. 마지막으로 추출한 시점 정보를 저장한다.

시퀀스 동기화를 위한 정보를 저장한다.

ProSync의 초기적재 기능을 사용하기 위한 정보를 저장한다.

Source DB가 Oracle이며 Log Miner를 사용하여 동기화 하는 경우 사용한다. instance 이름을 저장한다.

시스템 변수

시스템 변수는 SET 명령어를 통해 변경할 수 있다.

HISTORY

명령어 히스토리의 크기를 설정한다.

SET HIS[TORY] {n}

화면상의 한 라인의 길이를 설정한다. 라인 길이의 최소값은 1이며, 최댓값은 운영체제에 따라 다르다.

NUMBER 타입을 출력할 길이를 설정한다. LINESIZE를 넘을 수 없다.

한 화면에 출력할 라인 수를 설정한다.

화면상의 프롬프트 문자를 설정한다.

파일 확장자를 생략했을 때 사용할 파일 확장자를 설정한다.

다음은 ProSync Admin Utility 명령어를 표현하는 사용법의 예이다.

위의 예를 기준으로 ProSync Admin Utility에서 사용하는 명령어의 문법을 해석하는 방법은 다음과 같다.

ProSync는 동기화 과정 중에 전달하는 세그먼트를 파일에 순차적으로 기록할 수 있다. APPLY 프로세스에서 Target DB에 반영하는 STATEMENT 를 파일에 저장할 수 있는데, 이를 SAM 기능이라고 한다.

다음은 SAM 기능을 지원하는 데이터 타입이다.

[INST_ID]_apply1.cfg 파일에 다음의 파라미터를 설정해야 한다.

본 절에서는 TX_SAM_TEMPLATE, STMT_SAM_TEMPLATE, COL_SAM_TEMPLATE 파라미터에서 사용할 템플릿을 설정하는 방법에 대해 서술한다.

템플릿 구성요소는 '% + 알파벳 하나(대소문자 구분)"으로 구성하며, 이렇게 구성된 표현값을 치환하여 Sam File에 출력한다.

테이블, 컬럼 매핑 기능을 사용하기 위해서는 $PRS_HOME/config 디렉터리의 Apply config file인 '[INST_ID]_apply1.cfg'를 설정한다.

다음은 설정해야 할 파라미터에 대한 설명이다.

기본 MAP 파라미터에 Source DB의 특정 테이블을 Target DB의 특정 테이블로 동기화하기 위한 규칙을 설정한다.

MAP=([SYNC OPTION] SOURCE_USER.SOURCE_TABLE [SOURCE_COLUMNS]
     [COLUMN FILTERING OPTION],
     [TARGET_DATABASE.]TARGET_USER.TARGET_TABLE [TARGET_COLUMNS]
     [RESOLVE OPTION] [SKIP OPTION]))

다음은 MAP 파라미터를 이용해서 동기화 대상 반영 기능을 사용하는 방법에 대한 예제이다.

다음은 Source DB의 PROSYNC1 사용자의 T1 테이블을 Target DB의 PROSYNC2 사용자의 T2 테이블로 동기화하는 예제이다.

다음은 Source DB의 PROSYNC1 사용자의 T1 테이블에 컬럼 C1, C2, C3가 있고, 이중 C1와 C2 컬럼만 Target DB의 PROSYNC2 사용자의 T2 테이블의 C1, C2 컬럼과 동기화하는 예제이다.

다음은 Source DB의 PROSYNC1 사용자의 T1 테이블에 컬럼 C1, C2, C3가 있고, 이중 C1와 C2 컬럼만 Target DB의 PROSYNC2 사용자의 T2 테이블의 D1, D2 컬럼과 동기화하는 예제이다.

동기화 테이블 사용여부를 설정한다.

동기화 테이블을 지정하는 경우 SYNC OPTION에 TABLE을 설정한다.

동기화 대상이 아닌 오브젝트의 DDL 매핑을 지정하는 경우 SYNC OPTION에 OBJECT를 설정한다.

동기화 대상 테이블에 대해서는 앞서 설명한 TABLE 규칙을 따라 DDL 매핑이 지원되며, TABLE 규칙이 명시되지 않은 경우 매핑 없이 동기화된다. 동기화 대상으로 설정할 수 없는 INDEX 등의 OBJECT나 동기화 대상이 아닌 테이블에 대해서만 해당 규칙으로 설정할 수 있다. OBJECT 규칙에 대해서는 반드시 위의 형태로만 사용 가능하다. OBJECT_NAME에 와일드 카드로 '%'를 입력할 수 있다. 이 경우 [SOURCE_USER]의 임의의 OBJECT [SOURCE_USER].[OBJECT_NAME]을 [TARGET_USER].[OBJECT_NAME]에 DDL 매핑하여 DDL을 동기화한다.

동기화를 제외할 테이블을 지정하는 경우 SYNC OPTION에 EXCLUDE를 설정한다.

Source DB의 PROSYNC 사용자의 SKIP 테이블을 제외하고 동기화 할 때 다음과 같이 '[INST_ID]_apply1.cfg'의 MAP 파라미터를 설정한다.

COLUMN FILTERING OPTION을 사용하여 일부 컬럼에 대한 동기화를 제거할 수 있다. 다만 Constraint가 걸려있는 컬럼에 대해서는 해당 옵션을 사용할 수 없다.

다음과 같이 COLUMN FILTERING OPTION을 사용할 수 있다.

Source DB의 PROSYNC1 사용자의 T1 테이블에 컬럼 C1, C2, C3가 있고, 이중 C1 컬럼만 제외하고 Target DB의 PROSYNC2 사용자의 T2 테이블의 C2, C3 컬럼과 동기화할 경우 다음과 같이 '[INST_ID]_apply1.cfg'의 MAP 파라미터를 설정한다.

동기화 시 충돌 상황에서 Source DB에 정합성 기준을 맞출 지, Target DB에 정합성 기준을 맞출 지, 아니면 특정 컬럼의 Min 혹은 Max 값 기준으로 데이터 정합성을 맞출 지를 결정하는 옵션이다. 필수 옵션은 아니며 주로 양방향 동기화에 사용된다.

정해진 Rule에 따라 DML 들이 변경되거나 생략 된다.

다음은 RESOLVE OPTION에 설정할 수 있는 RESOLVE_RULE의 종류이다.

MAX와 MIN RESOLVE_RULE의 경우에는 반드시 DEFAULT OPTION을 설정해야 한다. 컬럼 값이 null인 경우에 설정한 DEFAULT 값으로 비교한다. 단, 동기화는 설정한 DEFAULT 값이 아니라 실제 컬럼 값으로 수행한다.

UPDATE을 동기화하는 경우 MIN, MAX Rule을 사용한다면 비교 대상 컬럼의 변경 유무에 따라 다르게 비교를 수행한다. 비교 대상 컬럼이 변경되었다면 변경된 값, 변경되지 않았다면 기존 값으로 Target DB의 row와 비교를 진행한다. 비교 대상 컬럼이 NULL인 상태에서 UPDATE가 발생하는 경우 비교가 불가능하기 때문에 비교 없이 Source DB 값을 우선으로 DML을 수행한다.

예를 들어 DB1과 DB2간의 양방향 동기화하는 경우 DB1의 PROSYNC 사용자의 T1 테이블을 DB2의 PROSYNC 사용자의 T1 테이블로 동기화하고, column c3의 값이 더 큰 값을 우선하고자 하는 경우 마지막으로 INSERT할 때 DCR 컬럼인 c3에 null이 들어가는 경우 10으로 비교할 경우 다음과 같이 설정한다.

SKIP OPTION에는 동기화하지 않길 원하는 row들을 특정하기 위한 조건을 설정한다.

SKIP OPTION은 다음과 같이 설정한다. SKIP_CONDITION이 True인 Row들은 동기화하지 않는다.

Source DB의 PROSYNC 사용자의 T1 테이블을 Target DB의 PROSYNC 사용자의 T1 테이블로 동기화하고, column c1의 값이 'example'이 아니면 DML을 skip할 경우 다음과 같이 MAP 파라미터를 설정한다.

위의 조건에 추가로 Source DB의 PROSYNC 사용자의 T2 테이블을 Target DB의 PROSYNC 사용자의 T2 테이블로 동기화하고, column c2의 값이 'example2'이면 DML을 skip할 경우 다음과 같이 MAP 파라미터를 설정한다.

ProSync 사용자는 적용 프로세스의 설정 파일에서 DDL 파라미터를 설정할 수 있다. DDL 파라미터는 동기화 할 DDL에 대한 설정이다.

DDL 파라미터는 하나 이상의 DDL Rule 문장으로 구성된다. DDL Rule에는 DDL 동기화를 포함/배제할 대상과 DDL 종류를 명시할 수 있다.

사용법

DDL=([SET] [RANGE], TYPE=('[DDL OPERATION] [DDL OBJECT]', ...))

다음은 Source DB에 따라 설정 가능한 [DDL OPERATION]과 [DDL OBJECT]의 조합이다.

다음은 모든 스키마에 대해서 모든 종류의 DDL 동기화를 하지만, 스키마 EXCLUDED_USR의 모든 테이블에 대한 DDL 동기화는 배제하는 예제이다.

다음은 동기화 대상 테이블에 대해 TABLE을 대상으로 하는 DDL을 동기화하고, INCLUDED_USR의 모든 오브젝트 이름에 대해 INDEX를 대상으로 하는 DDL을 동기화한다. 반면, 오브젝트 이름이 EXCLUDED_USR.IDX1일 경우 INDEX를 대상으로 하는 DDL을 동기화하지 않는다.

다음은 SRCUSR의 모든 테이블에 대해 TYPE에 해당되는 DDL을 동기화하지만, SRCUSR.T1에 대해서는 DROP TABLE과 CREATE TABLE에 해당되는 DDL을 동기화하지 않는다.

• DDL 문장 크기 동기화 할 DDL 문장의 각 요소는 128글자를 넘을 수 없다.

• 설정 전 확인 DDL 파라미터의 대상과, 동기화 할 DDL 종류가 정확한지 Wildcard를 고려하여 확인하고 설정한다. 다른 DB나 대상에게 먼저 적용해보고 설정하는 것을 권장한다.

• CREATE TABLE 이후 동기화 CREATE TABLE에 대한 DDL 동기화 후 생성된 테이블을 DML 동기화 하려면 수동으로 동기화 대상 추가를 해야한다. 반면 DDL은 Rule에 의해 생성된 직후부터 동기화 될 수 있으므로 주의한다.

• implicit DDL CREATE TABLE에 대한 DDL 동기화 실행 중 컬럼의 PRIMARY KEY로 인해 INDEX 생성이 되는 것처럼 명시되지 않은 DDL을 implicit DDL이라 하며, 동기화 설정할 때 이를 주의한다.

! / HOST

ProSync Admin Utility 내에서 운영체제의 명령어를 실행한다.

! [command]
HO[ST] [command]

운영체제의 명령어 없이 ! 명령어만 입력하면 운영체제의 명령 프롬프트로 나가서 운영체제의 명령어를 여러 번 입력할 수 있다.

이때 다시 ProSync Admin Utility로 돌아오려면 EXIT 명령어를 입력한다.

다음은 현재 디렉터리에 내에 확장자가 ext인 모든 디렉터리와 파일 목록을 출력하는 예제이다.

특정 스크립트 파일을 실행한다. 파일의 확장자가 SUFFIX 시스템 변수에 등록되어 있으면, 확장자를 생략하고 파일명을 지정할 수 있다.

스크립트 실행 전에 SET 명령어로 설정된 시스템 변수는 실행 도중에도 유효하다. 스크립트 내에서 EXIT 또는 QUIT 명령어를 실행하면 ProSync Admin Utility가 정지한다.

다음은 현재 디렉터리 내의 스크립트 파일을 실행하는 예제이다.

ProSync Admin Utility 내에서 히스토리 버퍼에 저장된 명령어를 재수행한다. 사용자는 지정된 숫자에 해당하는 명령어를 반복 실행할 수 있다.

다음은 히스토리 버퍼에 저장된 'HELP' 명령어를 재수행하는 예제이다:

ProSync 운영 중에 동기화 대상 테이블을 추가/제거 하거나, 기동 중인 ProSync 프로세스의 Parameter를 변경할 수 있다.

동기화 테이블 추가/제거의 경우, 기동 전에 prs_obj_group1.list에 추가하지 못했던 테이블을 ProSync 운영 중에 동적으로 추가할 수 있다. Source DB를 오라클을 사용하고, 로그마이너를 통한 추출을 하는 경우 다음과 같은 동작을 수행해야 동적 동기화 테이블 추가가 가능하다.

1. 소스 오라클, 타겟 티베로 동기화 대상 테이블 생성(CREATE 수행)

2. admin> ALTER [Top_ID] ADD TABLE 수행 SUPP LOG 추가

3. 소스 오라클 ALTER SYSTEM SWITCH LOGFILE 수행

4. DML/DDL 동기화 확인

Parameter 변경의 경우, 수정을 원하는 Parameter의 유형이 Dynamic 인 경우에만 변경할 수 있다.

ProSync Admin Utility를 정지한다. 현재 진행 중이던 프로세스에 영향을 전혀 주지 않고 Utility만 정지된다.

Admin 명령어 사용에대한 도움말을 화면에 출력한다.

옵션을 지정하지 않으면 ProSync Admin Utility에서 사용할 수 있는 전체 명령어를 출력한다.

다음은 SET 파라미터에 대한 도움말을 화면에 출력하는 예제이다.

사용자가 입력한 INST_ID의 작업을 멈추는 명령어이다.

모든 프로세스가 정지하는 것이 아닌, 추출이 더 이상 데이터를 추출하지 않도록 하는 기능이다. 즉 현재 반영중인 내용이나 이미 소켓을 타고 넘어간 데이터들에 대한 반영은 이루어진다.

다음은 'prosync4'의 작업을 일시정지하는 예제이다.

사용자가 입력한 INST_ID의 작업을 재개하는 명령어이다.

PAUSE 의 동작을 되돌리는 것으로, 추출이 다시 시작되는 기능으로 볼 수 있다.

예제

ProSync Admin Utility의 시스템 변수를 설정한다.

SET 명령어로 설정된 시스템 변수는 SHOW 명령어를 사용하여 출력한다. 단, 변경된 시스템 변수는 현재 세션 내에서만 유효하다. 각각의 시스템 변수에 대해서는 를 참고한다.

예제

ProSync Admin Utility의 시스템 변수 및 각 프로세스의 파라미터를 출력한다.

다음은 시스템 변수를 출력하는 예제이다.

다음은 'prosync4' 에 속한 프로세스들의 파라미터를 출력하는 예제이다.

다음은 'agent1' 에 속한 모든파라미터를 출력하는 예제이다.

사용자가 입력한 INST_ID의 프로세스 혹은 매니저 프로세스를 정지한다.

다음은 'pro'의 프로세스를 정지하는 예제이다.

다음은 'agent1'의 매니저 프로세스를 정지하는 예제이다.

사용자가 입력한 INST_ID의 프로세스를 실행한다.

다음은 'agent1'의 매니저 프로세스를 실행하는 예제이다.

다음은 'pro' instacne를 실행하는 예제이다.

전체 프로세스, 사용자가 입력한 INST_ID의 프로세스 혹은 매니저 프로세스의 상태를 확인하는 명령어이다.

전체 프로세스의 상태를 조회하는 경우 STATUS 명령어만 사용한다.

다음은 모든 Instance(inst_id) 프로세스를 조회하는 예제이다.

다음은 Instance(inst_id)가 'prosync4'인 모든 프로세스 및 스레드의 상태를 조회하는 예제이다.

Instance의 apply 프로세스가 Target DB에 반영 중인 Query의 정보를 출력한다.

다음은 MONITOR 명령어를 통해 현재 적용 중인 쿼리를 조회하는 예제이다.

ProSync Admin Utility에서 주로 사용하는 기능은 명령어를 직접 입력하여 프로세스를 실행하고 정지하고 일시정지하는 것이다. ProSync Admin Utility 명령어는 실행을 위한 명령어가 따로 없으며, 입력된 명령어는 버퍼에 저장된다. ProSync Admin Utility 명령어는 입력을 마침과 동시에 실행된다.

위의 예는 INST_ID가 prosync4인 모든 프로세스를 실행하는 명령어의 입력 및 실행 결과를 보이고 있다. INST_ID의 추출, 적용, LONG/LOB 프로세스가 각각 기동된다. 예제의 명령어를 입력하기 이전에 해당 INST_ID에 연결되어 있는 매니저 프로세스를 실행시켜야 한다.

INST_ID를 정지하면, 매니저 프로세스를 제외한 추출, 적용, LONG/LOB 프로세스가 중단된다.