Openflow Connector for Oracle 정보¶

1. 임베디드 라이선스(Snowflake 제공)¶

Snowflake는 Oracle XStream 라이선스를 유료로 직접 제공합니다. 이 모델을 사용하면 Oracle과 직접 계약하지 않고도 XStream 복제를 사용할 수 있습니다. 자세한 내용은 임베디드 라이선스 세부 정보 및 `Oracle용 Openflow Connector 부록 <https://www.snowflake.com/en/legal/optional-offerings/offering-specific-terms/openflow-oracle-terms/>`_을 참조하세요.

2. 독립 라이선스(Bring Your Own License - BYOL)¶

XStream 권한(예: Oracle GoldenGate 라이선스)이 포함된 자체 Oracle 라이선스를 제공합니다. 자세한 내용은 :ref:`독립 라이선스(BYOL) 세부 정보 <label-oracle_byol_license_details>`를 참조하세요.

청구¶

Oracle XStream 서비스 요금은 매월 청구되며 Snowflake 용량 잔액에서 차감됩니다. 요금에는 라이선스 요금과 지원 및 유지 관리(S&M) 요금이라는 두 가지 구성 요소가 있습니다. 라이선스 요금은 소스 Oracle 데이터베이스의 프로세서 코어 수에 Oracle 프로세서 코어 인자를 곱하여 계산됩니다.

약정(“61일 차” 규칙)¶

최대 16개의 라이선스 코어에 대해 처음 60일 동안은 무료입니다. 그러나 60일 평가판 이후에 커넥터를 활성화하면 36개월 청구 기간(“초기 기간”)이 시작되며 취소할 수 없습니다.

• 자동 변환: 청구는 61일째에 자동으로 시작됩니다. 요금이 청구되지 않도록 하려면 60일 이전에 Admin » Terms » Openflow for Oracle 대시보드에서 평가판을 취소해야 합니다.

• 잠금: 이 초기 기간 중에 Snowflake 계약이 해지되면 초기 기간의 나머지 잔액 전액이 즉시 지급되어야 합니다.

만기 후 갱신 및 페널티¶

초기 기간 이후에는 라이선스 요금이 $0가 되지만, 지원 및 유지 관리(S&M) 요금은 계속 부과됩니다.

• 옵트아웃 결과: Admin » Terms » :ui:`Openflow for Oracle`의 대시보드를 통해 S&M 갱신을 옵트아웃할 수 있습니다. 그러나 S&M 적용이 중지되면 커넥터 프로세서가 잠깁니다. 작업을 재개하려면 NEW 임베디드 라이선스를 구매해야 합니다(36개월 정가 약정 재설정).

요구 사항¶

커넥터 구성에서 프로세서 코어 수 및 올바른 코어 계수를 정확하게 보고할 책임은 사용자에게 있습니다. 소스 데이터베이스 하드웨어가 변경되는 경우 이 정보를 최신 상태로 유지해야 합니다.

제한 사항¶

이 옵션을 사용할 수 없는 경우는 다음과 같습니다.

• 공공 부문 엔터티(예: 정부 및 교육 기관).

• GCP 마켓플레이스를 통해 Snowflake를 구매하는 고객.

• 서드 파티 리셀러(예: CDW, Optiv)를 통해 Snowflake와 계약한 고객.

구성¶

임베디드 라이선스를 구성하려면 다음을 수행합니다.

• UI에 제시된 Oracle용 Openflow 커넥터 부록 약관을 검토하고 동의합니다.

• Embedded License 유형을 선택합니다.

• 소스 Oracle 데이터베이스에 대한 CPU 코어 수 세부 정보인 **총 코어 수**(소스 데이터베이스 서버의 총 물리적 코어 수) 및 **코어 계수**(Oracle 프로세서 코어 계수(예: Intel 프로세서의 경우 0.5))를 입력합니다. 올바른 값은 Oracle 프로세서 코어 계수 테이블을 참조하세요.

요구 사항¶

커넥터 사용이 기존 Oracle 라이선스 계약의 약관을 준수하는지 확인할 책임은 전적으로 사용자에게 있습니다. Snowflake는 Oracle 권한을 검증하거나 감사하지 않습니다.

구성¶

독립 라이선스(BYOL)를 구성하려면 다음을 수행합니다.

• UI에 제시된 Oracle용 Openflow 커넥터 부록 약관을 검토하고 동의합니다.

• Independent License 유형을 선택합니다.

커넥터를 구성할 때 코어 수 또는 청구 관련 정보를 입력하지 않고 진행합니다.

테이블이 복제되는 방법¶

테이블은 다음 스테이지에서 복제됩니다.

1. 스키마 자가 분석: 커넥터는 열 이름 및 유형을 포함한 소스 테이블의 열을 검색한 다음 Snowflake와 커넥터의 `제한 사항`_ 에 대해 유효성을 검사합니다. 검증에 실패하면 이 스테이지도 실패하고 주기가 완료됩니다. 이 스테이지가 성공적으로 완료되면 커넥터는 Snowflake에 빈 대상 테이블을 생성합니다.

2. 스냅샷 로딩: 커넥터는 소스 테이블에서 사용 가능한 모든 데이터를 대상 테이블에 복사본으로 복사합니다. 이 스테이지에 실패하면 더 이상 데이터가 복제되지 않습니다. 성공적으로 완료되면 소스 테이블의 데이터를 대상 테이블에서 사용할 수 있습니다.

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

테이블 복제 상태¶

연결 오류와 같은 임시 오류가 발생해도 테이블 복제가 멈추지 않습니다. 그러나 지원되지 않는 데이터 타입과 같은 영구적인 오류가 발생하면 테이블 복제가 이루어지지 않습니다.

복제 문제를 해결하거나 복제 흐름에서 테이블이 성공적으로 제거되었는지 확인하려면 테이블 상태 저장소를 확인합니다.

1. Openflow 런타임 캔버스에서 프로세서 그룹을 마우스 오른쪽 버튼으로 클릭하고 :ui:`Controller Services`를 선택합니다. 컨트롤러 서비스 목록을 보여주는 테이블이 표시됩니다.

2. Table State Store 레이블이 지정된 행을 찾아 행의 오른쪽에 있는 More 버튼을 클릭한 다음 :ui:`View State`를 선택합니다.

테이블과 테이블의 현재 상태 목록이 표시됩니다. 검색 상자에 테이블 이름을 입력하여 테이블 이름으로 목록을 필터링합니다. 가능한 상태는 다음과 같습니다.

• NEW: 테이블 복제가 예약되었지만 복제가 시작되지 않았습니다.

• SNAPSHOT_REPLICATION: 커넥터가 기존 데이터를 복사하고 있습니다. 이 상태는 모든 레코드가 대상 테이블에 저장될 때까지 표시됩니다.

• INCREMENTAL_REPLICATION: 커넥터가 변경 사항을 적극적으로 복제하고 있습니다. 이 상태는 스냅샷 복제가 끝난 후에 표시되며 테이블이 복제에서 제거되거나 복제가 실패할 때까지 무기한으로 계속 표시됩니다.

• FAILED: 오류로 인해 복제가 영구적으로 중지되었습니다.

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

영구적인 오류로 인해 테이블 복제가 불가능한 경우 복제에서 테이블을 제거합니다. 실패의 원인이 된 문제를 해결한 후에는 테이블을 복제에 다시 추가할 수 있습니다. 자세한 내용은 :ref:`테이블 복제 다시 시작 <label-of_oracle_restart_table_replication>`을 참조하세요.

데이터 보존¶

대상 테이블 메타데이터 열¶

각 대상 테이블에는 복제 정보를 추적하는 다음 메타데이터 열이 포함됩니다.

일시 삭제된 행¶

소스 테이블에서 행이 삭제될 때 커넥터는 대상 테이블에서 해당 행을 물리적으로 제거하지 않습니다. 대신 _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``이 있습니다.

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

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>``은 대상 테이블의 이름입니다.

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

• ``<number>``는 1에서 시작하며 소스 테이블의 스키마 변경 또는 열 필터의 수정으로 인해 대상 테이블 스키마가 변경될 때마다 증가합니다.

예를 들어 대상 테이블이 ``SALES.ORDERS``인 경우 저널 테이블의 이름은 ``SALES.ORDERS_JOURNAL_1705320000_1``일 수 있습니다.