Oracle용 Openflow 커넥터 소개
Oracle용 Openflow 커넥터 소개
이 문서에서는 Oracle용 Openflow 커넥터의 기본 개념, 워크플로, 제한 사항을 설명합니다. 이 커넥터는 Oracle 데이터베이스 인스턴스를 Snowflake에 연결하고 선택한 테이블의 데이터를 거의 실시간 또는 지정된 일정에 따라 복제합니다.
출처: Snowflake 문서
본문
참고: Oracle용 Openflow 커넥터는 표준 커넥터 서비스 약관 외에 추가 서비스 약관의 적용을 받습니다. 자세한 내용은 'Openflow Connector for Oracle Addendum'을 참조하세요.
Oracle용 Openflow 커넥터 소개
Oracle용 Openflow 커넥터는 Oracle 데이터베이스 인스턴스를 Snowflake에 연결하고 선택한 테이블의 데이터를 거의 실시간 또는 지정된 일정에 따라 복제합니다. 커넥터는 또한 모든 데이터 변경의 로그를 만들며, 이 로그는 복제된 테이블의 현재 상태와 함께 제공됩니다.
사용 사례
커넥터는 다음 사용 사례를 지원합니다.
- 포괄적이고 중앙 집중적인 보고를 위해 Oracle 데이터베이스 테이블을 Snowflake로 복제
라이선스 모델 및 중요한 제약
Oracle용 Openflow 커넥터는 세 가지의 뚜렷한 라이선스 모델을 지원합니다. 설치 전에 올바른 모델을 선택해야 합니다. 올바른 모델을 선택하지 않으면 배포 실패나 의도하지 않은 재정적 부담이 발생할 수 있습니다.
자세한 라이선스 약관, 비교, 구성 지침은 'Oracle XStream licensing'을 참조하세요.
경고: 커넥터는 기술적으로 Oracle Database Standard Edition(SE/SE2)과 호환됩니다. 그러나 Oracle 문서는 "Oracle XStream을 라이선스하고 사용하기 위한 선행 조건은 Oracle Database Enterprise Edition 라이선스"라고 명시합니다. Standard Edition 데이터베이스에 커넥터를 배포하기 전에 Oracle 라이선스 계약을 확인해 XStream 사용이 허용되는지 검증하세요. Oracle 라이선스 약관 준수는 전적으로 귀하의 책임입니다.
1. 임베디드 라이선스(36개월 약정, Snowflake 제공)
참고: Openflow에서 이 라이선스 옵션은 Oracle Embedded License로 표시됩니다.
Snowflake가 Oracle XStream 라이선스를 비용을 받고 직접 제공합니다. 이 모델은 Oracle과 직접 계약하지 않고 XStream 복제를 사용할 수 있게 해 줍니다. 자세한 내용은 'Embedded license details for 36-month commitment'와 'Openflow Connector for Oracle Addendum'을 참조하세요.
| 약관 | 세부 사항 |
|---|---|
| 과금 | 월 라이선스 비용과 지원·유지 보수(S&M) 비용이 Snowflake Capacity에서 차감됨 |
| 약정 | 활성화는(60일 평가판 이후) 취소할 수 없는 36개월 약정을 시작함 |
| 수명 주기 | 약정 이후(36개월+): 최초 36개월 후 라이선스 비용은 $0로 내려가지만 S&M 비용은 12개월 단위로 자동 갱신되며 월별로 청구됨. 잠금 위험: S&M 갱신을 거부하면 S&M 적용이 끝날 때 커넥터가 영구적으로 잠깁니다. 커넥터 잠금을 해제하려면 새 Embedded License를 구매해야 하며, 이는 전액 정가의 새 36개월 약정을 시작합니다 |
| 관리 UI | 모든 라이선스 작업(Start/Cancel Trial, Monitor Usage, Opt-out)은 Snowsight의 Admin » Terms » Openflow for Oracle에서 ORGADMIN이 수행. 단계별 지침은 'Openflow Connector for Oracle: Enable and manage commercial terms' 참조 |
| 제한 | 다음 고객은 자격이 없음: GCP Marketplace를 통해 Snowflake를 구매하는 고객. 제3자 리셀러를 통해 Snowflake와 계약한 고객 |
2. 임베디드 라이선스(12개월 약정, Snowflake 제공)
참고: Openflow에서 이 라이선스 옵션은 Oracle Embedded License(Public Sector)로 표시됩니다.
Snowflake가 Oracle XStream 라이선스를 비용을 받고 직접 제공합니다. 이 모델은 Oracle과 직접 계약하지 않고 XStream 복제를 사용할 수 있게 해 줍니다. 자세한 내용은 'Embedded license details for 12-month commitment'와 'Openflow Connector for Oracle Addendum'을 참조하세요.
| 약관 | 세부 사항 |
|---|---|
| 과금 | 일회성 라이선스 비용과 연간 지원·유지 보수(S&M) 비용이 Snowflake Capacity에서 차감됨 |
| 약정 | 활성화는(60일 평가판 이후) 취소할 수 없는 12개월 약정을 시작하며, 라이선스 비용은 전액 선불로 지불되고 S&M 비용은 연간 청구됨 |
| 수명 주기 | 약정 이후(12개월+): 최초 12개월 후 라이선스 비용은 $0로 내려가지만 S&M 비용은 12개월 단위로 자동 갱신되며 연간 청구됨. 잠금 위험: S&M 갱신을 거부하면 S&M 적용이 끝날 때 커넥터가 영구적으로 잠깁니다. 커넥터 잠금을 해제하려면 새 Embedded License를 구매해야 하며, 이는 전액 정가의 새 12개월 약정을 시작합니다 |
| 관리 UI | 모든 라이선스 작업은 Snowsight의 Admin » Terms » Openflow for Oracle에서 ORGADMIN이 수행. 단계별 지침은 'Openflow Connector for Oracle: Enable and manage commercial terms' 참조 |
| 제한 | 다음 고객은 자격이 없음: GCP Marketplace를 통해 Snowflake를 구매하는 고객 |
3. 독립 라이선스(Bring Your Own License, BYOL)
XStream 권한을 포함하는 직접 소유한 Oracle 라이선스(예: Oracle GoldenGate 라이선스)를 제공합니다. 자세한 내용은 'Independent license (BYOL) details'를 참조하세요.
| 약관 | 세부 사항 |
|---|---|
| 과금 | Snowflake로부터 추가 라이선스 비용 없음. 표준 스토리지·컴퓨트 비용(예: Openflow Compute)이 적용됨 |
| 준수 | Oracle 라이선스 준수는 전적으로 귀하의 책임 |
| 사용 | GCP Marketplace 고객에게 필수 |
Oracle XStream 라이선스 모델 선택
Oracle용 Openflow 커넥터는 Oracle XStream 서비스에 대한 유료 라이선스가 필요합니다. 세 가지 라이선스 모델을 사용할 수 있습니다.
- Oracle Embedded License(36개월 약정)
- Oracle Embedded License(12개월 약정)
- Independent Oracle License(Bring Your Own License, BYOL)
다음 표로 조직에 적합한 모델을 결정하세요.
| 고려 사항 | Oracle Embedded License(36개월 약정) | Oracle Embedded License(12개월 약정) | Independent License(BYOL) |
|---|---|---|---|
| 대상 | Oracle XStream 기술을 Snowflake 계약을 통해 직접 라이선스하고 36개월에 걸친 월별 지불 일정을 선호하는 고객 | Oracle XStream 기술을 Snowflake 계약을 통해 라이선스해야 하지만 다년 약정에 동의할 수 없거나 월별 지불 대신 선불 지불 옵션을 선호하는 고객 | 이미 Oracle GoldenGate 라이선스 또는 XStream 권한을 제공하는 다른 Oracle 계약이 있는 고객 |
| 과금 | 소스 Oracle DB의 프로세서 코어 수에 따라 Snowflake를 통해 월별 청구됨. 취소할 수 없는 36개월 약정 포함. 지원·유지 보수 서비스도 월별 청구. 또한 표준 스토리지·컴퓨트 비용(예: Openflow Compute)이 적용됨 | 소스 Oracle DB의 프로세서 코어 수에 따라 Snowflake를 통해 선불 청구됨. 모든 라이선스 비용이 전액 선불로 지불되는 취소할 수 없는 12개월 약정 포함. 지원·유지 보수 서비스도 연간 선불 청구. 또한 표준 스토리지·컴퓨트 비용이 적용됨 | Snowflake로부터 Oracle XStream 서비스에 대한 추가 라이선스 또는 지원·유지 보수 비용 없음. 모든 라이선스와 준수는 Oracle과 직접 책임. 표준 스토리지·컴퓨트 비용이 적용됨 |
| 구성 | 커넥터 파라미터에 Oracle DB의 CPU 코어 수와 Oracle의 프로세서 라이선스 계수를 입력해야 함 | 커넥터 파라미터에 Oracle DB의 CPU 코어 수와 Oracle의 프로세서 라이선스 계수를 입력해야 함 | Snowflake에 CPU 코어 정보를 제공할 필요 없음 |
| 평가판 기간 | 최대 16 라이선스 코어에 대한 60일 무료 평가판 포함. 61일째에 자동으로 과금 시작 | 최대 16 라이선스 코어에 대한 60일 무료 평가판 포함. 61일째에 자동으로 과금 시작 | Snowflake를 통한 평가판은 제공되지 않음. 사용은 기존 Oracle 계약의 적용을 받음 |
36개월 약정 임베디드 라이선스 세부 사항
이 옵션을 선택하면 Snowflake를 통해 커넥터와 함께 Oracle XStream 기술을 사용할 권리를 구매하는 것입니다. 다음 주요 약관을 유의하세요.
과금
Oracle XStream 서비스는 월별로 청구되며 Snowflake Capacity 잔액에서 차감됩니다. 비용은 두 구성 요소로 이루어집니다. 라이선스 비용과 지원·유지 보수(S&M) 비용. 라이선스 비용은 소스 Oracle 데이터베이스의 프로세서 코어 수에 Oracle Processor Licensing Factor를 곱해 계산됩니다.
약정
최대 16 라이선스 코어에 대해 처음 60일은 무료입니다. 그러나 60일 평가판을 넘어 커넥터를 활성화하면 취소할 수 없는 36개월 청구 약정이 시작됩니다.
- 자동 전환: 청구는 61일째에 자동으로 시작됩니다. 요금을 피하려면 60일 이전에 Admin » Terms » Openflow for Oracle 대시보드에서 평가판을 취소해야 합니다.
- 잠금: 이 약정 기간 중 Snowflake 계약이 종료되면 36개월 약정의 전체 잔여 잔액이 즉시 지불 기한이 됩니다.
약정 이후 갱신 및 불이익
최초 36개월 약정 후 라이선스 비용은 $0가 되지만 지원·유지 보수(S&M) 비용은 계속됩니다.
- 거부(opt-out) 결과: Admin » Terms » Openflow for Oracle 대시보드에서 S&M 갱신을 거부할 수 있습니다. 그러나 S&M 적용이 중지되면 커넥터 프로세서가 잠깁니다. 운영을 재개하려면 새 Embedded License를 구매해야 하며, 이는 36개월 전액 정가 약정을 재설정합니다.
요구 사항
커넥터 구성에 프로세서 코어 수와 올바른 라이선스 계수를 정확히 보고할 책임이 있습니다. 소스 데이터베이스 하드웨어가 변경되면 이 정보를 최신으로 유지해야 합니다.
구성
Embedded License(36개월 약정)를 구성하려면:
- UI에 제시된 'Openflow Connector for Oracle Addendum' 약관을 검토하고 수락합니다.
- 36개월 약정용 Oracle Embedded License 타일을 선택합니다.
- 소스 Oracle 데이터베이스에 대한 CPU 코어 수 세부 사항을 입력합니다. Oracle Database Processor Cores(소스 데이터베이스 서버의 총 물리 코어 수)와 Oracle Database Processor Multiplier(Oracle 프로세서 라이선스 계수, 예: Intel 프로세서의 경우 0.5). 올바른 값은 Oracle Processor Core Factor Table을 참조하세요.
12개월 약정 임베디드 라이선스 세부 사항
이 옵션을 선택하면 12개월, 선불 청구 약정으로 Snowflake를 통해 커넥터와 함께 Oracle XStream 기술을 사용할 권리를 구매하는 것입니다. 다음 주요 약관을 유의하세요.
과금
Oracle XStream 서비스는 선불로 청구되며 Snowflake Capacity 잔액에서 차감됩니다. 비용은 두 구성 요소로 이루어집니다. 라이선스 비용과 지원·유지 보수(S&M) 비용. 라이선스 비용은 소스 Oracle 데이터베이스의 프로세서 코어 수에 Oracle Processor Licensing Factor를 곱해 계산됩니다.
약정
최대 16 라이선스 코어에 대해 처음 60일은 무료입니다. 그러나 60일 평가판을 넘어 커넥터를 활성화하면 취소할 수 없는 12개월 청구 약정이 시작됩니다.
- 자동 전환: 청구는 61일째에 자동으로 시작됩니다. 요금을 피하려면 60일 이전에 Admin » Terms » Openflow for Oracle 대시보드에서 평가판을 취소해야 합니다.
- 잠금: 이 약정 기간 중 Snowflake 계약이 종료되면 12개월 약정의 전체 잔여 잔액이 즉시 지불 기한이 됩니다.
약정 이후 갱신 및 불이익
최초 12개월 약정 후 라이선스 비용은 $0가 되지만 지원·유지 보수(S&M) 비용은 연간 단위로 계속됩니다.
- 거부(opt-out) 결과: Admin » Terms » Openflow for Oracle 대시보드에서 S&M 갱신을 거부할 수 있습니다. 그러나 S&M 적용이 중지되면 커넥터 프로세서가 잠깁니다. 운영을 재개하려면 새 Embedded License를 구매해야 하며, 이는 12개월 전액 정가 약정을 재설정합니다.
요구 사항
커넥터 구성에 프로세서 코어 수와 올바른 라이선스 계수를 정확히 보고할 책임이 있습니다. 소스 데이터베이스 하드웨어가 변경되면 이 정보를 최신으로 유지해야 합니다.
구성
Embedded License(12개월 약정)를 구성하려면:
- UI에 제시된 'Openflow Connector for Oracle Addendum' 약관을 검토하고 수락합니다.
- 12개월 약정용 Oracle Embedded License(Public Sector) 타일을 선택합니다.
- 소스 Oracle 데이터베이스에 대한 CPU 코어 수 세부 사항을 입력합니다. Oracle Database Processor Cores와 Oracle Database Processor Multiplier(Oracle 프로세서 라이선스 계수, 예: Intel 프로세서의 경우 0.5). 올바른 값은 Oracle Processor Core Factor Table을 참조하세요.
독립 라이선스(BYOL) 세부 사항
이 옵션은 필요한 Oracle 기술을 이미 라이선스한 고객을 위한 것입니다.
요구 사항
커넥터 사용이 기존 Oracle 라이선스 계약의 약관을 준수하는지 확인할 책임은 전적으로 귀하에게 있습니다. Snowflake는 귀하의 Oracle 권한을 검증하거나 감사하지 않습니다.
구성
Independent License(BYOL)를 구성하려면:
- UI에 제시된 'Openflow Connector for Oracle Addendum' 약관을 검토하고 수락합니다.
- Independent License 유형을 선택합니다.
- 커넥터를 구성할 때 코어 수나 청구 관련 정보를 입력하지 않고 진행합니다.
Openflow 요구 사항
Oracle용 Openflow 커넥터에는 다음 Openflow 런타임 요구 사항이 적용됩니다.
- 지속적인 복제 워크로드에 따라 런타임 크기를 선택하세요. 크기 조정 지침과 한 런타임에서 여러 커넥터를 실행하는 방법은 Runtime sizing을 참조하세요.
- 커넥터는 다중 노드 Openflow 런타임을 지원하지 않습니다. 이 커넥터의 런타임은 Min nodes와 Max nodes를 1로 설정해 구성하세요.
지원되는 Oracle 버전 및 플랫폼
다음 Oracle 데이터베이스 버전과 플랫폼이 지원됩니다.
- Oracle 데이터베이스 버전 11g 이상
- 온프레미스 서버
- Oracle Exadata
- OCI VM/Bare Metal
- AWS Custom RDS for Oracle
- AWS Standard Single-tenant RDS for Oracle
Data Guard 및 standby 지원
Data Guard standby에 연결하면 기본(primary) Oracle 데이터베이스에서 복제 부하를 제거할 수 있습니다. 어떤 토폴로지가 필요한지는 standby가 물리적(physical)인지 논리적(logical)인지에 따라 다릅니다.
Active Data Guard(물리적 standby)
Active Data Guard는 물리적 standby, 즉 기본 데이터베이스의 읽기 전용 복사본입니다. XStream은 메타데이터에 대해 쓰기 가능한 데이터베이스가 필요하므로 여기에는 XStream 아웃바운드 서버를 만들 수 없습니다.
커넥터는 여전히 Active Data Guard와 함께 작동합니다. 스냅샷 로드에는 물리적 standby를 사용하세요(Oracle Connection URL). 증분(CDC) 로드의 경우 쓰기 가능한 데이터베이스(XStream Out Server URL)에 XStream 아웃바운드 서버를 만드세요. 기본 데이터베이스거나, CDC도 기본에서 분리하려면 별도의 downstream capture 데이터베이스일 수 있습니다.
Active Data Guard에 대해 스냅샷을 실행할 때 Snapshot Fetching Strategy를 SEQUENTIAL_BY_PRIMARY_KEY로 설정하세요. 기본 CONCURRENT_BY_ROWID 전략은 병렬 작업으로 테이블을 범위로 나누는데, 이는 읽기 전용 standby에서는 허용되지 않습니다.
논리적 standby
논리적 standby는 읽기-쓰기로 열려 있으며 SQL Apply로 기본 데이터베이스의 변경을 적용합니다. 커넥터는 스냅샷과 CDC 양쪽에 논리적 standby를 사용할 수 있으므로, XStream용 추가 데이터베이스가 필요 없습니다.
아웃바운드 서버를 만들거나 커넥터를 시작하기 전에 Database Guard를 STANDBY로 설정하세요. 논리적 standby는 기본적으로 ALL이며, 이는 ORA-16224: Database Guard is enabled로 XStream 클라이언트를 차단합니다.
설정 단계는 'Data Guard or standby capture (optional)'을 참조하세요.
제한 사항
Oracle용 Openflow 커넥터에는 다음 제한 사항이 적용됩니다.
- AWS Standard Multi-tenant RDS for Oracle은 지원되지 않습니다.
- Oracle Autonomous Databases(ATP/ADW)는 지원되지 않습니다.
- Oracle Fusion Cloud Applications, NetSuite 같은 Oracle SaaS 제품은 지원되지 않습니다.
- Active Data Guard 물리적 standby는 읽기 전용이므로 XStream 아웃바운드 서버는 기본, 논리적 standby, 또는 별도의 downstream capture 데이터베이스에 만드세요. 자세한 내용은 'Data Guard and standby support'를 참조하세요.
- 커넥터는 BYOC에 대해 Openflow 배포 버전 0.55.0 이상이 필요합니다.
- Openflow 런타임은 필수 Openflow 배포 버전이 설치된 후에 만들어야 합니다.
- 각 복제 테이블에는 기본 키, 자격이 되는 고유 제약 조건, 자격이 되는 고유 인덱스, 또는 사용자가 선언한 논리 키가 있어야 합니다. 자세한 내용은 'How the connector chooses a replication key'를 참조하세요.
- 커넥터는 복제 중 열 추가, 삭제, 이름 변경 같은 일반적인 소스 테이블 스키마 변경을 지원합니다. 전체 목록과 지원되지 않는 변경 유형 몇 가지는 Schema changes를 참조하세요.
- 가장 이른 위치에서 redo 로그를 다시 읽는 동안 스키마 변경(열을 추가·삭제하는 ALTER TABLE 문 등)은 지원되지 않습니다. 사용 가능한 가장 이른 SCN과 현재 위치 사이에 테이블의 스키마가 변경되었다면 해당 테이블을 복제에서 제거하고 새 스냅샷으로 다시 추가해야 합니다.
- 커넥터는 복제 키로 사용하는 기본 키, 고유 제약 조건, 고유 인덱스를 삭제하거나 수정할 때 런타임에서 감지하지 못합니다. 이 제한은 복제 키 열 이름 변경에도 적용됩니다. 그러한 변경 후에는 영향을 받는 테이블의 복제를 다시 시작하세요. 'Restart table replication' 참조.
- 소스에서 논리 키 값이 변경되면 커넥터는 이전 행을 소프트 삭제하지 않아, 목적지에 중복 활성 행이 발생합니다. 자세한 내용은 'Limitation: Changes to a logical-key value'를 참조하세요.
- DBMS_LOB 패키지(예: DBMS_LOB.WRITEAPPEND, DBMS_LOB.WRITE, DBMS_LOB.ERASE, DBMS_LOB.TRIM)로 대형 객체(LOB) 값의 일부만 수정하는 업데이트는 지원되지 않습니다. Oracle XStream은 변경된 LOB 값의 일부만 보고하지만, 커넥터는 병합 쿼리를 조정하려면 전체 값이 필요하므로 영향을 받는 LOB 열은 Snowflake에서 NULL로 복제됩니다. 이를 유발하는 일반적인 패턴은 EMPTY_CLOB()(또는 EMPTY_BLOB())로 행을 삽입한 뒤 DBMS_LOB.WRITEAPPEND로 LOB를 채우는 것입니다. LOB가 단일 INSERT 또는 UPDATE 문에서 인라인으로 쓰이면 올바르게 복제됩니다. 작은 LOB 값의 경우 DBMS_LOB.WRITEAPPEND가 전체 값을 가진 UPDATE LCR을 생성할 수 있으며, 이 경우 행이 올바르게 복제됩니다. 커넥터가 지원되지 않는 부분 LOB 연산을 관찰하면 영향을 받는 행의 소스 테이블과 기본 키를 식별하는 WARN 수준 메시지를 기록해 변경을 수동으로 조정할 수 있게 합니다.
- 커넥터는 테이블 잘라내기(truncate) 연산을 지원하지 않습니다. 소스의 TRUNCATE 문은 무시되며 해당 행 삭제는 목적지 테이블에 적용되지 않습니다.
커넥터 동작 방식
다음 섹션에서는 복제, 스키마 변경, 데이터 보존을 포함해 다양한 맥락에서 커넥터가 어떻게 동작하는지 설명합니다.
테이블 복제 방식
목적지 스키마 이름은 Destination Schema Pattern 파라미터로 결정됩니다. 자세한 내용은 'Snowflake Destination Parameters'를 참조하세요. 기본적으로 목적지 스키마 이름은 소스 데이터베이스 이름과 소스 스키마 이름을 밑줄로 연결한 것이므로 목적지 테이블의 정규화된 이름은 다음과 같습니다.
<destination_database>.<source_database_name>_<source_schema_name>.<source_table_name>
테이블은 다음 단계로 복제됩니다.
- 스키마 introspection: 커넥터가 소스 테이블의 열(열 이름과 유형 포함)을 발견한 뒤 Snowflake와 커넥터의 제한 사항에 대해 검증합니다. 검증 실패는 이 단계를 실패하게 하고 주기가 완료됩니다. 이 단계가 성공적으로 완료되면 커넥터는 Snowflake에 빈 목적지 테이블을 만듭니다.
- 스냅샷 로드: 커넥터가 소스 테이블에서 사용 가능한 모든 데이터를 목적지 테이블로 복사합니다. 이 단계가 실패하면 더 이상 데이터가 복제되지 않습니다. 성공적으로 완료되면 소스 테이블의 데이터가 목적지 테이블에서 사용 가능해집니다.
- 증분 로드: 커넥터가 소스 테이블의 변경을 추적하고 이를 목적지 테이블에 적용합니다. 이 과정은 테이블이 복제에서 제거될 때까지 계속됩니다. 이 단계에서의 실패는 문제가 해결될 때까지 소스 테이블 복제를 영구적으로 중지합니다.
스키마 변경
증분 복제 중 커넥터는 소스 테이블 스키마 변경을 감지하고 목적지 테이블을 자동으로 업데이트할 수 있습니다. 지원되지 않는 변경은 영향을 받는 테이블의 복제를 다시 시작할 때까지 중지합니다.
지원되는 변경
커넥터는 다음 스키마 변경을 지원합니다.
- 열 추가. 커넥터가 열을 목적지 테이블에 추가하고 새 행과 업데이트된 행의 값을 복제합니다. 기존 행은 역채움되지 않으며, 변경 전에 존재했던 행에서는 새 열이 NULL입니다.
- 열 삭제. 커넥터가 목적지 열의 이름을
__SNOWFLAKE_DELETED접미사를 붙여 변경해 과거 값을 보존합니다. 자세한 내용은 'Dropped columns'을 참조하세요. - 열 이름 변경. 커넥터는 이름 변경을 원래 열 삭제와 새 열 추가로 취급합니다. 커넥터는 원래 열을 접미사가 붙은 이름으로 유지합니다. 예: A라는 열은 A__SNOWFLAKE_DELETED가 됩니다. 쿼리 패턴은 'Renamed columns'를 참조하세요.
- 호환 가능한 유형 변경. 열을 같은 Snowflake 데이터 유형으로 매핑되는 소스 유형으로 바꾸면 커넥터는 목적지 열 유형을 변경하지 않고 복제를 계속 유지합니다(예: INT→BIGINT, 둘 다 NUMBER로 매핑).
- 이전에 삭제된 열 재추가. 커넥터가 기존의 소프트 삭제된 열 옆에 새 목적지 열로 열을 추가합니다(예: A와 A__SNOWFLAKE_DELETED).
이전에 삭제되어 소프트 삭제된 열을 다시 삭제하면 소프트 삭제된 열 이름이 이미 사용 중이므로 해당 테이블의 복제가 실패합니다.
지원되지 않는 변경
커넥터는 다음 스키마 변경을 지원하지 않습니다. 달리 명시되지 않는 한 영향을 받는 테이블의 복제는 다시 시작할 때까지 중지됩니다.
- 기본 키 정의 변경. 기본 키 열 추가·제거 또는 기본 키를 구성하는 열 변경. 커넥터는 이 변경을 감지하지 못하고 이전 키로 복제를 계속합니다. 복제가 스스로 중지되지는 않습니다. 커넥터가 새 키를 인식하도록 영향을 받는 테이블의 복제를 다시 시작하세요.
- 호환되지 않는 유형 변경. 새 소스 유형이 다른 Snowflake 데이터 유형으로 매핑될 때(예: INT→VARCHAR, 각각 NUMBER와 TEXT로 매핑).
- 숫자 정밀도 또는 배율 변경. 예: NUMERIC(7,2)을 NUMERIC(6,3)으로 변경.
- 문자 열 길이 변경. 예: VARCHAR(50)을 VARCHAR(100)으로 변경.
복구하려면 영향을 받는 테이블의 복제를 다시 시작하세요. 'Restart table replication' 참조.
참고: 호환되지 않는 유형 변경의 경우 커넥터가 목적지 테이블이 업데이트되기 전에 Oracle 파라미터 유형 충돌을 보고할 수 있습니다.
테이블의 Column Filter JSON을 변경할 때도 동일한 소프트 삭제 메커니즘이 적용됩니다. 자세한 내용은 'Replicate a subset of columns in a table'을 참조하세요.
커넥터의 복제 키 선택 방식
커넥터는 각 소스 테이블에서 하나의 열 또는 열 집합을 복제 키로 사용합니다. 복제 키는 행을 고유하게 식별하고, CDC 변경을 목적지에 적용하는 MERGE 작업을 구동하며, 스냅샷 로드 중 행을 정렬합니다.
각 테이블에 대해 커넥터는 다음 순서로 복제 키를 결정합니다.
- 사용자가 선언한 논리 키. 커넥터가 테이블을 나열하는 Table Key Configuration Service로 구성된 경우 커넥터는 해당 열을 복제 키로 사용하며, 기본 키, 고유 제약 조건, 고유 인덱스를 모두 덮어씁니다. 자세한 내용은 'Specify a logical key for a table'을 참조하세요.
- 기본 키. 테이블의 활성화된 기본 키 제약 조건의 열.
- 고유 제약 조건 또는 고유 인덱스. 테이블에 기본 키가 없으면 커넥터는 'Qualifying unique constraints and unique indexes'에 설명된 대로 자격이 되는 고유 제약 조건이나 고유 인덱스를 찾습니다.
- 없음. 자격이 되는 키가 없으면 커넥터는 테이블을 복제할 수 없습니다. 해결하려면 테이블에 기본 키를 추가하거나, 기존 제약 조건이나 인덱스가 자격 요건(아래 기준 참조)을 갖추도록 수정하거나, 행을 고유하게 식별하는 열에 논리 키를 선언하세요. 진단 단계는 문제 해결 문서의 'A table fails because the connector can't find a replication key'를 참조하세요.
자격이 되는 고유 제약 조건과 고유 인덱스
커넥터는 다음 조건이 충족될 때만 고유 제약 조건을 복제 키 후보로 평가합니다.
- 제약 조건 유형이 UNIQUE이고 ALL_CONSTRAINTS에서 STATUS = ENABLED.
- 제약 조건이 처음에 지연되지 않음(DEFERRED = IMMEDIATE). DEFERRABLE INITIALLY IMMEDIATE로 선언된 제약 조건은 자격이 되고, DEFERRABLE INITIALLY DEFERRED는 자격이 되지 않음.
- 제약 조건이 다루는 모든 열이 NOT NULL.
커넥터는 다음 조건이 충족될 때만 고유 인덱스를 복제 키 후보로 평가합니다.
- ALL_INDEXES에서 UNIQUENESS = UNIQUE이고 인덱스가 UNUSABLE이 아님.
- INDEX_TYPE = NORMAL(표준 B-tree 인덱스). 비트맵 및 함수 기반 고유 인덱스는 제외됨.
- 인덱스가 기본 키나 고유 제약 조건의 구현이 아님(제약 조건 지원 인덱스는 별도가 아니라 제약 조건을 통해 평가됨).
- 인덱스가 다루는 모든 열이 NOT NULL.
참고:
LOB,CLOB,NCLOB,LONG및 유사한 대형 객체 열은 Oracle의 고유 제약 조건이나 고유 인덱스에 나타날 수 없으므로 복제 키 열로 결코 자격을 갖추지 못합니다.
동점자 해소(tiebreaker)
둘 이상의 후보가 자격을 갖추면 커넥터는 다음 선호 순서로 결정적으로 하나를 선택합니다.
- 모든 후보 중에서 고유 제약 조건이 고유 인덱스보다 우선합니다.
- 같은 유형의 후보 중에서 열이 가장 적은 후보가 우선합니다.
- 열 수가 같은 후보 중에서 숫자 열이 가장 많은 후보가 우선합니다. 커넥터는 다음 Oracle 유형을 숫자로 간주합니다: NUMBER, INTEGER, INT, SMALLINT, FLOAT, DOUBLE, BINARY_FLOAT, BINARY_DOUBLE.
- 여전히 동점이면 알파벳 순으로 가장 낮은 제약 조건 또는 인덱스 이름을 가진 후보가 선택됩니다.
동점자 해소 결과와 무관하게 특정 열 집합을 사용하고 싶다면 논리 키로 선언하세요. 자세한 내용은 'Specify a logical key for a table'을 참조하세요.
복제 키 예시
다음 테이블에는 기본 키가 없지만 NOT NULL 열에 고유 제약 조건이 있습니다. 제약 조건이 자격을 갖추므로 커넥터는 복제 키로 제약 조건을 사용해 테이블을 복제합니다.
CREATE TABLE customers (
email VARCHAR2(255) NOT NULL,
name VARCHAR2(100),
created_at TIMESTAMP DEFAULT SYSTIMESTAMP,
CONSTRAINT uk_customers_email UNIQUE (email)
);
다음 테이블에는 기본 키도 고유 제약 조건도 없지만 NOT NULL 열에 고유 B-tree 인덱스가 있습니다. 인덱스가 자격을 갖추므로 커넥터는 복제 키로 인덱스를 사용해 테이블을 복제합니다.
CREATE TABLE sessions (
session_id VARCHAR2(64) NOT NULL,
user_id NUMBER,
created_at TIMESTAMP
);
CREATE UNIQUE INDEX idx_sessions_id ON sessions (session_id);
다음 테이블은 자동 복제 키 선택 자격을 갖추지 못합니다. 고유 제약 조건 열이 nullable이기 때문입니다. 이 테이블을 복제하려면 NOT NULL 제약 조건을 추가하거나, 열을 NOT NULL인 열로 바꾸거나, 논리 키를 지정하세요.
CREATE TABLE products (
sku VARCHAR2(50),
name VARCHAR2(100),
CONSTRAINT uk_products_sku UNIQUE (sku)
);
복제 키 값 변경
소스 업데이트가 기존 행의 복제 키 값을 변경하면 커넥터는 행의 신원이 바뀌므로 목적지 행을 제자리에서 업데이트할 수 없습니다. 대신 소스 업데이트를 목적지 테이블의 두 연산으로 나눕니다.
- 이전 값으로 키가 지정된 목적지 행이 소프트 삭제됩니다. 해당
_SNOWFLAKE_DELETED메타데이터 열이 TRUE로 설정됩니다. - 새 값으로 키가 지정된 새 목적지 행이 삽입되며, 업데이트된 페이로드와
_SNOWFLAKE_DELETED = FALSE가 설정됩니다.
따라서 변경 후 목적지 테이블에는 원래 행(소프트 삭제됨)과 새 키 값 아래의 새 행, 두 행이 포함됩니다. 현재 행만 쿼리하려면 _SNOWFLAKE_DELETED = FALSE로 필터링하세요.
이 동작은 복제 키가 기본 키이거나 자동 감지된 고유 제약 조건·고유 인덱스일 때 적용됩니다. 사용자가 선언한 논리 키는 다르게 동작합니다. 'Limitation: Changes to a logical-key value'의 제한 사항을 참조하세요.
초과 크기 값
기본적으로 커넥터는 최대 16 MB까지의 개별 값을 복제합니다. 커넥터가 더 큰 값을 만나면 관련 테이블을 영구 실패로 표시하고 복제를 중지합니다. 초과 크기 값 처리 방식을 변경하려면(예: NULL로 바꾸기) Oversized Value Strategy 목적지 파라미터를 수정하세요.
Snowflake 계정에 ENABLE_OPENFLOW_CDC_ORACLE_SSV2 파라미터가 true로 설정되어 있으면 값당 한도를 16 MB에서 128 MB로 높일 수 있습니다.
128 MB 값당 한도 활성화에 대한 자세한 내용과 지침은 'Increase the oversized value limit'을 참조하세요.
잘못된 행에 대한 오류 처리
잘못된 행은 수집 중 Snowflake가 거부하는 행으로, 목적지 테이블에 쓸 수 없습니다(예: 목적지 열 유형으로 변환할 수 없는 값, 필수 열 누락). Error Handling Strategy 파라미터는 커넥터가 잘못된 행을 만났을 때 하는 동작을 제어합니다.
- Fail Table(기본): 첫 번째 잘못된 행에서 커넥터가 테이블을 영구 실패로 표시하고 복제를 중지하며, 엄격한 전부 아니면 전무 복제를 유지합니다. 소스 데이터를 고친 뒤 'Restart table replication'에 설명된 대로 복제를 재개하세요.
- Log Errors and Continue: 커넥터는 유효한 행은 계속 복제하고, 거부된 각 행을 원래 페이로드와 오류 세부 정보와 함께 테이블의 오류 테이블에 기록합니다. 테이블은 실패로 표시되지 않습니다.
전략을 바꾸려면 Error Handling Strategy 파라미터를 설정하세요. 자세한 내용은 'Snowflake Destination Parameters'를 참조하세요.
거부된 행 캡처 방식
커넥터는 Snowpipe Streaming으로 데이터를 로드하므로 오류 로깅은 'Error logging in Snowpipe Streaming'에 설명된 그대로 동작합니다. Log Errors and Continue를 선택하면 커넥터는 ERROR_LOGGING 속성이 TRUE로 설정된 새 목적지·저널 테이블을 만들므로, 거부된 행은 로드를 중단하는 대신 전용 오류 테이블에 캡처됩니다. 오류 테이블은 어떤 변환 전에 Snowflake로 전송된 원래 페이로드와 함께 오류 세부 정보를 저장합니다.
ERROR_TABLE 테이블 함수로 테이블의 오류 테이블을 쿼리하세요.
SELECT * FROM ERROR_TABLE(<destination_database>.<schema>.<table>) ORDER BY timestamp;
거부된 행이 어디에 들어가는지는 복제 단계에 따라 다릅니다.
- 스냅샷 로드: 거부된 행이 목적지 테이블의 오류 테이블에 기록됩니다.
- 증분(CDC) 로드: CDC 변경이 목적지 테이블에 병합되기 전에 먼저 저널 테이블에 기록되므로 거부된 행이 저널 테이블의 오류 테이블에 기록됩니다.
커넥터는 Log Errors and Continue를 선택한 뒤 만들어진 테이블에서만 오류 로깅을 활성화합니다. 이미 복제 중이던 테이블의 거부된 행을 캡처하려면 'Enable error logging on an existing schema'의 저장 프로시저로 기존 목적지·저널 테이블에 오류 로깅을 활성화하세요.
참고: 커넥터가 잘못된 행을 만나면 거부된 행 수를 포함하는
WARN로그 항목을 내보냅니다. 이 항목들로 거부된 행 활동을 모니터링하세요.
거부된 행 소비
거부된 행을 프로그래밍 방식으로 처리하려면 오류 테이블에 스트림을 만들고 다른 Snowflake 스트림처럼 소비하세요. 자세한 내용은 'Streams on error tables'를 참조하세요.
데이터 보존 이해
커넥터는 고객 데이터가 자동으로 삭제되지 않는 데이터 보존 철학을 따릅니다. 복제된 데이터에 대한 완전한 소유권과 통제권을 유지하며, 커넥터는 과거 정보를 영구히 제거하지 않고 보존합니다.
이 접근 방식의 의미는 다음과 같습니다.
- 소스 테이블에서 삭제된 행은 물리적으로 제거되지 않고 목적지 테이블에서 소프트 삭제됩니다.
- 소스 테이블에서 제거된 열은 삭제되지 않고 목적지 테이블에서 이름이 변경됩니다.
- 저널 테이블은 무기한 보존되며 자동으로 정리되지 않습니다.
목적지 테이블 메타데이터 열
각 목적지 테이블에는 복제 정보를 추적하는 다음 메타데이터 열이 포함됩니다.
| 열 이름 | 유형 | 설명 |
|---|---|---|
| _SNOWFLAKE_INSERTED_AT | TIMESTAMP_NTZ | 행이 원래 목적지 테이블에 삽입된 시각 |
| _SNOWFLAKE_UPDATED_AT | TIMESTAMP_NTZ | 행이 목적지 테이블에서 마지막으로 업데이트된 시각 |
| _SNOWFLAKE_DELETED | BOOLEAN | 행이 소스 테이블에서 삭제되었는지 여부. true이면 행이 소프트 삭제되어 더 이상 소스에 존재하지 않음 |
소프트 삭제된 행
행이 소스 테이블에서 삭제되면 커넥터는 이를 목적지 테이블에서 물리적으로 제거하지 않습니다. 대신 _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 메커니즘의 제한 때문에 커넥터는 열 이름 변경과 열 삭제 후 새 열 추가를 구분할 수 없습니다. 그 결과 소스 테이블에서 열 이름을 바꾸면 커넥터는 이를 두 개의 별도 연산(원래 열 삭제와 새 이름으로 새 열 추가)으로 취급합니다.
예를 들어 소스 테이블에서 열 이름을 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;
중요: 목적지 테이블 구조를 수동으로 수정하는 것(열 삭제 또는 이름 변경 등)은 진행 중인 복제를 방해하고 데이터 불일치를 유발할 수 있으므로 권장되지 않습니다.
저널 테이블
증분 복제 중 소스 데이터베이스의 변경은 목적지 테이블에 병합되기 전에 먼저 저널 테이블에 기록됩니다. 커넥터는 저널 테이블에서 데이터를 자동으로 제거하지 않습니다. 이 데이터는 감사, 디버깅, 재처리 목적으로 유용할 수 있기 때문입니다.
저널 테이블은 해당 목적지 테이블과 같은 스키마에 만들어지며 다음 명명 규칙을 따릅니다.
<TABLE_NAME>_JOURNAL_<timestamp>_<number>
여기서:
- <TABLE_NAME>은 목적지 테이블 이름.
는 Unix epoch 형식(1970년 1월 1일 이후 초)의 생성 타임스탬프로 고유성을 보장. 는 1에서 시작해 소스 테이블의 스키마 변경이나 열 필터 수정으로 인해 목적지 테이블 스키마가 바뀔 때마다 증가.
예를 들어 목적지 테이블이 SALES.ORDERS라면 저널 테이블 이름은 SALES.ORDERS_JOURNAL_1705320000_1일 수 있습니다.
중요: 복제가 진행 중일 때 저널 테이블을 삭제하지 마세요. 활성 저널 테이블 제거는 데이터 손실이나 복제 실패를 유발할 수 있습니다. 해당 소스 테이블이 복제에서 완전히 제거된 후에만 저널 테이블을 삭제하세요.
저널 테이블 스토리지 관리
오래된 저널 데이터를 제거해 스토리지 비용을 관리해야 한다면, 더 이상 복제되지 않는 테이블의 저널 테이블을 주기적으로 정리하는 Snowflake 태스크를 만들 수 있습니다.
저널 정리를 구현하기 전에 다음을 확인하세요.
- 해당 소스 테이블이 복제에서 완전히 제거되었는지.
- 감사나 처리 목적으로 저널 데이터가 더 이상 필요 없는지.
자동 정리용 태스크 생성·관리에 대한 정보는 'Introduction to tasks'를 참조하세요.
다음 단계
이 문서를 검토한 뒤 다음 단계를 고려하세요.
- 커넥터를 활성화하고, Oracle XStream 약관을 수락하며, 라이선스 모델을 구성하려면 'Openflow Connector for Oracle: Enable and manage commercial terms'를 검토하세요.
- 커넥터가 데이터 유형을 Snowflake 데이터 유형으로 매핑하는 방법을 이해하려면 'Openflow Connector for Oracle: Data mapping'을 검토하세요.
- 커넥터 설정은 'Set up tasks for the Openflow Connector for Oracle'을 검토하세요.