Status-Driven Transfer¶

개요¶

Status-Driven Transfer는 Repository DB에 저장된 테이블 상태 정보를 기준으로 전송 대상을 자동으로 선택하고 처리하는 방식입니다.

이 모드에서는 source와 target 외에 상태 정보를 조회하기 위한 repository 연결이 추가로 필요합니다.

1. repository¶

1.1 설명¶

repository는 테이블 상태(예: READY, COMPLETED 등)를 관리하는 Repository DB 접속 정보입니다.

상태 기반 전송에서는 이 Repository DB를 조회하여 감시 대상과 전송 가능 대상을 판단합니다.

1.2 입력 형식¶

문자열(str) 또는 dict 형식을 지원합니다.
dict 형식에서 dbtype을 생략하면 키 구성(dsn, service_name, sid 등)을 기준으로 Oracle 또는 Postgres를 추정합니다.
지원 DB 타입은 다음과 같습니다.
- postgresql
- oracle

1.3 예시¶

repository=HOST:PORT/SERVICE

참고

위 예시는 문서 설명용 형식입니다. 실제 입력 형식은 Datatrans에서 사용하는 DB 연결 방식에 맞춰 작성해야 합니다.

2. completed_target_query¶

2.1 설명¶

completed_target_query는 Repository에서 감시 대상 테이블 목록을 조회하는 쿼리입니다.

이 쿼리는 초기 분석 단계에서 실행되며, 실제로 모니터링할 후보 테이블 범위를 확정하는 데 사용됩니다.

2.2 반환 형식¶

쿼리 결과는 아래 두 형식 중 하나여야 합니다.

2컬럼 형식1컬럼 형식

(OWNER, TABLE_NAME)

'OWNER.TABLE'

점(.)이 반드시 포함되어야 합니다.

또한 OWNER와 TABLE_NAME 값은 내부적으로 대문자로 정규화됩니다.

2.3 동작 규칙¶

사용자가 지정한 schemas 또는 tables 범위와 completed_target_query 결과의 교집합만 실제 전송 후보가 됩니다.
Repository에 존재하더라도 schemas 또는 tables 범위 밖의 대상은 무시됩니다.
교집합이 하나도 없으면 전송 대상이 없는 것으로 판단하고 종료합니다.

2.4 쿼리 예시¶

SELECT OWNER, TABLE_NAME
FROM DT_REPO_TABLE_STATUS
WHERE MONITOR_YN='Y';

3. working_target_query¶

3.1 설명¶

working_target_query는 Repository에서 지금 전송을 시작할 수 있는 테이블을 조회하는 쿼리입니다.

일반적으로 READY 상태와 같이 즉시 처리 가능한 대상을 찾기 위해 사용합니다.

Datatrans는 이 쿼리를 주기적으로 폴링하고, 준비된 테이블이 확인되면 큐에 등록한 뒤 워커가 비는 즉시 전송을 시작합니다.

3.2 반환 형식¶

반환 형식은 completed_target_query와 동일합니다.

2컬럼 형식1컬럼 형식

(OWNER, TABLE_NAME)

'OWNER.TABLE'

3.3 쿼리 예시¶

SELECT OWNER, TABLE_NAME
FROM DT_REPO_TABLE_STATUS
WHERE STATUS='READY';

4. polling_frequency¶

4.1 설명¶

polling_frequency는 Repository를 조회하는 폴링 주기(초)를 의미합니다.

기본값은 3초입니다.
내부 루프에서는 next_poll_time = now + polling_frequency 방식으로 다음 조회 시각을 계산합니다.

4.2 권장 설정¶

설정값	영향
너무 짧음 (예: `0.1`초)	Repository DB 부하 증가
너무 길음 (예: `60`초)	상태 변경 후 실제 전송 시작까지 지연
권장 범위 (`3~10`초)	시스템 부하와 응답성 균형

5. 운영 팁¶

핵심 포인트

completed_target_query는 감시 범위를 결정하는 용도입니다.
working_target_query는 실제 실행 가능 대상을 계속 찾는 용도입니다.
두 쿼리의 결과 형식은 반드시 일관되게 유지하는 것이 좋습니다.
schemas 또는 tables를 함께 사용하는 경우, 최종 대상은 항상 교집합 기준으로 결정됩니다.
polling_frequency는 응답성과 Repository 부하 사이의 균형을 고려해 설정해야 합니다.

6. 전체 흐름 다이어그램¶

graph TD
    A[Datatrans 시작] --> B[completed_target_query 실행]
    B --> C{schemas/tables와 교집합?}
    C -->|없음| D[종료]
    C -->|있음| E[감시 대상 확정]
    E --> F[polling_frequency 간격으로 폴링]
    F --> G[working_target_query 실행]
    G --> H{READY 테이블 있음?}
    H -->|없음| F
    H -->|있음| I[큐에 등록]
    I --> J[Worker 할당 후 전송]
    J --> K[상태 업데이트]
    K --> F

7. 실행 예시¶

datatrans \
  source=APP_SOURCE/password@192.168.0.10:1521/SOURCEPDB \
  target=APP_TARGET/password@192.168.0.20:1521/TARGETPDB \
  repository=REPO_USER/password@192.168.0.30:1521/REPODB \
  schemas=SALES,HR \
  completed_target_query="SELECT OWNER, TABLE_NAME FROM DT_REPO_TABLE_STATUS WHERE MONITOR_YN='Y'" \
  working_target_query="SELECT OWNER, TABLE_NAME FROM DT_REPO_TABLE_STATUS WHERE STATUS='READY'" \
  polling_frequency=5 \
  degree=8 \
  table_action=TRUNCATE \
  jobname=status_driven_job