설치

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

실행

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

prs_adm [options] [script]

options

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

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

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

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

Admin>

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

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

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

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

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의 파라미터 설정 및 조회

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

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

Source DB가 Tibero, Oracle인 경우, 암호화된 테이블에 대한 동기화를 지원한다. 암호화된 테이블 동기화를 위해서는 복호화를 위한 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의 Flow Control을 위해 사용되는 기능들을 정리한 문서이다. 데이터가 동기화되는 일련의 과정이 안정적으로 운영되기 위해선 데이터 처리 속도가 관건이다.

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

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

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

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 기능에 대한 자세한 내용은 을 참고한다.

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

EXTRACT_ARCHIVE_LOG_ONLY=[Y|N]

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

LLOB_THREAD_CNT=[1-4]

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

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

시스템 변수

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

HISTORY

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

SET HIS[TORY] {n}

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

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

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

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

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

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

ProSync는 이 물리적으로 정해진 ROWID만 가지고는 Target Database에서 정확하게 어떤 row인지 판별할 수가 없다. 왜냐하면 데이터 파일도 다를 것이고, 블록 위치나 row 위치 정보도 모두 다르기 때문에 ROWID로는 서로 다른 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만 입력하게된다.

Source DB가 Tibero인 경우, 압축된 테이블에 대한 동기화를 지원한다. 압축 테이블의 변경 데이터는 Redo Log에 압축 심볼 참조 형태로 기록되며, Extract 프로세스는 Supplemental Log에 포함된 심볼 매핑 정보를 이용하여 이를 원본 값으로 복원한 후 동기화한다.

압축 테이블 동기화를 위한 별도의 파라미터 설정은 필요하지 않으며, 다음 조건을 만족하면 자동으로 동작한다.

• 동기화 대상 테이블에 Supplemental Logging이 설정되어 있어야 한다.

• Source DB(Tibero)와 ProSync 모두 압축 테이블 동기화를 지원하는 버전이어야 한다.

SQL> CREATE TABLE TEST.T_COMP (C1 VARCHAR(2000), C2 NUMBER) COMPRESS FOR OLTP;
SQL> ALTER TABLE TEST.T_COMP ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

지원 범위

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 이름을 저장한다.

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

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

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

• 같은 형태의 쿼리

• Batch로 모았을 때의 한계

같은 형태의 쿼리

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

문제는 이렇게 되면 Insert * 3, Update*3, Delete* 3의 순서로 데이터가 들어올 때와 (Insert, Update, Delete) * 3의 순서로 데이터가 들어올 때 Batch Execution 입장에서 큰 차이가 발생한다.

유사한 쿼리가 연속해서 들어온다면 ProSync는 이를 Batch로 묶어서 처리를 할 수가 있지만, 쿼리들의 형태가 연속적이지 않게 들어온다면 Batch로 처리할 수가 없다. 따라서 두 트랜잭션의 결과가 동일하더라도 하나는 Batch 처리가 가능하고 다른 하나는 Batch 처리가 불가능하다.

트랜잭션 내에 같은 형태의 쿼리들이 연속해서 들어온다고 가정을 하여도 성능 향상이 미미한 경우도 존재한다. 예를 들어 Insert의 경우 Batch 동작을 통해 데이터의 개수나 크기 등을 Target Database에 미리 알려준다면 Database는 이에 맞는 플랜을 세워서 최적화 하여 처리가 가능하다. 하지만 Delete나 Update 처럼 각 row 별로 Where Clause에 의해 따로 탐색을 해야 하는 형태로 들어온다면 아무리 모아 보내도 서버 입장에선 하나씩 처리하나, 모아서 들어온걸 하나씩 처리하나 큰 차이가 없다고 볼 수 있다.

따라서 ProSync는 특별한 설정이 없다면 Insert에 대한 Batch만 처리하는 것이 기본 동작이다. 하지만 Database 별로 처리하는 방식이 달라질 수 있기 때문에 Batch 사용 여부는 파라미터로 모두 관리가 된다.

Parameter 별 제공하는 기능이다.

• USE_BATCH_MODE 기본 값은 Y 로, Batch는 항상 동작하도록 되어있다.

• BATCH_MEM_SIZE 기본 값은 10MB로 서버에 보낼 때 최대 10MB의 데이터까지만 쌓고 쿼리에 대한 처리를 요청한다.

• USE_ONLY_INSERT_BATCH Insert 만 Batch 로 처리할 것 인지에 대한 파라미터로 기본 값은 Y 이다.

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

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

사용

ENABLE_NETWORK_ENCRYPT=[Y|N]

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

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

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

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

Source DB가 PostgreSQL인 경우에는 WAL logical replication 연결(network)을 통해 변경 로그를 추출하므로 반드시 Source DB 서버에 기동될 필요는 없으며, Source DB에 network로 접속할 수 있고 replication 권한이 있는 위치라면 기동할 수 있다.

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

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

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

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

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

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

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

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

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

해당 시점으로 flashback query를 할 수 없는 경우의 동작은 LLOB_FLASHBACK_ERROR 파라미터 설정에 따라 다르다.

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

의존성 체크는 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 가 가장 앞선 경우이다.

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

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

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

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

DCR의 제약사항

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

시나리오

Resolve By Source

1. Insert

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

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

2. Update

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

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

3. Delete

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

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

Resolve By Target

1. Insert

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

2. Update

Row가 없는 상황이 맞다고 판단하기 때문에 별도의 작업 없이 해당 처리를 건너뛴다.

3. Delete

Row가 없는 상황이 맞다고 판단하기 때문에 별도의 작업 없이 해당 처리를 건너뛴다.

Resolve By Min/Max

위 두 경우에 대한 조합으로 볼 수 있다. 상황에 따라 Source 기준 또는 Target 기준에 맞춰 수행하는 시나리오다. 기준이 되는 것이 Database 단위가 아닌 Column 내 데이터의 대소 비교로 이루어진다는 점이 다르고, 이에 따라 충돌 처리 동작은 위의 Source / Target과 동일하게 작동한다.

데이터가 처음 생성되는 위치는 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에 있는 데이터들 중 가장 용량이 큰 트랜잭션 기준으로 파일로 내려가게 되며, 내려간 파일은 실제 반영이 되는 시점까진 계속 Disk에 남게 된다

Process 설명

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

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

Threads

Apply 프로세스는 위와 같은 구조를 가지고 있다. 앞서 Inter Processes/Threads Communication에서 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

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 사용량을 실시간으로 수집한다. 수집된 내용은 로그상에 계속해서 남게 되며, ProSync 매니저와 연동 중일 경우, Agent 프로세스를 통해 수집한 값을 ProSync 매니저로 전송한다.

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

Apply는 재기동이나 재연결 이후에도 중복 반영 없이 이어서 동기화할 수 있도록 복구 상태를 여러 저장소에 나누어 관리한다.

재연결 시 Apply는 저장된 이력 정보를 Ext에 전달하여(handshake) 재추출 시작점을 결정한다. Ext는 그 지점부터 다시 추출하므로 일부 레코드가 재전송될 수 있으며, Apply는 PRS_COMMITTED_TX_LIST를 통해 이미 반영이 완료된 트랜잭션을 건너뛴다.

재기동 유형별 복구 절차와 장애 시나리오는 를 참고한다.

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

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

ProSync는 Source Oracle이 ASM(Automatic Storage Management)을 사용하는 환경에서 ASM Diskgroup에 저장된 Redo Log와 Archive Log를 추출할 수 있다.

ASM Diskgroup의 파일은 운영체제 파일 시스템에 그대로 노출되지 않으므로 일반적인 파일 읽기로는 접근할 수 없다. Extract 프로세스는 ASM 인스턴스에 직접 접속하여 Diskgroup 경로(+로 시작하는 경로)의 로그 파일을 읽는다.

지원 범위

Extract 프로세스는 읽으려는 로그 파일의 경로를 보고 읽기 경로를 결정한다.

경로에 따라 읽기 경로가 결정되므로 Redo Log와 Archive Log 중 일부만 ASM Diskgroup에 저장된 혼합 구성에서도 사용할 수 있다. ASM 사용 여부를 지정하는 별도의 파라미터는 없으며, ASM 접속 정보를 설정하면 ASM 경로의 파일에 대해 ASM 읽기가 사용된다.

ASM 경로의 로그를 읽을 때 Extract 프로세스는 ASM 인스턴스에 ASM_IO_WORKERS 개수만큼 병렬 I/O Worker 세션을 만든다. 각 Worker는 로그 파일 읽기만 수행하고, 읽어온 Redo의 분석은 로그 리더가 별도로 수행한다.

ASM_IO_WORKERS는 Extract 프로세스 기동 시에만 반영되므로, 값을 변경한 경우 Extract 프로세스를 재기동해야 한다.

Extract 프로세스가 ASM 인스턴스에 접속할 별칭을 tnsnames.ora에 등록한다. 이 별칭을 ASM_DB_NAME에 설정한다.

ASM 접속 계정은 ASM 인스턴스에 접속하여 Diskgroup의 파일을 읽을 수 있어야 하므로 SYSASM 권한을 가진 계정을 사용한다.

등록한 별칭으로 접속이 되는지 확인한다.

Redo Log와 Archive Log가 ASM Diskgroup에 저장되어 있는지 확인한다. 경로가 +로 시작하면 ASM 로그 추출 설정이 필요하다.

ASM_PWD=#encrypted는 암호화된 문자열 자체가 아니라, 실제 비밀번호를 wallet 파일에서 읽으라는 표시(sentinel)이다. 따라서 config 파일만 다른 노드로 복사해서는 프로세스를 기동할 수 없으며 wallet 파일(var/<instance>/.wallet_asm)을 함께 이관해야 한다.

설치 config 파일에 ASM 접속 정보를 설정하면 설치 과정에서 ASM 구성이 반영된다.

ASM 접속 정보를 설정하고 설치하면 다음이 수행된다.

• ASM_PWD 암호화 및 wallet 파일 저장

• 생성되는 Extract config에 ASM 파라미터 자동 기입

설치 후 생성된 Extract config에 다음 값이 기입되어 있는지 확인한다.

Extract 프로세스는 활성 Online Redo Log의 경로가 ASM Diskgroup 경로인 경우 ASM 인스턴스 접속을 통해 해당 파일을 읽는다. 읽기는 I/O Worker 세션이 병렬로 수행하고, 로그 리더는 읽어온 블록의 Redo를 분석하여 LCR을 생성한다.

Archive Log는 다음 순서로 위치를 결정한다.

1. ARCHIVE_LOG_DIR이 설정된 경우 해당 디렉터리에서 Archive Log 파일을 먼저 찾는다.

2. 해당 디렉터리에서 찾지 못하거나 ARCHIVE_LOG_DIR이 설정되지 않은 경우 V$ARCHIVED_LOG 조회 결과의 ASM 경로(+DISKGROUP/...)로 접근한다.

ARCHIVE_LOG_DIR은 절대 경로의 디렉터리만 유효한 값이다. 따라서 log_archive_dest가 FRA(USE_DB_RECOVERY_FILE_DEST)이거나 ASM Diskgroup(+...)인 표준 ASM 구성에서는 설치 과정에서 ARCHIVE_LOG_DIR에 값이 기입되지 않으며, Archive Log 위치는 위의 순서에 따라 운영 중에 결정된다.

ASM_PWD는 암호화되어 인스턴스의 wallet 파일(var/<instance>/.wallet_asm)에 저장된다. wallet 파일은 백업 대상에 포함해야 하며, ASM 접속 계정의 비밀번호를 변경한 경우 wallet을 다시 생성해야 한다.

• ASM 로그 추출은 Source Oracle 전용이다.

• ASM_IO_WORKERS는 Extract 프로세스 기동 시에만 적용된다. 운영 중 변경하려면 프로세스를 재기동해야 한다.

• ASM_IO_WORKERS는 최대 8까지 설정할 수 있다.

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

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

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

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

테이블, 컬럼 매핑 기능을 사용하기 위해서는 $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 사용자의 TMP_TBL 테이블을 제외하고 동기화 할 때 다음과 같이 '[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는 Tibero Standby Cluster(이하 TSC) 환경에서 Standby DB를 Source로 하는 동기화를 지원한다.

TSC 환경에서 Extract 프로세스와 Llob 프로세스는 Redo Log 읽기와 Flashback 조회를 Standby DB에서 수행하고, Source DB에 쓰기가 필요한 메타데이터 작업은 쓰기 가능한 Primary DB로 라우팅한다. Failover로 Standby DB가 Primary로 승격되면 쓰기 라우팅을 승격된 DB로 자동 전환한다.

Standby DB에서 추출을 수행하므로 운영 중인 Primary DB의 부하를 줄일 수 있고, Source DB의 장애 전환 이후에도 재설치 없이 동기화를 이어갈 수 있다.

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

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

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

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

사용법

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

다음은 설정 가능한 [DDL OPERATION]과 [DDL OBJECT]의 조합이다. Source DB가 Tibero인 경우와 Oracle인 경우 동일하게 지원한다.

• O : 지원

• △ : 특정 조건에서만 지원 (비고 참조)

• X : 미지원

위 조합 외에 COMMENT ON과 TRUNCATE TABLE을 지원한다.

다음 DDL은 동기화를 지원하지 않으며, 추출 단계에서 skip 처리된다.

• GRANT, REVOKE

• RENAME (ALTER ... RENAME 구문은 ALTER로 동기화 설정하여 사용할 수 있다.)

• ALTER DATABASE LINK,

다음은 모든 스키마에 대해서 모든 종류의 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 동기화 하려면 동기화 대상에 추가해야 한다. Admin 명령으로 수동 등록하거나 AUTO_SYNC_ON_CREATE=Y로 자동 등록할 수 있다. 반면 DDL은 Rule에 의해 생성된 직후부터 동기화 될 수 있으므로 주의한다.

! / 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 Utility에서 ALTER <inst_id> ADD TABLE 수행 (해당 테이블에 supplemental 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' instance를 실행하는 예제이다.

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

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

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

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

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

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

프로세스의 메모리 할당 현황을 파일로 출력하는 진단 명령어이다. 메모리 사용량 분석이나 장애 진단 시 기술 지원의 요청에 따라 사용한다.

결과 파일은 $PRS_HOME/var/<instance>/alloc/ 경로에 생성된다.

Apply 프로세스의 내부 상태를 파일로 출력하는 진단 명령어이다. Apply 프로세스 전용이다.

결과 파일은 $PRS_HOME/var/<instance>/dump/ 경로에 생성된다.

프로세스 내부 상태의 스냅샷 dump를 생성하거나, 생성된 dump 파일을 분석하는 진단 명령어이다.

결과 파일은 $PRS_HOME/var/<instance>/jcdump/ 경로에 생성된다.

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

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

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