Apply
성능
Apply 프로세스는 Extract 프로세스가 전달한 변경 데이터를 TX별로 정리 후 commit 요청된 시점부터 Target DB에 반영하며 주로 DB에 쿼리를 수행한 후 결과를 기다리는 과정에서 지연이 발생한다.
지연을 방지하기 위해, Target DB에 반영 쿼리를 수행하는 APPLY_NUM 파라미터를 조절하여 Thread 수를 늘려 성능을 개선할 수 있다.
장애
반영 실패
Source DB에서 추출한 변경 데이터에 대해 Target DB에 반영할 수 없는 경우, 프로싱크는 실패한 DML을 성공할 때 까지 다시 시도한다.
사용자는 해당 데이터가 반영될 수 있도록 Target DB를 수정하거나 DCR 기능 또는 DISCARD 기능을 사용하여 우회할 수 있다.
메모리 과점유
ProSync는 TX에 대해 commit 또는 rollback 이전까지 반영을 시작하지 않기 때문에 commit 없이 변경 데이터를 계속해서 전달받는 경우, Apply 프로세스에서 사용하는 메모리가 증가할 수 있다.
이때, 메모리 조절용 파라미터를 설정하여 사용하는 메모리를 조절할 수 있다.
MEMORY_CTRL_STOP_SIZE/MEMORY_CTRL_RESUME_SIZE
Replay Thread 에서 완료되지 않은 TX들의 총 메모리 크기가 MEMORY_CTRL_STOP_SIZE 파라미터의 값을 넘는 경우 extract 프로세스에서 보내는 chunk를 수신하지 않는다.
이후, Replay Thread 에서 동기화를 수행하여 완료되지 않은 TX들의 총 메모리 크기가MEMORY_CTRL_RESUME_SIZE 값보다 낮아지는 경우 다시 Extract 프로세스에서 보내는 chunk를 수신한다.
MERGE_BLOCK_CNT/MERGE_RESUME_CNT
TAC/RAC 환경에서 특정 extract 프로세스의 chunk만 계속해서 수신 받는 경우, stmt수가 MERGE_BLOCK_CNT 파라미터의 값을 넘는 경우 해당 extract 프로세스에서 보내는 chunk를 수신하지 않는다.
이후, 다른 extract 프로세스들에게 chunk를 수신 받아 처리되지 못한 stmt수가 MERGE_RESUME_CNT 값보다 낮아지는 경우 다시 extract 프로세스에서 보내는 chunk를 수신한다.
CHUNK_TOTAL_SIZE
extract 프로세스에서 수신한 chunk에 대해, const Thread 에서 처리하지 못한 TX들의 총 메모리 크기가 CHUNK_TOTAL_SIZE 파라미터의 값을 넘는 경우 extract 프로세스에서 보내는 chunk를 수신하지 않는다.
이후, const Thread 가 처리하지 못한 메모리 크기가 파라미터 값의 절반 이하로 낮아지는 경우 다시 extract 프로세스에서 보내는 chunk를 수신한다.
TX_HASH_SIZE
apply 프로세스의 Const Thread 메모리에서 관리하는 tx정보들의 크기를 관리하는 파라미터로 commit이 오지 않은 stmt들 정보가 TX_HASH_SIZE를 넘어가는 경우 가장 큰 TX부터 part파일 생성 후 메모리에서 제거하며 해당 값보다 사용하는 메모리가 낮아질 때 까지 반복한다.
디스크 사용
TX_HASH_FILE_CNT/TX_HASH_FILE_TOTAL_SIZE
Log Switch 감지 시, const Thread 에서 아직 commit되지 않은 tx정보를 재기동 상황에서도 유지하기 위해 txh 파일을 생성한다. 이때, txh 파일의 최대 개수 또는 파일들의 합의 최대 크기를 설정할 수 있다.
TX_HASH_FILE_MODE 파라미터를 통해 제한 방식을 설정할 수 있으며, 각 Extract별로 txh의 크기나 개수를 계산한다.
partfile
TX_HASH_SIZE 이상으로 const Thread 에서 TX 정보들이 쌓이게 되는 경우, 메모리 관리를 위해 part파일을 작성하고 메모리에서 제거하게 되며 관련된 TX가 commit 또는 rollback되기 전까지 partfile은 제거되지 않는다. 따라서, 한 TX가 끝나지 않는 경우 디스크 사용량이 계속해서 증가할 수 있다.
주의사항
Character Set 설정 주의사항
Source DB의 Character Set과 OS 환경 변수(LANG) 불일치 시 주의사항
Source DB에 데이터를 삽입할 때는 해당 DB의 Character Set과 일치하는 Terminal 및 OS의 LANG 환경변수 설정이 반드시 필요하다.
LANG 설정이 Source DB의 Character Set과 일치하지 않으면, ProSync가 데이터를 추출할 때 잘못된 인코딩으로 인식하게 되어, Target DB로 전송 시 문자 깨짐 또는 손상된 데이터가 저장될 수 있다.
따라서, Source DB에 데이터를 입력하는 시스템의 LANG 환경 변수는 Source DB의 Character Set과 정확히 일치시켜야 하며, 시스템 관리자 또는 사용자 환경에서도 일관된 문자셋 설정이 유지되어야 한다.
Trigger가 설정된 테이블 동기화 시 주의 사항
Trigger가 설정된 테이블을 동기화할 경우, Trigger로 인해 예상치 못한 데이터 중복이 발생할 수 있다. 예를 들어, 다음과 같은 Trigger가 Source DB와 Target DB에 존재한다고 가정한다.
위와 같은 환경에서 TEST.T1 테이블을 동기화할 경우, 다음과 같은 흐름이 발생할 수 있다.
Source DB에서 TEST.T1 테이블에 INSERT 수행 -> Trigger 작동 -> TEST.T2에도 데이터 삽입
동기화 과정에서 Target DB에 TEST.T1 INSERT 반영 -> Target DB의 Trigger 작동 -> TEST.T2에도 동일한 데이터 삽입
또한, Source DB에서 추출된 TEST.T2의 INSERT 문이 Target DB에 반영되면서 중복 삽입 발생
이로 인해 Target DB의 TEST.T2 테이블에는 중복된 데이터가 저장될 수 있다.
따라서 프로싱크 동기화 로직 상 정합성이 틀어질 수 있기 때문에 Target DB에는 Trigger가 존재해서는 안 된다.
주의
제약 조건이 설정된 테이블 동기화 시 주의 사항
Trigger뿐만 아니라 ON DELETE, ON UPDATE와 같은 제약 조건(Constraint) 또한 동일한 이유로 Target DB에 설정되어서는 안 된다.
이러한 제약 조건이 존재할 경우, 동기화 시 데이터의 삽입·삭제·갱신 작업이 중복 반영되어 데이터 정합성이 깨질 수 있다.
Last updated