Openflow Connector for SQL Server: 유지 관리

Openflow Connector for SQL Server: 유지 관리 (Maintenance)

이 페이지에서는 Openflow Connector for SQL Server의 유지 관리 고려 사항과 모범 사례를 설명해요. 커넥터 재설치, 변경 추적 시작 위치 설정, 대용량 값 한도 증가 등의 작업을 다룹니다. 이러한 작업은 스냅샷 없는 증분 복제(Incremental replication without snapshots)와 함께 사용하는 경우가 많아요.

출처: 문서

본문

기능 — 일반 공급 (Generally Available)

Snowflake 커넥터는 Snowflake Openflow를 사용할 수 있는 모든 리전에서 지원돼요.

Openflow Snowflake 배포는 AWS, Azure, GCP Commercial 리전의 모든 계정에서 사용할 수 있어요.
BYOC 배포의 Snowflake Openflow는 AWS Commercial 리전의 모든 계정에서만 사용할 수 있어요.

참고

이 커넥터는 Snowflake Connector 약관이 적용돼요.

이 항목에서는 Openflow Connector for SQL Server의 유지 관리 고려 사항과 모범 사례(예: 커넥터 재설치, 변경 추적 시작 위치 설정)를 설명해요. 이러한 작업은 스냅샷 없는 증분 복제와 함께 사용되는 경우가 많아요.

테이블의 복제 상태 확인 (Check the replication status of a table)

일시적인 실패(예: 연결 오류, 고가용성 장애 조치 중 소스가 일시적으로 사용 불가한 경우)는 테이블 복제를 막지 않아요. 복제된 테이블은 현재 상태를 유지하고 커넥터는 다음 폴링 주기에 다시 시도해요. 그러나 지원되지 않는 데이터 타입 같은 영구 실패는 테이블 복제를 막아요.

복제 문제를 해결하거나 테이블이 복제 플로우에서 성공적으로 제거되었는지 확인하려면 Table State Store를 확인해요.

Openflow 런타임 캔버스에서 프로세서 그룹을 마우스 오른쪽 버튼으로 클릭하고 Controller Services를 선택해요. 컨트롤러 서비스 목록이 표시돼요.
Table State Store 레이블이 붙은 행을 찾아 행 오른쪽의 More 버튼을 클릭한 다음 View State를 선택해요.

테이블 목록과 현재 상태가 표시돼요. 검색 상자에 입력해 테이블 이름으로 목록을 필터링할 수 있어요. 가능한 상태는 다음과 같아요.

NEW: 테이블이 복제 예정이지만 복제가 아직 시작되지 않았어요.
SNAPSHOT_REPLICATION: 커넥터가 기존 데이터를 복사하고 있어요. 모든 레코드가 대상 테이블에 저장될 때까지 이 상태가 표시돼요.
INCREMENTAL_REPLICATION: 커넥터가 변경 사항을 활발히 복제하고 있어요. 이 상태는 스냅샷 복제가 끝난 뒤 표시되며, 테이블이 복제에서 제거되거나 복제가 실패할 때까지 계속 표시돼요.
FAILED: 오류로 인해 복제가 영구적으로 중지되었어요.

참고

Openflow 런타임 캔버스는 테이블 상태 변경을 표시하지 않고 현재 테이블 상태만 표시해요. 그러나 테이블 상태 변경은 발생할 때 로그에 기록돼요. 다음 로그 메시지를 찾아봐요.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

영구 실패로 테이블 복제가 막히면 테이블을 복제에서 제거해요. 실패를 일으킨 문제를 해결한 뒤 테이블을 복제에 다시 추가할 수 있어요. 자세한 내용은 테이블 복제 다시 시작을 참고해요.

테이블 복제 다시 시작 (Restart table replication)

참고

이 절차는 테이블을 제자리에서(in place) 다시 스냅샷해요. 커넥터 버전 0.53.0 이상과 runtime-extensions 2026.9.3.12 이상이 필요해요. 이전 버전에서는 Snowflake에 이미 존재하는 테이블을 다시 스냅샷하면 제자리에서 다시 로드하는 대신 실패해요. 이 절차를 사용하기 전에 커넥터를 업그레이드해요.

FAILED 상태의 테이블(예: 기본 키 누락 또는 지원되지 않는 스키마 변경으로 인해)은 자동으로 다시 시작되지 않아요. 테이블이 FAILED 상태가 되거나 처음부터 복제를 다시 시작해야 한다면, 다음 절차를 사용해 테이블을 복제에서 제거했다가 다시 추가해요.

참고

실패 원인이 소스 테이블의 기본 키 누락 같은 문제였다면, 계속하기 전에 소스 데이터베이스에서 그 문제를 해결해요.

다음 방법 중 하나로 테이블을 복제에서 제거해요.
- 테이블을 Re-snapshot Table Exclusions 매개변수에 추가해 복제에서 일시적으로 제외해요. 이 방식은 테이블이 변경하고 싶지 않은 Included Table Regex와 일치할 때 편리해요.
- Ingestion Parameters 컨텍스트에서 테이블을 Included Table Names에서 제거하거나 Included Table Regex를 수정해 테이블이 더 이상 일치하지 않게 해요.
테이블이 제거되었는지 확인해요.
- Openflow 런타임 캔버스에서 프로세서 그룹을 마우스 오른쪽 버튼으로 클릭하고 Controller Services를 선택해요.
- 테이블 목록 컨트롤러 서비스에서 Table State Store 행을 찾아 행 오른쪽의 세로 점 세 개를 클릭하고 View State를 선택해요.
중요

계속하기 전에 테이블 상태가 이 목록에서 완전히 제거될 때까지 기다려야 해요. 이 구성 변경이 완료될 때까지 계속하지 마세요.
테이블을 다시 추가하기 전에 모든 큐가 비워질 때까지 기다려요. 모든 FlowFile이 처리되면 커넥터 프로세서 그룹의 Queued 값이 0이 돼요.

경고

테이블을 제거하기 전에 캡처된 변경 이벤트가 여전히 큐에 있는 동안 테이블을 다시 추가하지 마세요. 테이블을 다시 추가하면 커넥터는 append-only 모드로 새 스냅샷을 로드하므로, 재스냅샷 후 테이블에 병합되는 잔여 변경 이벤트가 대상 테이블에 중복 행을 만들 수 있어요.
첫 번째 단계에서 했던 변경을 되돌려 테이블을 다시 추가해요. 즉 Re-snapshot Table Exclusions에서 테이블을 제거하거나, Included Table Names 또는 Included Table Regex에 다시 추가해요. 먼저 대상 테이블을 drop할 필요는 없어요. 커넥터는 제자리에서 테이블을 다시 스냅샷해요. 현재 대상 테이블을 <destination_table>_ARCHIVE_<timestamp>라는 아카이브 테이블로 zero-copy clone하고, 대상 테이블을 비운 다음, 같은 대상 테이블에 새 스냅샷을 로드해요. 대상 테이블 객체가 보존되므로 스트림(stream) 같은 종속 객체는 연결된 채로 계속 작동해요. 아카이브 테이블은 다시 로드 직전 대상 테이블 콘텐츠의 사본을 안전 장치로 보관해요. 커넥터는 그 테이블을 다시 읽거나 쓰지 않으므로, 백업이 더 이상 필요 없을 때(일반적으로 재스냅샷이 완료되고 대상 데이터가 올바른지 확인한 뒤) 언제든지 drop할 수 있어요.
다시 시작을 확인해요. 앞서 설명한 지침을 사용해 Table State Store를 확인해요. 테이블 상태가 NEW로 나타난 뒤 SNAPSHOT_REPLICATION으로, 마지막으로 INCREMENTAL_REPLICATION으로 전환되어야 해요.

대용량 값 한도 증가 (Increase the oversized value limit)

기본적으로 커넥터는 개별 값을 최대 16 MB까지 복제하고, 그보다 큰 값을 포함하는 테이블은 영구 실패로 표시해요. Snowflake 계정에 ENABLE_OPENFLOW_CDC_SQLSERVER_SSV2 매개변수가 true로 설정되어 있으면 값별 한도를 16 MB에서 128 MB로 높일 수 있어요.

중요

128 MB 한도는 두 가지 방식으로 적용돼요. 즉 단일 값의 최대 크기이면서 동시에 행의 최대 총 크기예요. 커넥터는 모든 복제 행에 메타데이터 열(_SNOWFLAKE_UPDATED_AT, _SNOWFLAKE_INSERTED_AT, _SNOWFLAKE_DELETED)을 추가하는데, 이 열들은 행의 다른 모든 열과 함께 행별 한도에 계산돼요. 그 결과 행에 다른 데이터가 포함되면 실제로 단일 값이 전체 128 MB에 도달할 수 없어요.

증가된 한도는 모든 열 타입에 동일하게 적용되지는 않아요.

참고

Snowflake에서 BINARY의 최대 크기는 64 MB(BINARY(67108864))예요. 증가된 크기 한도가 활성화된 경우에도 마찬가지예요. 128 MB까지 보유할 수 있는 것은 VARCHAR, VARIANT, ARRAY, OBJECT 열뿐이에요.

128 MB 한도 사용 가능 여부 확인

ENABLE_OPENFLOW_CDC_SQLSERVER_SSV2 매개변수 값을 쿼리해 확인하지 못할 수 있어요. 활성화되었는지 확인하려면 FlowFile이 Upload Rows via Snowpipe Streaming 2 프로세서를 통해 흐르는지(Upload Rows via Snowpipe Streaming을 통해서가 아니라) 확인해요.

프로세서 구성

다음 프로세서에서 Oversized Value Limit 속성을 128 MB로 업데이트해요.

Fetch Table Rows (Snapshot Load 그룹) — 파티션되지 않은 테이블용
MultiDatabaseFetchTableSnapshot (Snapshot Load 그룹) — 파티션된 테이블용
Read SQLServer Change Tracking tables (Incremental Load 그룹)

각 프로세서에 대해:

플로우에서 프로세서를 찾아요. 커넥터 캔버스의 오른쪽 위 검색 상자를 사용해 이름으로 프로세서를 찾을 수 있어요.
프로세서를 마우스 오른쪽 버튼으로 클릭하고 Configure를 선택해요.
Properties 탭을 열어요.
Oversized Value Limit을 128 MB로 설정해요.
변경 사항을 적용해요.

이미 복제 중이고 대상 열이 VARCHAR(134217728) 또는 BINARY(67108864)보다 좁은 테이블은 기존 테이블 마이그레이션을 참고해요.

기존 테이블 마이그레이션

"대용량 값 한도 증가"의 단계는 새로 생성되는 대상 테이블에 대한 한도를 높여요. 이미 복제 중이고 대상 열 타입이 VARCHAR(134217728) 또는 BINARY(67108864)가 아닌 테이블에서 원래 16 MB 한도보다 큰 값을 이제 로드하고 싶다면, 저널(journal) 테이블과 대상 테이블 모두에서 열 타입을 수동으로 넓혀야 해요.

마이그레이션 전에 현재 대상 열 타입을 확인해요. 스냅샷 복제가 수행된 시기에 따라 달라질 수 있기 때문이에요.

경고

저널 테이블이나 대상 테이블을 변경하기 전에 해당 테이블에 대한 복제를 중지해야 해요. 복제가 활성화된 상태에서 이 테이블들을 변경하면 처리 중인 데이터가 손상될 수 있어요.

테이블을 마이그레이션하려면:

모든 큐가 비워질 때까지 Snapshot Load와 Incremental Load 그룹의 최상위 프로세서를 중지해 해당 테이블에 대한 복제를 중지해요. 동등한 중지 절차는 커넥터 재설치의 하위 단계를 참고해요.
열 타입에 따라 저널 테이블과 대상 테이블 모두에서 열을 넓혀요.
- VARCHAR 열인 경우: 저널 테이블과 대상 테이블에서 ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE VARCHAR(134217728)을 실행해요(테이블당 하나의 문장).
- BINARY 열인 경우: Snowflake는 BINARY를 제자리에서 넓히는 것을 허용하지 않으므로 저널과 대상 테이블 둘 다에서 다음을 수행해요.
  - BINARY(67108864) 타입의 새 열을 추가해요.
  - 원래 열에서 새 열로 데이터를 복사해요.
  - 원래 열을 drop하고 새 열을 원래 이름으로 바꿔요.
프로세서를 다시 활성화해 복제를 다시 시작해요.

성능 고려 사항

값별 한도를 높이면 커넥터가 메모리에 로드하고 플로우를 통해 이동하는 데이터 양이 늘어나 런타임과 워크하우스 양쪽의 부하가 커져요. 런타임과 워크하우스를 그에 맞게 크기를 조정해요.

Oversized Value Strategy가 Set Null로 설정되어 있으면 커넥터는 값을 NULL로 대체하기 전에 각 대용량 값을 여전히 메모리에 로드해요. 테이블에 수 기가바이트 규모의 LOB 열이 있다면 해당 열을 복제에서 제외해요.

스냅샷과 증분 복제 둘 다에서 Upload Rows via Snowpipe Streaming 2 프로세서 앞의 큐가 FlowFile로 가득 차 역압(back pressure)이 발생할 수 있고, 이는 런타임 디스크 공간을 많이 소모해요. 더 큰 테이블에는 추가 스토리지를 제공하는 Large 런타임을 사용해요. 크기 선택에 대한 안내는 런타임 크기 조정을 참고해요.

스냅샷 복제

스냅샷 복제 속도를 높이려면 Upload Rows via Snowpipe Streaming 2 프로세서가 사용하는 채널 수를 늘릴 수 있어요. 채널 수는 프로세서의 Channel Group 속성으로 설정되며, 기본값은 ${chunk.index:isEmpty():ifElse('1', ${chunk.index:mod(8)})}예요.

채널 수를 늘리려면:

플로우에서 Upload Rows via Snowpipe Streaming 2 프로세서를 찾아요.
프로세서를 중지해요. 속성을 변경하려면 먼저 프로세서를 중지해야 해요.
프로세서를 마우스 오른쪽 버튼으로 클릭하고 Configure를 선택해요.
Properties 탭을 열어요.
Channel Group 속성에서 표현식의 값 8을 늘려요. 예를 들어 8을 16으로 바꾸면 채널 수가 두 배가 돼요.
변경 사항을 적용해요.
프로세서를 시작해요.

경고

스냅샷 복제가 진행 중인 동안에는 채널 수를 늘리기만 해요. 활성 스냅샷 중에 채널 수를 줄이면 데이터 손실이 발생할 수 있어요.

증분 복제

소스가 큰 값을 포함하는 행에 빈번한 변경을 만들 때는 Large 워크하우스가 필요할 수 있어요. 중간 크기의 행이 많고(예: 8 MB 값이 많음) 빈번하게 병합되면 큰 단일 병합 연산이 필요할 수 있고, 더 작은 워크하우스는 메모리가 부족할 수 있어요. 반대로 매우 큰 행이 적은 경우(예: 128 MB 값)는 Upload Rows via Snowpipe Streaming 2 프로세서를 통해 파일 단위로 스트리밍되고, 각 파일은 증분으로 병합되므로 더 작은 워크하우스에서도 워크하우스 오류 없이 일반적으로 완료돼요.

기존 스키마에서 오류 로깅 활성화 (Enable error logging on an existing schema)

Error Handling Strategy 매개변수를 Log Errors and Continue로 설정하면 커넥터는 그 뒤에 만드는 테이블에만 오류 로깅을 자동으로 활성화해요. 커넥터가 더 일찍 만든 테이블은 거부된 행에 대한 오류 로깅을 켤 때까지 캡처하지 않아요. 오류 처리 전략에 대한 자세한 내용은 잘못된 행에 대한 오류 처리를 참고해요.

커넥터는 저널 테이블을 대상 테이블과 같은 스키마에 저장하므로 전체 대상 스키마에 대해 한 번에 오류 로깅을 켤 수 있어요. 대상 스키마당 한 번씩 다음 저장 프로시저를 실행해요. my_database를 대상 데이터베이스로, my_schema를 대상 스키마로 바꿔요.

참고

스키마 이름은 인용된 식별자로 전달되므로(예: '"my_schema"') 커넥터가 만든 정확한, 대소문자 구분 이름과 일치해요. 커넥터가 대상 스키마의 이름을 지정하는 방법에 대한 자세한 내용은 SQLServer Destination Parameters를 참고해요.

USE DATABASE my_database;

WITH enable_error_logging AS PROCEDURE (schema_name STRING)
RETURNS STRING
LANGUAGE SQL
AS
$$
DECLARE
  tables RESULTSET;
  table_count NUMBER DEFAULT 0;
BEGIN
  SHOW TABLES IN SCHEMA IDENTIFIER(:schema_name);

  -- Assign AFTER SHOW TABLES so LAST_QUERY_ID() refers to that result
  tables := (
    SELECT "database_name", "schema_name", "name"
    FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
    WHERE "kind" = 'TABLE'
  );

  FOR t IN tables DO
    -- Double-quote each identifier so names with special characters are handled safely
    EXECUTE IMMEDIATE
      'ALTER TABLE "' || REPLACE(t."database_name", '"', '""') || '".' ||
      '"'             || REPLACE(t."schema_name",   '"', '""') || '".' ||
      '"'             || REPLACE(t."name",          '"', '""') || '" ' ||
      'SET ERROR_LOGGING = TRUE';

    table_count := table_count + 1;
  END FOR;

  RETURN 'Enabled ERROR_LOGGING on ' || table_count || ' table(s) in schema ' || :schema_name;
END;
$$
CALL enable_error_logging('"my_schema"');

오류 로깅이 활성화되었는지 확인

스키마의 모든 테이블에서 오류 로깅이 활성화되었는지 확인하려면 다음 프로시저를 실행해요. 오류 로깅이 활성화된 테이블 수와 그렇지 않은 테이블 수를 보고해요.

USE DATABASE my_database;

WITH verify_error_logging AS PROCEDURE (schema_name STRING)
RETURNS STRING
LANGUAGE SQL
AS
$$
DECLARE
  tables RESULTSET;
  probe RESULTSET;
  total_tables          NUMBER DEFAULT 0;
  logging_enabled       NUMBER DEFAULT 0;
  disabled_or_invisible NUMBER DEFAULT 0;
BEGIN
  SHOW TABLES IN SCHEMA IDENTIFIER(:schema_name);

  -- Assign AFTER SHOW TABLES so LAST_QUERY_ID() refers to that result
  tables := (
    SELECT "database_name", "schema_name", "name"
    FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()))
    WHERE "kind" = 'TABLE'
  );

  FOR t IN tables DO
    total_tables := total_tables + 1;

    -- Probe ERROR_TABLE(): it succeeds only when error logging is enabled and visible
    BEGIN
      probe := (
        EXECUTE IMMEDIATE
          'SELECT 1 FROM ERROR_TABLE(' ||
          '"' || REPLACE(t."database_name", '"', '""') || '".' ||
          '"' || REPLACE(t."schema_name",   '"', '""') || '".' ||
          '"' || REPLACE(t."name",          '"', '""') || '"' ||
          ') LIMIT 1'
      );
      logging_enabled := logging_enabled + 1;
    EXCEPTION
      WHEN STATEMENT_ERROR THEN
        disabled_or_invisible := disabled_or_invisible + 1;
    END;
  END FOR;

  RETURN 'schema='                                  || :schema_name ||
         ', total_tables='                          || total_tables ||
         ', error_logging_enabled='                 || logging_enabled ||
         ', error_logging_disabled_or_not_visible=' || disabled_or_invisible;
END;
$$
CALL verify_error_logging('"my_schema"');

커넥터 재설치 (Reinstall the connector)

이 섹션에서는 커넥터를 다시 설치하고, 같은 테이블을 다시 스냅샷하지 않고도 데이터를 계속 복제하는 방법을 설명해요. 새 커넥터가 같은 런타임에 설치되는 경우와 새 런타임으로 이동되는 경우를 모두 다룹니다.

사전 요구 사항

커넥터 매개변수 컨텍스트 값을 검토하고 기록해요. 같은 런타임에 커넥터를 다시 설치하면 기존 컨텍스트를 재사용할 수 있어요. 새 인스턴스가 다른 런타임에 있다면 모든 매개변수를 다시 입력해야 해요.

기존 커넥터에서 처리 중인(in-flight) 모든 FlowFile 처리를 마친 뒤 커넥터를 중지해요.
- Snowsight에 로그인해요.
- 내비게이션 메뉴에서 Ingestion » Openflow를 선택해요.
- Launch Openflow를 선택해요.
- Openflow 창에서 Runtimes 탭을 선택해요.
- 커넥터가 포함된 런타임을 선택해요.
- 커넥터를 선택해요.
- Snapshot Load 그룹의 최상위 프로세서 Set Tables for Replication을 중지해요.
- Incremental Load 그룹의 최상위 프로세서 Read SQLServer Change Tracking tables를 중지해요.
- Merge Task Schedule CRON 매개변수 값을 변경했다면 * * * * * ?로 되돌려요. 그렇지 않으면 다음 예약 실행까지 큐가 비워지지 않아요.
- 커넥터의 모든 FlowFile이 처리되고 모든 큐가 비워질 때까지 기다려요. 모든 FlowFile이 처리되면 커넥터 프로세서 그룹의 Queued 값이 0이 돼요. 원래 커넥터의 큐에 항목이 남아 있으면 새 커넥터가 시작될 때 데이터 공백이 생길 수 있어요.
- 커넥터의 모든 프로세서와 컨트롤러 서비스를 중지해요.
주의

기존 커넥터는 중지된 상태로 유지되는 한 런타임에 남아 있어도 새 인스턴스를 방해하지 않아요.
커넥터를 새 런타임으로 이동하는 경우, 기존 커넥터에서 플로우 정의를 다운로드해 처음부터 구성하는 대신 현재 상태로 커넥터를 다시 만들 수 있게 해요. 플로우 정의 다운로드에는 Openflow Runtime Server 버전 2026.6.4.18 이상이 필요해요.
- 커넥터의 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Download flow definition을 선택해요.
- 다음 두 옵션을 모두 선택한 뒤 플로우 정의를 다운로드해요.
  - Export with External Services: 커넥터가 상위 프로세스 그룹에서 참조하는 컨트롤러 서비스를 포함해요.
  - Export with Components State: 변경 추적 위치와 증분 복제 상태 같은 컴포넌트 상태를 포함해 복제가 중단된 지점부터 계속되도록 해요.
대상 런타임에 커넥터를 만들어요.
- 플로우 정의를 다운로드했다면 새 런타임으로 가져와요. 플로우 정의를 가져오면 내보내기 중 캡처된 컴포넌트 상태가 보존되므로 커넥터가 이전 위치부터 증분 복제를 재개해요.
- 그렇지 않으면 커넥터의 새 인스턴스를 만들어요. 원래 커넥터와 같은 런타임을 사용한다면 기존 매개변수 컨텍스트를 유지하고 설정을 재사용할 수 있어요.
다른 런타임에 설치하거나 이전 매개변수 컨텍스트를 삭제했다면, SQL Server용 Openflow Connector 설정에 설명된 대로 테이블 이름과 패턴을 포함한 구성 설정을 새 매개변수 컨텍스트에 입력해요. 다운로드한 플로우 정의는 민감한 값(예: 암호)이나 업로드된 파일(예: Microsoft JDBC 드라이버)을 포함하지 않으므로 다시 입력하고 다시 업로드해야 해요.
SQLServer Ingestion Parameters 컨텍스트로 이동해 다음 매개변수를 설정해요.
- Ingestion Type 매개변수를 incremental로 설정해요. 자세한 내용은 스냅샷 없는 증분 복제 활성화를 참고해요.
- Starting Change Tracking Position 매개변수를 Earliest로 설정해요. 자세한 내용은 변경 추적 테이블 위치에서 로드 지정을 참고해요.
참고

Export with Components State를 선택해 플로우 정의를 가져왔다면 커넥터는 이전 변경 추적 위치를 유지해요. 이 경우 Starting Change Tracking Position을 Latest로 두어 중단된 위치부터 복제를 계속해요.
새 커넥터를 시작해요.

사용 메모

새 커넥터는 원래 커넥터가 만든 기존 대상 테이블을 사용하지만 새 저널 테이블을 만들어요.

변경 추적 테이블 위치에서 로드 지정 (Specify load from change tracking table position)

Openflow Connector for SQL Server 커넥터를 사용하면 변경 추적 테이블을 읽을 시작 위치를 선택할 수 있어요. 기본적으로 커넥터는 사용 가능한 최신 위치부터 읽어요. 또는 소스 인스턴스에서 사용 가능한 가장 이른 위치를 선택할 수 있어요. 가장 이른 위치부터 시작하도록 선택하는 것은 커넥터를 재설치할 때 흔한 방식이에요. 이렇게 하면 새 인스턴스가 따라잡아 기존 테이블을 각각 다시 스냅샷하지 않고도 복제를 계속할 수 있어요.

실행 중인 커넥터를 최신 위치에서 가장 이른 위치로 전환하면 변경 추적 테이블의 내용이 다시 읽히고, 다시 처리되어 대상 테이블에 다시 적용돼요.

경고

변경 추적 테이블이 다시 읽히는 동안 모든 이벤트가 다시 처리되고 병합될 때까지 영향받는 대상 테이블의 데이터가 소스와 동기화되지 않을 수 있어요.

Ingestion Parameters 컨텍스트에서 다음 매개변수를 사용할 수 있어요.

매개변수	설명
Starting Change Tracking Position	`Latest`(기본값): 변경 추적 테이블 읽기가 사용 가능한 최신 위치에서 시작해 거기서부터 계속돼요. `Earliest`: 증분 로드가 사용 가능한 가장 이른 변경 추적 테이블 위치부터 시작하거나 다시 읽도록 전환해요.
Re-read Tables in State	`New`(기본값): 시작 위치가 `Earliest`로 전환된 뒤 추가된 새 테이블만 가장 이른 위치부터 변경 추적 테이블을 읽어요. 구성 변경 전에 복제를 시작한 테이블은 마지막 위치부터 계속 읽어요. `Any active`: 현재 복제 중인 모든 테이블의 변경 사항을 다시 읽고 다시 처리해요.

Latest(기본값): 변경 추적 테이블 읽기가 사용 가능한 최신 위치에서 시작해 거기서부터 계속돼요.
Earliest: 증분 로드가 사용 가능한 가장 이른 변경 추적 테이블 위치부터 시작하거나 다시 읽도록 전환해요.
New(기본값): 시작 위치가 Earliest로 전환된 뒤 추가된 새 테이블만 가장 이른 위치부터 변경 추적 테이블을 읽어요. 구성 변경 전에 복제를 시작한 테이블은 마지막 위치부터 계속 읽어요.
Any active: 현재 복제 중인 모든 테이블의 변경 사항을 다시 읽고 다시 처리해요.

커넥터가 변경 추적 테이블 재읽기를 완료했는지 확인하려면:

Openflow 캔버스로 이동해요.
Incremental Load 프로세스 그룹을 열어요.
Read SQLServer Change Tracking tables라는 이름의 최상위 프로세서를 마우스 오른쪽 버튼으로 클릭하고 View state를 선택해요.
position.로 시작하는 키가 있는 모든 테이블의 상태 항목을 확인해요. 값이 0/0이라면 커넥터가 아직 이 테이블의 변경 사항 재읽기를 완료하지 못한 것이에요.
실행 중인 커넥터를 가장 이른 위치에서 읽도록 전환하고 시작한 뒤에는 프로세스를 재구성하거나 취소할 수 없으며, 현재 읽고 있는 위치가 최신 값에 도달할 때까지 계속돼요.
실행 중인 커넥터에서 가장 이른 위치로 전환하면, 다시 처리되는 모든 테이블에 대해 기존 저널을 마치고 새 저널 테이블을 만들어요.

Openflow Connector for SQL Server: 유지 관리