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가 끝나지 않는 경우 디스크 사용량이 계속해서 증가할 수 있다.
Last updated