성능

Extract 프로세스는 Redo Log 파일을 읽어 변경 데이터를 추출하기 때문에, 디스크 읽기 속도가 성능에 영향을 줄 수 있으며 변경 데이터는 Chunk 형태로 Apply 프로세스에 전송하기 때문에, 네트워크 속도가 영향을 줄 수 있다.

ProSync 파라미터에 따라 성능이 변화할 수 있다.

1. 로그 레벨(LOG_LEVEL)이 높다면, disk write가 많아짐에 따라 성능이 저하될 수 있다.

2. 데이터 압축 기능을 사용한다면, 데이터 압축을 위한 동작이 추가됨에 따라 성능이 저하될 수 있다.

3. 데이터 암호화 기능을 사용한다면, 데이터 암호화를 위한 동작이 추가됨에 따라 성능이 저하될 수 있다.

ProSync는 적절한 반영 쿼리 생성을 위해 테이블의 DD image 변경이 발생하는 시점에 Trigger를 통해 내부 패키지를 수행하여 메타 테이블을 업데이트한다.

메타 테이블 업데이트는 필요한 정보가 있는 시스템 테이블을 조회하여 동기화 할 Object들의 정보를 메타 테이블에 insert하는 방식으로 설치 시점에 PRS_USER에 적절한 권한이 부여되지만, 사용 중인 PRS_USER에게서 필요한 권한을 회수한다면 해당 동작을 수행하지 못해 장애가 발생할 수 있다.

ProSync가 사용하는 PRS_DDL_HIST에서 오류가 발생했는지 확인할 수 있으며 해당 테이블에 오류가 발생한 경우, PRS_USER의 권한 변경이 있는지 확인이 필요하다.

Extract 프로세스는 여러 파일에 대한 읽기 또는 쓰기 권한이 필요하다.

• 변경 데이터 읽기 위해 Redo Log와 Archive Log들에 대한 읽기 권한이 필요하다.

• 로그 작성을 위해 LOG_DIR, LOG_BACKUP_DIR 파라미터 경로에 대한 쓰기 권한이 필요하다.

• 이전 Redo Log에서 commit되지 않은 tx정보를 저장하는 tlr(olr) 파일을 작성하기 위해 $PRS_HOME/var/[instance_name]/lr[node_num] 경로에 대한 읽기/쓰기 권한이 필요하다.

Log Reader가 특정 변경 데이터에 대한 처리를 하지 못한다면, 버그 리포트 후 새로운 바이너리로 교체가 필요하다.

정합성 불일치를 감수하고 동기화를 진행하려면 설치 안내서의 이력조절(링크)을 참고하여 문제되는 Redo Log를 넘기거나 corrupted lcr이 추출된 경우 _LR_SKIP_CORRUPTED_LCR 파라미터를 통해 넘길 수 있다.

ProSync 운영 중 장애 발생 시, 분석을 위해 현상 발생한 프로세스의 5레벨 로그와 config를 첨부해야 하며 장애 유형에 따라 다음 정보를 추가적으로 요청할 수 있다.

다른 프로세스에서 전달한 정보에 오류가 의심되는 경우 요청할 수 있다.

config 파일의 LOG_DIR 경로에 위치한다.

현상 발생한 프로세스와 동일하게 5레벨 로그(LOG_LEVEL=5)를 첨부해야 한다.

Log Reader 오동작이 의심되는 경우 요청할 수 있다. 자세한 분석을 위해, Extract 프로세스의 파라미터를 '''LR_TRACE_LVL=5''' 로 설정한 뒤, 현상 재현을 요청한다.

$PRS_HOME/var/[INST_ID]/lr[NODE_NUM]/ 경로에 생성되는 til[NODE_NUM].log/oli[NODE_NUM].log 파일을 첨부해야 한다.

여러 Redo Log에 Chaining된 TX에 대해, 잘못된 값을 추출한 것으로 의심되는 경우 요청할 수 있다.

Extract 프로세스를 기동한 장비의 $PRS_HOME/var/[INST_ID]/lr[NODE_NUM]/ 경로에 생성된다.

Log Reader에서 잘못된 값을 추출한 것으로 의심되는 경우, 마지막으로 읽은 Redo Log를 요청할 수 있다.

Extract 프로세스에서 마지막으로 출력한 redo log found 또는 redo/archived log found 로그를 통해 마지막으로 읽은 로그를 알 수 있다.

기동 실패, 파라미터 동적 변경 실패, 동기화 테이블 추가 실패 등 Agent 프로세스에서 요청을 보내는 기능이 실패하는 경우, 실패한 지점을 분석하기 위해 5레벨 Agent 로그를 요청할 수 있다.

config 파일의 LOG_DIR 경로에 위치한다.

Apply 프로세스에서 메모리 관리를 위해 파일로 내린 TX 데이터의 손상이 의심되는 경우 요청할 수 있다.

Apply 프로세스를 기동한 장비의 $PRS_HOME/var/[INST_ID]/tx 경로에 생성되며 config파일에 TX_HASH_FILE_DIR 파라미터 설정 시, 해당 경로에 생성된다.

Llob 프로세스는 Apply 프로세스의 요청에 따라 read Thread 에서 해당 시점(TSN 또는 SCN)의 llob 데이터에 대한 select 쿼리를 수행하기 때문에, 해당 시점에 대한 정보가 없는 경우(flashback 쿼리 실패) 현재 시점을 기준으로 조회하며 이때, 현재 시점에 해당 row가 존재하지 않는다면 조회를 실패할 수 있다.

Apply 프로세스에서 최대 20개의 Replay Thread 를 사용하여 동기화를 수행할 수 있고, 모든 Thread 에서 llob 데이터가 존재하는 테이블을 동기화 한다면 Llob 프로세스에서 모든 요청을 처리하는데 지연이 발생할 수 있다.

이때, LLOB_THREAD_CNT파라미터를 사용하여 Apply 프로세스의 요청을 분배해 성능을 개선할 수 있다.

추출한 시점의 TSN(SCN)으로 flashback 쿼리를 수행할 수 없으면서 현재 해당 row가 존재하지 않는다면 llob 데이터 조회가 실패하고 Prosync는 해당 row 동기화를 계속해서 재시도한다.

성능

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를 수신한다.

TAC/RAC 환경에서 특정 extract 프로세스의 chunk만 계속해서 수신 받는 경우, stmt수가 MERGE_BLOCK_CNT 파라미터의 값을 넘는 경우 해당 extract 프로세스에서 보내는 chunk를 수신하지 않는다.

이후, 다른 extract 프로세스들에게 chunk를 수신 받아 처리되지 못한 stmt수가 MERGE_RESUME_CNT 값보다 낮아지는 경우 다시 extract 프로세스에서 보내는 chunk를 수신한다.

extract 프로세스에서 수신한 chunk에 대해, const Thread 에서 처리하지 못한 TX들의 총 메모리 크기가 CHUNK_TOTAL_SIZE 파라미터의 값을 넘는 경우 extract 프로세스에서 보내는 chunk를 수신하지 않는다.

이후, const Thread 가 처리하지 못한 메모리 크기가 파라미터 값의 절반 이하로 낮아지는 경우 다시 extract 프로세스에서 보내는 chunk를 수신한다.

apply 프로세스의 Const Thread 메모리에서 관리하는 tx정보들의 크기를 관리하는 파라미터로 commit이 오지 않은 stmt들 정보가 TX_HASH_SIZE를 넘어가는 경우 가장 큰 TX부터 part파일 생성 후 메모리에서 제거하며 해당 값보다 사용하는 메모리가 낮아질 때 까지 반복한다.

Log Switch 감지 시, const Thread 에서 아직 commit되지 않은 tx정보를 재기동 상황에서도 유지하기 위해 txh 파일을 생성한다. 이때, txh 파일의 최대 개수 또는 파일들의 합의 최대 크기를 설정할 수 있다.

TX_HASH_FILE_MODE 파라미터를 통해 제한 방식을 설정할 수 있으며, 각 Extract별로 txh의 크기나 개수를 계산한다.

TX_HASH_SIZE 이상으로 const Thread 에서 TX 정보들이 쌓이게 되는 경우, 메모리 관리를 위해 part파일을 작성하고 메모리에서 제거하게 되며 관련된 TX가 commit 또는 rollback되기 전까지 partfile은 제거되지 않는다. 따라서, 한 TX가 끝나지 않는 경우 디스크 사용량이 계속해서 증가할 수 있다.

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가 Source DB와 Target DB에 존재한다고 가정한다.

위와 같은 환경에서 TEST.T1 테이블을 동기화할 경우, 다음과 같은 흐름이 발생할 수 있다.

1. Source DB에서 TEST.T1 테이블에 INSERT 수행 -> Trigger 작동 -> TEST.T2에도 데이터 삽입

2. 동기화 과정에서 Target DB에 TEST.T1 INSERT 반영 -> Target DB의 Trigger 작동 -> TEST.T2에도 동일한 데이터 삽입

3. 또한, Source DB에서 추출된 TEST.T2의 INSERT 문이 Target DB에 반영되면서 중복 삽입 발생

이로 인해 Target DB의 TEST.T2 테이블에는 중복된 데이터가 저장될 수 있다.

따라서 프로싱크 동기화 로직 상 정합성이 틀어질 수 있기 때문에 Target DB에는 Trigger가 존재해서는 안 된다.

Oracle To Tibero 동기화의 경우, 이미 데이터가 존재하는 테이블에 ALTER TABLE DDL 수행 시 오라클 내부 동작으로 인해 DPI(Direct Path Insert)가 발생하며 Unique Constraints Violation이 발생할 수 있다.

예를 들어, 아래와 같은 형상의 테이블이 존재하며, 다음과 같은 흐름으로 진행된다고 가정한다.

이 때, ALTER TABLE 구문으로 인해 오라클 내부에서 DPI가 발생하며 데이터를 복사하는 과정이 수행되는데, 해당 DPI 구문이 동기화 테이블과 같은 OBJ_ID를 가지고 있어 함께 동기화가 진행되며 Unique Constraints Violation이 발생한다.

해당 오류 발생 시DISCARD_EC 파라미터에 UNIQUE VIOLATION Error code를 기재하여 우회 할 수 있다.