Openflow Connector for SQL Server 소개

Openflow Connector for SQL Server 소개

이 페이지에서는 SQL Server용 Openflow Connector의 기본 개념, 사용 사례, 제한 사항, 작업 흐름과 동작 방식을 설명해요. 데이터 보존 정책과 중간 상태를 보존하지 않는 Change Tracking 방식의 특성을 이해하는 데 도움이 됩니다.

출처: Snowflake 문서

본문

Note

이 커넥터는 Snowflake Connector Terms에 의해 규율됩니다.

이 토픽은 SQL Server용 Openflow Connector의 기본 개념, 작업 흐름, 그리고 제한 사항을 설명합니다.

Openflow Connector for SQL Server 소개

SQL Server용 Openflow Connector는 SQL Server 데이터베이스 인스턴스를 Snowflake에 연결하고 선택한 테이블의 데이터를 근-실시간 또는 일정에 따라 복제합니다. 커넥터는 SQL Server Change Tracking을 사용해 복제되는 테이블의 변경을 감지·적용합니다. 변경 데이터는 복제되는 테이블의 현재 상태와 함께 저널(journal) 테이블에 기록됩니다.

Snowflake는 또한 Change Data Capture를 사용하는 SQL Server (CDC)용 Openflow Connector를 제공합니다. 두 커넥터 사이의 선택은 SQL Server용 Openflow Connector 비교를 참고하세요.

사용 사례

다음과 같은 목적이 있다면 이 커넥터를 사용하세요:

• 포괄적·중앙 집중식 보고를 위해 SQL Server 데이터를 Snowflake와 동기화.

지원되는 SQL Server 버전

다음 SQL Server 데이터베이스 버전과 플랫폼이 지원됩니다:

• Microsoft SQL Server 2022

• Microsoft SQL Server 2019

• Microsoft SQL Server 2017

• Microsoft SQL Server 2016

• Azure SQL Database

• Azure SQL Managed Instance

• AWS RDS for SQL Server

• Google Cloud SQL for SQL Server

Note

커넥터는 SQL Server 2008부터 사용할 수 있는 SQL Server Change Tracking에 의존합니다. 이전 버전은 이 기능을 지원하지 않아 커넥터와 호환되지 않습니다.

Openflow 요구 사항

• 지속 복제 워크로드에 맞춰 런타임 크기를 선택하세요. 크기 조정 지침과 한 런타임에서 여러 커넥터를 실행하는 방법은 Runtime sizing을 참고하세요.

• 커넥터는 다중 노드 Openflow 런타임을 지원하지 않습니다. 이 커넥터의 런타임은 Min nodes와 Max nodes를 1로 설정해 구성하세요.

제한 사항

• 커넥터는 SQL Server 인증으로 사용자 이름·비밀번호만 지원합니다.

• 커넥터는 기본 키가 있는 데이터베이스 테이블만 복제합니다.

• 소스 데이터베이스 중 하나에 기본값이 있는 새 NOT NULL 열이 추가되면 커넥터는 Snowflake 데이터베이스의 기존 레코드를 업데이트하지 않습니다.

• Column Filter JSON의 포함 목록에 새 열이 추가되면 커넥터는 Snowflake 데이터베이스의 기존 레코드를 업데이트하지 않습니다.

• 커넥터는 복제 중 열 추가·제거·이름 변경 같은 일반적인 소스 테이블 스키마 변경을 지원합니다. 전체 목록과 몇 가지 지원되지 않는 변경 유형은 Schema changes를 참고하세요.

• 커넥터는 트런케이트 테이블 연산을 지원하지 않습니다. 소스의 TRUNCATE 문은 무시되며 그에 해당하는 행 삭제는 대상 테이블에 적용되지 않습니다.

Note

특정 테이블 열에 영향을 주는 제한 사항은 그 열들을 복제에서 제외해 우회할 수 있습니다.

작업 흐름

다음 작업 흐름은 SQL Server용 Openflow Connector를 설정·실행하는 단계를 요약합니다:

1. SQL Server 데이터베이스 관리자가 다음 작업을 수행합니다:

2. SQL Server 복제 설정을 구성하고 복제되는 데이터베이스·테이블에서 변경 추적을 활성화합니다.

3. 커넥터용 자격 증명을 만듭니다.

4. (선택) SSL로 SQL Server 인스턴스에 연결하기 위한 SSL 인증서를 제공합니다.

5. Snowflake 계정 관리자가 다음 작업을 수행합니다:

6. 커넥터용 서비스 사용자, 복제된 데이터를 저장할 대상 데이터베이스, 커넥터용 웨어하우스를 만듭니다.

7. 커넥터를 설치합니다.

8. 커넥터 흐름 정의에 필요한 파라미터를 지정합니다.

9. 흐름을 실행합니다.

Openflow에서 실행될 때 커넥터는 다음을 수행합니다:

1. 복제하도록 구성된 소스 테이블과 일치하는 스키마와 대상 테이블을 만듭니다.

2. 테이블 복제 수명 주기에 따라 복제를 시작합니다.

자세한 내용은 테이블이 복제되는 방식을 참고하세요.

커넥터 동작 방식

다음 섹션은 복제, 파티션 테이블 스냅샷, 스키마 변경, 데이터 보존 등 다양한 시나리오에서 커넥터가 어떻게 동작하는지 설명합니다.

변경 추적 동작

커넥터는 SQL Server Change Tracking(CT)을 사용해 소스 테이블의 변경을 감지합니다. Change Tracking은 폴링 간격 사이 변경의 순효과(net effect)를 보고합니다. 두 연속 폴링 사이에 행이 여러 번 업데이트되면 커넥터는 그 행의 가장 최근 버전만 봅니다. 중간 상태는 보존되지 않습니다.

이것은 대상 테이블을 소스와 동기화하는 것이 목표인 데이터 동기화 사용 사례에 커넥터를 적합하게 만듭니다. 행의 모든 중간 변경을 캡처해야 하는 감사(audit)·히스토리 사용 사례에는 적합하지 않습니다.

데이터 복제

커넥터는 단일 SQL Server 인스턴스의 여러 SQL Server 데이터베이스에서 테이블 복제를 지원합니다. 커넥터는 서로 다른 데이터베이스의 복제 테이블을 대상 Snowflake 데이터베이스의 별도 스키마에 만듭니다.

복제 테이블은 소스 데이터베이스 이름, 소스 스키마 이름, 테이블 이름을 다음 형식으로 조합해 참조합니다:

<database_name>.<schema_name>.<table_name>

대상 스키마의 이름은 Destination Schema Pattern 파라미터로 결정됩니다. 자세한 내용은 SQLServer Destination Parameters를 참고하세요. 기본적으로 대상 스키마 이름은 소스 데이터베이스 이름과 소스 스키마 이름을 밑줄로 연결한 것이므로 대상 테이블의 정규화된 이름은:

<destination_database>.<source_database_name>_<source_schema_name>.<source_table_name>

테이블이 복제되는 방식

커넥터는 다음 단계로 테이블을 복제합니다:

1. 스키마 내부 검사(schema introspection): 커넥터가 열 이름과 타입을 포함한 소스 테이블의 열을 발견한 뒤 Snowflake와 커넥터의 제한 사항에 대해 검증합니다. 검증 실패는 이 단계를 실패시키고 주기가 완료됩니다. 이 단계가 성공적으로 완료된 뒤 커넥터는 빈 대상 테이블을 만듭니다.

2. 스냅샷 로드: 커넥터가 소스 테이블의 모든 사용 가능한 데이터를 대상 테이블로 복사합니다. 이 단계가 실패하면 커넥터는 데이터 복제를 중지합니다. 성공적으로 완료되면 소스 테이블의 데이터가 대상 테이블에 있습니다. 큰 파티션 테이블을 처리하는 방법은 파티션 테이블 스냅샷을 참고하세요.

3. 증분 로드: 커넥터가 소스 테이블의 변경을 추적하고 그 변경을 대상 테이블에 적용합니다. 이 과정은 테이블이 복제에서 제거될 때까지 계속됩니다. 이 단계에서의 실패는 문제가 해결될 때까지 소스 테이블의 복제를 영구히 중지합니다.

스냅샷 로드를 건너뛰고 증분 로드 과정을 사용하는 방법은 Incremental replication을 참고하세요.

파티션 테이블 스냅샷

스냅샷 로드 중 커넥터는 기본 키 순서로 각 소스 테이블을 페이지네이션합니다. 소스에서 물리적으로 파티션된 큰 테이블에서는, 요구된 순서로 행을 제공하는 인덱스가 없으면 이 순서가 매 배치마다 SQL Server가 전체 테이블을 정렬하게 하여 스냅샷이 매우 느려지거나 완료를 방해할 수 있습니다.

이를 피하기 위해 커넥터는 물리적으로 파티션된 테이블을 한 번에 한 파티션씩 스냅샷합니다. 단일 파티션을 읽으면 SQL Server가 정렬 없이 인덱스 순서로 행을 스트리밍할 수 있어 각 배치가 빠르게 끝납니다. 이 동작은 자동입니다: 커넥터가 파티션 테이블을 감지하며 구성 변경이 필요 없습니다. 파티션되지 않은 테이블은 영향이 없고 전체로 계속 읽힙니다.

스키마 변경

증분 복제 중 커넥터는 소스 테이블 스키마 변경을 감지해 대상 테이블을 자동으로 업데이트할 수 있습니다. 지원되지 않는 변경이면 영향받는 테이블의 복제를 다시 시작해 복구하거나 변경을 적용하세요.

지원되는 변경

커넥터는 다음 스키마 변경을 지원합니다:

• 열 추가. 커넥터가 대상 테이블에 열을 추가하고 새 행·업데이트된 행의 값을 복제합니다. 기존 행은 백필되지 않습니다. 변경 전에 존재하던 행에는 새 열이 NULL입니다.

• 열 제거. 커넥터가 대상 열을 __SNOWFLAKE_DELETED 접미사로 이름을 바꿔 히스토리 값이 보존되게 합니다. 자세한 내용은 제거된 열을 참고하세요.

• 열 이름 변경. 커넥터는 이름 변경을 원래 열 제거 + 새 열 추가로 취급합니다. 커넥터는 원래 열을 접미사가 붙은 이름으로 유지합니다. 예를 들어 A라는 열은 A__SNOWFLAKE_DELETED가 됩니다. 쿼리 패턴은 이름이 바뀐 열을 참고하세요.

• 호환 가능한 타입 변경. 열을 같은 Snowflake 데이터 타입으로 매핑되는 소스 타입으로 변경하면(예: INT를 BIGINT로, 둘 다 NUMBER로 매핑) 커넥터는 대상 열 타입을 그대로 두고 복제를 계속합니다.

• 이전에 제거한 열 다시 추가. 커넥터는 기존 소프트 삭제 열 옆에 새 대상 열로 열을 추가합니다(예: A와 A__SNOWFLAKE_DELETED).

이전에 제거되고 소프트 삭제된 열을 다시 제거하면 소프트 삭제된 열 이름이 이미 사용 중이라 영향받는 테이블의 복제가 실패합니다.

지원되지 않는 변경

커넥터는 다음 스키마 변경을 지원하지 않습니다. 별도로 명시하지 않는 한, 다시 시작할 때까지 영향받는 테이블의 복제가 중지됩니다:

• 기본 키 정의 변경. 기본 키 열을 추가·제거하거나 기본 키를 구성하는 열을 바꿉니다. 커넥터는 이 변경을 감지하지 못하고 이전 키로 계속 복제합니다. 복제는 스스로 멈추지 않습니다. 커넥터가 새 키를 사용하도록 영향받는 테이블의 복제를 다시 시작하세요.

• 호환되지 않는 타입 변경. 새 소스 타입이 다른 Snowflake 데이터 타입으로 매핑될 때(예: INT를 VARCHAR로, 각각 NUMBER와 TEXT로 매핑).

• 숫자 정밀도 또는 배율 변경. 예: NUMERIC(7,2)를 NUMERIC(6,3)으로 변경.

• 문자 열 길이 변경. 예: VARCHAR(50)을 VARCHAR(100)으로 변경.

복구하려면 영향받는 테이블의 복제를 다시 시작하세요: 테이블 복제 다시 시작 참고.

테이블의 Column Filter JSON을 변경할 때도 같은 소프트 삭제 메커니즘이 적용됩니다. 자세한 내용은 테이블에서 열 하위 집합 복제를 참고하세요.

큰 값(Oversized values)

기본적으로 커넥터는 최대 16 MB까지 개별 값을 복제합니다. 더 큰 값을 만나면 관련 테이블을 영구 실패로 표시하고 복제를 중지합니다. 큰 값을 처리하는 방식을 바꾸려면(예: NULL로 대체) Oversized Value Strategy 대상 파라미터를 수정하세요.

Snowflake 계정에 ENABLE_OPENFLOW_CDC_SQLSERVER_SSV2 파라미터가 true로 설정되어 있으면 값별 한도를 16 MB에서 128 MB로 올릴 수 있습니다.

128 MB 값별 한도 활성화에 대한 자세한 내용은 큰 값 한도 증가를 참고하세요.

Always On 가용성 그룹과 소스 장애 조치(failover)

커넥터는 SQL Server Always On Availability Groups를 지원합니다. 커넥터는 복제를 다시 시작하거나 커넥터 구성에서 테이블을 제거할 필요 없이 계획·비계획 장애 조치를 견딥니다.

장애 조치 중 SQL Server가 기본 역할을 다른 복제본으로 옮기는 동안 소스 데이터베이스는 잠깐 오프라인일 수 있습니다. 소스 데이터베이스를 일시적으로 사용할 수 없으면 복제 테이블은 Table State Store에 현재 상태를 유지합니다. 커넥터는 다음 폴링 주기에 재시도하고, 데이터베이스가 다시 온라인이 되면 마지막으로 기록된 위치에서 증분 복제를 재개합니다. 일시적 연결 오류와 소스 일시적 미사용은 테이블을 FAILED로 옮기지 않습니다.

Note

이 동작은 지원되지 않는 스키마 변경이나 테이블의 변경 캡처를 영구히 중지하는 다른 소스 측 조건 같은 영구 실패와는 다릅니다. 그런 조건은 여전히 영향받는 테이블을 FAILED로 옮기며, 근본 문제를 해결하고 테이블 복제를 다시 시작할 때까지 계속됩니다.

연결 설정은 Always On Availability Groups를 참고하세요.

잘못된 행(invalid rows)에 대한 오류 처리

잘못된 행은 대상 테이블에 쓸 수 없어 Snowflake가 수집 중 거부하는 행입니다(예: 대상 열 타입으로 변환할 수 없는 값, 누락된 필수 열). Error Handling Strategy 파라미터는 커넥터가 잘못된 행을 만났을 때 무엇을 하는지 제어합니다:

• Fail Table (기본): 첫 잘못된 행에서 커넥터가 테이블을 영구 실패로 표시하고 복제를 중지해, 엄격한 all-or-nothing 복제를 유지합니다. 소스 데이터를 고친 뒤 테이블 복제 다시 시작에 설명된 대로 복제를 재개하세요.

• Log Errors and Continue: 커넥터가 유효한 행의 복제를 계속하고, 각 거부된 행을 원래 페이로드와 오류 세부 정보와 함께 테이블의 오류 테이블에 기록합니다. 테이블은 실패로 표시되지 않습니다.

전략을 바꾸려면 Error Handling Strategy 파라미터를 설정하세요. 자세한 내용은 SQLServer Destination Parameters를 참고하세요.

거부된 행이 캡처되는 방식

커넥터는 Snowpipe Streaming으로 데이터를 로드하므로 오류 로깅은 Snowpipe Streaming의 오류 로깅에 설명된 대로 정확히 동작합니다. Log Errors and Continue를 선택하면 커넥터는 ERROR_LOGGING 속성이 TRUE로 설정된 새 대상·저널 테이블을 만들어, 거부된 행이 로드를 중단하는 대신 전용 오류 테이블에 캡처됩니다. 오류 테이블은 변환 전 Snowflake로 보낸 원래 페이로드를 오류 세부 정보와 함께 저장합니다.

테이블의 오류 테이블은 ERROR_TABLE 테이블 함수로 조회합니다:

SELECT * FROM ERROR_TABLE(<destination_database>.<schema>.<table>) ORDER BY timestamp;

거부된 행이 어디에 놓이는지는 복제 단계에 따라 다릅니다:

• 스냅샷 로드: 거부된 행이 대상 테이블의 오류 테이블에 기록됩니다.

• 증분(변경 추적) 로드: 변경이 먼저 저널 테이블에 기록되므로 거부된 행이 저널 테이블의 오류 테이블에 기록됩니다. 저널 테이블에 대한 자세한 내용은 를 참고하세요.

커넥터는 Log Errors and Continue를 선택한 뒤 생성하는 테이블에만 오류 로깅을 활성화합니다. 이미 복제 중이던 테이블의 거부된 행을 캡처하려면 기존 스키마에서 오류 로깅 활성화의 저장 프로시저로 기존 대상·저널 테이블에서 오류 로깅을 활성화하세요.

Note

커넥터가 잘못된 행을 만나면 거부된 행 수를 포함하는 WARN 로그 항목을 배출합니다. 이 항목들로 거부된 행 활동을 모니터링하세요.

거부된 행 소비

거부된 행을 프로그래밍 방식으로 처리하려면 오류 테이블에 스트림을 만들어 다른 Snowflake 스트림처럼 소비하세요. 자세한 내용은 오류 테이블의 스트림을 참고하세요.

소스 데이터베이스 잠금 동작

스냅샷·증분 복제 중 커넥터는 행 데이터를 가져오고 변경을 추적하기 위해 소스 데이터베이스 테이블에서 읽습니다.

SQL Server의 기본 READ COMMITTED 격리 수준에서는 이 읽기 연산이 소스 테이블에 공유 잠금을 획득합니다. 다른 데이터베이스 클라이언트가 같은 테이블에 충돌하는 잠금을 동시에 보유하면, SQL Server가 충돌하는 세션 중 하나를 종료하는 교착 상태(deadlock)가 발생할 수 있습니다.

다른 애플리케이션이 사용하는 격리 수준에 영향을 주지 않고 이런 교착 상태를 피하려면, 커넥터가 SNAPSHOT 격리 하에서 읽도록 구성하세요. SNAPSHOT 격리는 공유 잠금을 획득하는 대신 행 버전에서 읽으므로 커넥터의 쿼리가 소스 테이블의 동시 쓰기와 더 이상 경합하지 않습니다.

이 방식은 SNAPSHOT 격리를 커넥터 자체 세션에서만 사용 가능하게 하므로, 다른 애플리케이션이 의존하는 기본 READ COMMITTED 격리 수준을 바꾸지 않습니다. 이런 목적으로는 Read Committed Snapshot Isolation(RCSI) 사용을 피하세요. RCSI는 데이터베이스에 대한 모든 연결의 기본 격리 수준을 재정의하기 때문입니다.

커넥터의 SNAPSHOT 격리 활성화 단계는 SNAPSHOT 격리 하에서 소스 읽기를 참고하세요.

커넥터는 고객 데이터가 자동으로 삭제되지 않는 데이터 보존 철학을 따릅니다. 복제된 데이터에 대한 완전한 소유권과 제어권을 유지하며, 커넥터는 영구 제거보다 히스토리 정보를 보존합니다.

이 방식은 다음을 의미합니다:

• 소스 테이블에서 삭제된 행은 대상 테이블에서 물리적으로 제거되지 않고 소프트 삭제됩니다.

• 소스 테이블에서 제거된 열은 대상 테이블에서 드롭되지 않고 이름이 바뀝니다.

• 저널 테이블은 무기한 유지되며 자동으로 정리되지 않습니다.

대상 테이블 메타데이터 열

각 대상 테이블은 복제 정보를 추적하는 다음 메타데이터 열을 포함합니다:

Column name	Type	Description
_SNOWFLAKE_INSERTED_AT	TIMESTAMP_NTZ	The timestamp when the row was originally inserted into the destination table.
_SNOWFLAKE_UPDATED_AT	TIMESTAMP_NTZ	The timestamp when the row was last updated in the destination table.
_SNOWFLAKE_DELETED	BOOLEAN	Indicates whether the row was deleted from the source table. When true, the row has been soft-deleted and no longer exists in the source.

소프트 삭제된 행

소스 테이블에서 행이 삭제되면 커넥터는 대상 테이블에서 물리적으로 제거하지 않습니다. 대신 _SNOWFLAKE_DELETED 메타데이터 열을 true로 설정해 행이 삭제되었음을 표시합니다.

이 방식으로 다음을 할 수 있습니다:

• 감사·규정 준수를 위해 히스토리 데이터 보존.

• 필요할 때 삭제된 레코드 조회.

• 요구 사항에 따라 데이터를 언제·어떻게 영구 제거할지 결정.

활성(비삭제) 행만 조회하려면 _SNOWFLAKE_DELETED 열로 필터링하세요:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

삭제된 행을 조회하려면:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

제거된 열

소스 테이블에서 열이 제거되면 커넥터는 대상 테이블에서 해당 열을 드롭하지 않습니다. 대신 히스토리 값 보존을 위해 __SNOWFLAKE_DELETED 접미사를 붙여 열 이름을 바꿉니다.

예를 들어 소스 테이블에서 EMAIL이라는 열이 제거되면 대상 테이블에서 EMAIL__SNOWFLAKE_DELETED로 이름이 바뀝니다. 열 제거 전에 존재하던 행은 원래 값을 유지하고, 제거 후 추가된 행은 이 열에 NULL이 있습니다.

이름이 바뀐 열에서 여전히 히스토리 값을 조회할 수 있습니다:

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

이름이 바뀐 열

CDC(Change Data Capture) 메커니즘의 제한 때문에 커넥터는 열 이름 변경과 '열 제거 후 새 열 추가'를 구분할 수 없습니다. 결과적으로 소스 테이블에서 열 이름을 바꾸면 커넥터는 이를 두 개의 별도 연산으로 취급합니다: 원래 열 제거와 새 이름의 새 열 추가.

예를 들어 소스 테이블에서 열을 A에서 B로 이름을 바꾸면 대상 테이블에는 다음이 포함됩니다:

• A__SNOWFLAKE_DELETED: 이름 변경 전의 값. 이름 변경 후 추가된 행은 이 열에 NULL.

• B: 이름 변경 후의 값. 이름 변경 전에 존재하던 행은 이 열에 NULL.

이름이 바뀐 열 조회

원래 열과 이름이 바뀐 열 둘 다에서 단일 통합 열로 데이터를 가져오려면 COALESCE 또는 CASE 표현식을 사용하세요:

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

CASE 표현식을 사용해도 됩니다:

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

이름이 바뀐 열용 뷰 생성

대상 테이블을 수동으로 수정하는 대신, 이름이 바뀐 열을 단일 통합 열로 제시하는 뷰를 만들 수 있습니다. 이 방식은 원래 데이터를 보존하고 진행 중인 복제로 인한 잠재적 문제를 피하므로 권장됩니다.

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

Important

대상 테이블 구조를 수동으로 수정하는 것(열 드롭·이름 변경 등)은 진행 중인 복제를 방해하고 데이터 불일치를 유발할 수 있으므로 권장되지 않습니다.

저널 테이블

증분 복제 중 소스 데이터베이스의 변경은 대상 테이블에 병합되기 전에 먼저 저널 테이블에 기록됩니다. 커넥터는 이 데이터가 감사·디버깅·재처리 목적으로 유용할 수 있으므로 저널 테이블에서 자동으로 제거하지 않습니다.

저널 테이블은 해당 대상 테이블과 같은 스키마에 생성되며 다음 명명 규칙을 따릅니다:

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

여기서:

• <TABLE_NAME>은 대상 테이블 이름입니다.

• <timestamp>는 Unix epoch 형식(1970년 1월 1일 이후 초)의 생성 타임스탬프로, 고유성을 보장합니다.

• <number>는 대상 테이블 스키마가 변경될 때마다(소스 테이블의 스키마 변경 또는 열 필터 수정에 의해) 1부터 증가합니다.

예를 들어 대상 테이블이 SALES.ORDERS라면 저널 테이블은 SALES.ORDERS_JOURNAL_1705320000_1 같은 이름일 수 있습니다.

Important

복제가 진행 중인 동안 저널 테이블을 드롭하지 마세요. 활성 저널 테이블을 제거하면 데이터 손실이나 복제 실패가 발생할 수 있습니다. 해당 소스 테이블이 복제에서 완전히 제거된 뒤에만 저널 테이블을 드롭하세요.

저널 테이블 스토리지 관리

오래된 저널 데이터를 제거해 스토리지 비용을 관리해야 한다면, 더 이상 복제되지 않는 테이블의 저널 테이블을 주기적으로 정리하는 Snowflake 태스크를 만들 수 있습니다.

저널 정리를 구현하기 전에 다음을 확인하세요:

• 해당 소스 테이블이 복제에서 완전히 제거되었는지.

• 감사·처리 목적으로 저널 데이터가 더 이상 필요 없는지.

자동 정리 태스크 생성·관리에 대한 정보는 태스크 소개를 참고하세요.

다음 단계

커넥터가 데이터 타입을 Snowflake 데이터 타입으로 매핑하는 방식을 이해하려면 SQL Server용 Openflow 커넥터: 데이터 매핑을 검토하세요.

커넥터를 설정하려면 SQL Server용 Openflow Connector 설정을 검토하세요.

더 알아보기 (Learn more)

• SQL Server용 Openflow Connector 설정
• Openflow Connector for SQL Server (CDC) 소개