Status-Driven Transfer¶

개요¶

Status-Driven Transfer는 mode=TRIGGER로 실행합니다. Repository SQL 결과를 주기적으로 조회해 준비된 Source table만 전송합니다.

웹 콘솔에서도 작업 모드를 TRIGGER로 선택하여 설정·검증·실행할 수 있습니다. 관리자가 프로젝트에 Oracle 또는 PostgreSQL Repository 연결을 지정하고, 작업 사용자는 전체 대상·준비 대상 조회문과 조회 주기를 입력합니다.

일반 작업에서는 schemas|tables 중 하나만 사용합니다. mapping_rule은 범위를 직접 정의하므로 schemas, tables, query와 함께 사용할 수 없습니다.

1. Repository 연결¶

repository=REPO_USER/password@host:1521/REPODB
repository=postgresql://repo_user:password@host:5432/repository

Repository는 Oracle 접속 문자열 또는 postgres://, postgresql:// URI를 지원합니다. 이는 상태 조회 Repository에 대한 지원이며 Datatrans의 source와 target은 Oracle 접속 문자열입니다.

2. 읽기 전용 query¶

completed_target_query¶

감시할 전체 Source table 목록을 조회합니다.

SELECT OWNER, TABLE_NAME
FROM MIG_TARGETS

이름과 달리 완료 결과를 기록하는 DML이 아니며 Repository를 변경하지 않습니다.

working_target_query¶

현재 전송 가능한 Source table 목록을 조회합니다.

SELECT OWNER, TABLE_NAME
FROM MIG_READY

두 query는 신뢰된 SQL로 그대로 실행됩니다. Repository 변경용 DML을 넣지 말고 관리자가 검토한 조회만 사용하십시오.

3. 반환 형식¶

두 query는 다음 중 하나를 반환해야 합니다.

OWNER | TABLE_NAME
SALES | ORDERS

OWNER.TABLE
SALES.ORDERS

일반 schemas|tables 작업에서 실제 감시 대상은 CLI 선택 범위와 completed_target_query 결과에 모두 포함된 Source table입니다. working_target_query가 그중 준비됐다고 반환한 table만 처리합니다.

4. Polling¶

polling_frequency=3

• 양의 정수 초 단위입니다.
• 기본값은 3초입니다.
• 준비되지 않은 table은 임의로 skip하거나 timeout 처리하지 않고 계속 확인합니다.

pooling_frequency는 오타를 보존한 deprecated alias입니다.

pooling_frequency=3

두 이름을 동시에 서로 다른 값으로 지정하면 오류입니다. 새 작업에는 polling_frequency를 사용하십시오.

준비 상태에 따른 처리 흐름¶

graph TD
    A[TRIGGER 시작] --> B[completed_target_query 조회]
    B --> C[선택 범위와 감시 대상 확인]
    C --> D[polling_frequency 간격으로 준비 상태 조회]
    D --> E{working_target_query에 전송 가능 대상이 있는가?}
    E -->|없음| D
    E -->|있음| F[준비된 대상 데이터 전송]
    F --> G{감시 대상 처리가 끝났는가?}
    G -->|아니요| D
    G -->|예| H[최종 결과 확인]

준비된 Source 테이블을 확인하고 처리하는 개념도입니다. Repository query는 상태를 조회하며 Repository를 변경하는 DML이 아닙니다.

5. TRIGGER와 Flashback¶

TRIGGER는 Repository에서 table이 준비된 시점의 기준 시점을 사용합니다. flashback_scn과 flashback_timestamp는 TRIGGER 처리 시점 지정에 사용되지 않습니다.

따라서 일반 TRANSFER의 CURRENT|INDIVIDUAL|OFF|SCN_NUMBER 또는 timezone timestamp를 TRIGGER ready 시각 제어 수단으로 사용하지 마십시오.

6. 전체 실행 예시¶

다음은 형식 검토용 예제이며 실제 접속 정보로 바꾼 뒤 관리자가 query와 범위를 검토해야 합니다.

datatrans \
  source=SRC_USER/password@host:1521/SRCDB \
  target=TGT_USER/password@host:1521/TGTDB \
  schemas=SALES \
  mode=TRIGGER \
  repository=REPO_USER/password@host:1521/REPODB \
  completed_target_query="SELECT OWNER,TABLE_NAME FROM MIG_TARGETS" \
  working_target_query="SELECT OWNER,TABLE_NAME FROM MIG_READY" \
  polling_frequency=3 \
  degree=8 \
  table_action=APPEND \
  jobname=SALES_TRIGGER

Mapping 범위라면 schemas를 제거하고 mapping_rule만 지정합니다.

datatrans \
  source=SRC_USER/password@host:1521/SRCDB \
  target=TGT_USER/password@host:1521/TGTDB \
  mapping_rule="/secure/mapping/*.yaml" \
  mode=TRIGGER \
  repository=postgresql://repo_user:password@host:5432/repository \
  completed_target_query="SELECT owner,table_name FROM migration_targets" \
  working_target_query="SELECT owner,table_name FROM migration_ready" \
  polling_frequency=3 \
  table_action=APPEND \
  jobname=MAPPING_TRIGGER

Mapping에서도 existing compatible Target과 APPEND|TRUNCATE만 지원합니다.

7. 모니터링¶

상태 조회는 help에 정의된 대화형 명령을 사용합니다.

콘솔의 프로젝트 실행은 실행 현황 또는 실행 모니터에서 확인합니다. 실행 통제 프로젝트는 관리자 승인 후 실행됩니다. CLI 이력의 콘솔 조회 범위는 웹 콘솔 가이드를 따릅니다.

$ datatrans
DATATRANS> STATUS=SALES_TRIGGER
DATATRANS> PROGRESS=SALES_TRIGGER
DATATRANS> CONTINUE_JOB=SALES_TRIGGER
DATATRANS:SALES_TRIGGER> STATUS_WATCH,3

8. 운영 체크리스트¶

• mode=TRIGGER와 모든 필수 parameter를 지정했습니다.
• Repository query는 읽기 전용이고 반환 형식이 정확합니다.
• 선택 범위와 completed_target_query 결과의 교집합을 확인했습니다.
• polling_frequency는 양의 정수이며 deprecated alias와 충돌하지 않습니다.
• 준비되지 않은 table을 계속 기다리는 운영 수명주기를 고려했습니다.
• TRIGGER 기준 시점이 Repository ready 시점임을 확인했습니다.