Oracle용 Openflow 커넥터 설치 및 구성

이 문서에서는 Oracle용 Openflow 커넥터를 설치하고 구성하는 단계를 설명합니다.

출처: Snowflake 문서

본문

데이터 엔지니어는 커넥터를 설치하고 구성하려면 다음 작업을 수행하세요.

커넥터 설치

데이터 엔지니어로서 커넥터를 설치하려면 다음을 수행하세요.

Openflow의 Connector library 탭으로 이동하세요.
Openflow connectors 페이지에서 커넥터를 찾아 Install을 선택하세요.
Select runtime 대화상자의 Available runtimes 드롭다운 목록에서 런타임을 선택하고 Install을 클릭하세요.
- 참고: 커넥터를 설치하기 전에 Snowflake에 커넥터가 수집한 데이터를 저장할 데이터베이스와 스키마를 만들었는지 확인하세요.
Snowflake 계정 자격 증명으로 배포에 인증하고, 런타임 애플리케이션이 Snowflake 계정에 접근하도록 허용할지 묻는 프롬프트에서 Allow를 선택하세요. 커넥터 설치 과정은 완료까지 몇 분 걸립니다.
Snowflake 계정 자격 증명으로 런타임에 인증하세요. 커넥터 프로세스 그룹이 추가된 Openflow 캔버스가 표시됩니다.

런타임 크기 조정

노드 유형 계층과 생성 후 재조정 방법을 포함한 크기 조정 지침은 CDC 커넥터용 'Runtime sizing and packing'을 참조하세요.

마이그레이션 지침은 'Reinstall the connector'를 참조하세요.

커넥터 구성

데이터 엔지니어로서 커넥터를 구성하려면 다음을 수행하세요.

추가된 런타임을 마우스 오른쪽 버튼으로 클릭하고 Parameters를 선택하세요.
필수 파라미터 값을 채우세요. 필수 파라미터 값에 대한 자세한 내용은 다음 섹션을 참조하세요.
- Snowflake Destination Parameters: Snowflake와 연결을 수립하는 데 사용.
- Oracle Ingestion Parameters: 복제할 테이블을 지정하는 데 사용.
- Oracle Source Parameters: Oracle에서 다운로드된 데이터의 구성을 정의하는 데 사용.

한 런타임에서 여러 CDC 커넥터 인스턴스를 실행하려면 Runtime sizing을 참조하세요.

Snowflake Destination Parameters

파라미터	설명	필수
Destination Database	데이터가 저장되는 데이터베이스. Snowflake에 이미 존재해야 하며 커넥터의 역할에 USAGE와 CREATE SCHEMA가 있어야 함. 이름은 대소문자를 구분함. 따옴표 없는 식별자는 대문자로 입력	예
Destination Schema Pattern	데이터가 저장되는 목적지 스키마 이름의 패턴. 커넥터는 스키마가 없으면 만듦. 다음 선택 변수로 테이블별 패턴을 사용자 지정할 수 있음: ${source.database.name}(소스 테이블의 데이터베이스), ${source.schema.name}(소스 테이블의 스키마), ${source.table.name}(소스 테이블 이름). 예: source_db.tenant_a.data라는 정규화된 이름의 테이블의 경우 패턴 prefix_${source.database.name}_${source.schema.name}은 prefix_source_db_tenant_a로 해석됨. 모든 테이블을 단일 스키마로 수집하려면 destination_schema처럼 변수 없는 스키마 이름을 제공하세요. 중요: 커넥터가 데이터 수집을 시작한 뒤에는 이 설정을 변경하지 마세요. 수집 시작 후 변경하면 기존 수집이 깨집니다. 반드시 바꿔야 한다면 새 커넥터 인스턴스를 만드세요	예
Snowflake Authentication Strategy	사용하는 경우: Snowflake Openflow Deployment 또는 BYOC → SNOWFLAKE_MANAGED 사용. 이 토큰은 Snowflake가 자동 관리. BYOC 배포는 SNOWFLAKE_MANAGED를 사용하려면 사전에 execute-as 역할을 구성해야 함. BYOC → 대안으로 인증 전략 값에 KEY_PAIR 사용 가능	예
Snowflake Account Identifier	사용하는 경우: SNOWFLAKE_MANAGED 인증 전략 → 비워야 함. KEY_PAIR → [organization-name]-[account-name] 형식의 Snowflake 계정 이름	예
Snowflake Connection Strategy	KEY_PAIR 사용 시 Snowflake에 연결하는 전략 지정: STANDARD(기본) - 표준 공개 라우팅으로 Snowflake 서비스에 연결. PRIVATE_CONNECTIVITY - AWS PrivateLink 같은 지원 클라우드 플랫폼과 연결된 프라이빗 주소로 연결	KEY_PAIR가 있는 BYOC에만 필수, 그 외에는 무시됨
Snowflake Private Key	사용하는 경우: SNOWFLAKE_MANAGED 인증 전략 → 비워야 함. KEY_PAIR → PKCS8 표준에 따라 형식화되고 표준 PEM 헤더와 푸터를 포함하는 인증용 RSA 개인 키. Snowflake Private Key File 또는 Snowflake Private Key 중 하나는 정의되어야 함	아니요
Snowflake Private Key File	사용하는 경우: SNOWFLAKE_MANAGED 인증 전략 → 개인 키 파일은 비워야 함. KEY_PAIR → PKCS8 표준에 따라 형식화되고 표준 PEM 헤더와 푸터를 포함하는 인증용 RSA 개인 키가 담긴 파일을 Snowflake에 업로드. 헤더 줄은 -----BEGIN PRIVATE로 시작. Reference asset 체크박스 선택	아니요
Snowflake Private Key Password	사용하는 경우: SNOWFLAKE_MANAGED 인증 전략 → 비워야 함. KEY_PAIR → Snowflake Private Key File과 연결된 비밀번호 제공	아니요
Snowflake Role	사용하는 경우: SNOWFLAKE_MANAGED 인증 전략 → 런타임의 execute-as 역할(또는 여기에 부여된 하위 역할) 사용. Openflow UI에서 런타임의 View Details로 이동해 찾을 수 있음. KEY_PAIR → 서비스 사용자에 대해 구성된 유효한 역할 사용	예
Snowflake Username	사용하는 경우: SNOWFLAKE_MANAGED 인증 전략 → 비워야 함. KEY_PAIR → Snowflake 인스턴스에 연결하는 데 사용할 사용자 이름 제공	예
Oversized Value Strategy	복제 중 내부 크기 제한(16 MB)을 초과하는 값을 커넥터가 처리하는 방식 결정. 가능한 값: Fail Table(기본) - 테이블이 영구 실패로 표시되고 해당 테이블의 복제가 중지. Set Null - 값이 목적지 테이블에서 NULL로 대체됨. 초과 크기 값 너머의 테이블 데이터 손실이 허용 가능할 때 테이블 실패를 방지하려면 이를 사용	아니요
Error Handling Strategy	수집 중 Snowflake가 거부하는 잘못된 행 처리 방식 결정. 가능한 값: Fail Table(기본) - 첫 번째 잘못된 행에서 테이블이 실패로 표시되고 해당 테이블의 복제가 중지. Log Errors and Continue - 커넥터가 유효한 행을 계속 복제하고 거부된 각 행을 테이블의 오류 테이블에 기록	아니요
Table Storage Format	표준 Snowflake 테이블 또는 Iceberg 테이블. 기본: STANDARD. 커넥터 시작 후 변경하지 마세요	예
Iceberg Version	Iceberg 테이블 버전, 2 또는 3(기본 3). Table Storage Format이 ICEBERG일 때만 적용. 수집 시작 후 이 값을 변경하지 마세요	아니요
Snowflake Warehouse	병합 쿼리를 실행하는 데 사용되는 Snowflake 웨어하우스. XSMALL로 시작. 테이블이 많으면 더 큰 크기보다 다중 클러스터 웨어하우스가 더 잘 확장됨	예

Oracle Ingestion Parameters

파라미터	설명
Included Table Names	정규화된 테이블 경로의 쉼표로 구분된 목록. 테이블은 정규화된 데이터베이스, 스키마, 테이블 이름 형식(DATABASE_NAME.SCHEMA_NAME.TABLE_NAME)으로 지정해야 함. 예: MYPDB.SALES.CUSTOMERS, MYPDB.SALES.ORDERS
Included Table Regex	기존·새 테이블의 자동 포함을 위해 테이블 경로와 일치시키는 정규식. 정규식 패턴은 3부분 명명 규칙(DATABASE_NAME.SCHEMA_NAME.TABLE_NAME)과 일치해야 함. 예: MYPDB\.SALES\..*(MYPDB 데이터베이스 내 SALES 스키마의 모든 테이블 일치)
Column Filter JSON	선택 사항. 테이블별 포함·제외할 열을 지정하는 필터 객체의 JSON 배열. 구문 세부 사항과 예시는 'Replicate a subset of columns in a table' 참조
Table Key Configuration Service	선택 사항. 하나 이상의 테이블에 사용자가 선언한 논리 키를 공급하는 MultiDatabaseJsonTableKeyConfigService 컨트롤러 서비스. 서비스는 키 매핑을 정의하는 Table Key Configuration JSON 속성을 노출함. 구성되면 논리 키가 최우선 순위를 가지며 커넥터가 자동 감지하는 기본 키, 고유 제약 조건, 고유 인덱스를 덮어씀. 사용 시기와 구성 방법은 'Specify a logical key for a table' 참조
Merge Task Schedule CRON	Journal에서 Destination Table로의 병합 작업이 트리거되는 시점을 정의하는 CRON 표현식. 연속 병합을 원하면 * * * * * ?으로 설정하거나, 웨어하우스 실행 시간을 제한하도록 시간 일정을 구성. 커넥터는 UTC 시간대에서 일정을 평가함. 예: * 0 * * * ? 문자열은 정각에 1분 동안 병합을 예약. * 20 14 ? * MON-FRI 문자열은 월요일부터 금요일까지 매일 오후 2:20에 병합을 예약. 추가 정보와 예시는 Quartz 문서의 cron triggers 튜토리얼 참조
Object Identifier Resolution	소스 객체 식별자(스키마, 테이블, 열 이름 등)가 Snowflake에서 어떻게 저장되고 쿼리되는지 지정. 이 설정은 SQL 쿼리에서 큰따옴표 사용 여부를 결정함. 옵션 1(기본, 대소문자 구분 없음, 권장): 변환 - 모든 식별자가 대문자로 변환. 예: My_Table은 MY_TABLE이 됨. 쿼리 - SQL 쿼리는 대소문자 구분 없이 동작해 SQL 큰따옴표가 필요 없음. 예: SELECT * FROM my_table;은 SELECT * FROM MY_TABLE;와 같은 결과를 반환. 참고: 데이터베이스 객체에 혼합 대소문자 이름이 예상되지 않으면 Snowflake는 이 옵션을 권장. 옵션 2(대소문자 구분): 변환 - 대소문자가 보존됨. 예: My_Table은 My_Table로 유지. 쿼리 - SQL 쿼리는 데이터베이스 객체의 정확한 대소문자를 일치시키기 위해 큰따옴표를 사용해야 함. 예: SELECT * FROM "My_Table";. 중요: 커넥터 수집이 시작된 뒤에는 이 설정을 변경하지 마세요. 수집 시작 후 변경하면 기존 수집이 깨집니다. 반드시 바꿔야 한다면 새 커넥터 인스턴스를 만드세요
Snapshot Fetching Strategy	스냅샷 로드 가져오기 전략 결정: CONCURRENT_BY_ROWID(기본) - 테이블을 물리적 행 ID 범위로 경계 지어진 청크로 나누고 각 청크를 병렬로 검색. 이 전략은 커넥터가 Active Data Guard 물리적 standby 같은 읽기 전용 데이터베이스에서 읽을 때 현재 지원되지 않음. SEQUENTIAL_BY_PRIMARY_KEY - 테이블의 복제 키(기본 키, 고유 제약 조건, 고유 인덱스 또는 논리 키)로 순차적으로 검색되는 고정 크기 배치 사용. 이름과 달리 이 전략은 기본 키가 아니라 커넥터가 테이블에 대해 해석한 키를 사용함
Concurrent Snapshot Queries	Snapshot 플로우에서 소스 데이터베이스로 실행할 최대 동시 쿼리 수. 늘리면 많은 테이블 스냅샷을 빠르게 할 수 있지만 소스 데이터베이스의 부하도 증가

Oracle Source Parameters

파라미터	설명	필수
Oracle Connection URL	DB에 연결하는 JDBC URL. URL은 복제할 데이터가 포함된 대상 컨테이너(PDB 또는 CDB)를 지정해야 함. 예: jdbc:oracle:thin:@:/YOUR_DB_NAME(YOUR_DB_NAME은 PDB 또는 CDB 이름). SSL이 활성화되면 TCPS 프로토콜을 사용하세요(예: jdbc:oracle:thin:@tcps://:<tcps_port>/YOUR_DB_NAME). 참고: 커넥터는 단일 데이터베이스/컨테이너 내에서 작동합니다. JDBC URL이 복제할 테이블이 있는 컨테이너를 직접 가리키는지 확인하세요	예
Oracle Username	XStream Server에 접근 권한이 있는 연결 사용자의 사용자 이름	예
Oracle Password	XStream Server에 접근 권한이 있는 연결 사용자의 비밀번호	예
Oracle SSL Mode	Oracle 데이터베이스로의 연결에 대한 SSL 암호화 제어. DISABLED(기본) - SSL 없이 연결. VERIFY_CA - SSL로 연결. 신뢰할 수 있는 인증 기관(CA)이 서버 인증서를 발급했는지 검증. VERIFY_IDENTITY - SSL로 연결. CA 인증서와 서버 호스트 이름이 인증서의 제목과 일치하는지 검증. VERIFY_CA 또는 VERIFY_IDENTITY로 설정하면 Oracle Wallet Filename 파라미터도 제공해야 함	예
Oracle Wallet Filename	Oracle auto-login 지갑 파일(cwallet.sso)이 담긴 파일 업로드. 지갑은 SSL 연결용 신뢰된 서버 인증서를 포함해야 함. 지갑 생성에 대한 정보는 'Configure SSL connections (optional)' 참조	SSL Mode가 DISABLED가 아닐 때 필수
Oracle Database Processor Multiplier	Oracle Processor Core Factor Table에 설명된 Core Processor Licensing Factor	Embedded License에만 필수
Oracle Database Processor Cores	Oracle 데이터베이스의 프로세서 코어 수	Embedded License에만 필수
XStream Billing Acknowledgement	라이선스 계약의 확인	Embedded License에만 필수
XStream Out Server Name	Oracle에 이미 존재해야 하는 XStream Server의 이름	예
XStream Out Server URL	OCI 드라이버를 사용해야 하는 XStream용 데이터베이스 연결 JDBC URL. 예: jdbc:oracle:oci:@:/SID. SSL이 활성화되면 TCPS 프로토콜을 사용하세요(예: jdbc:oracle:oci:@tcps://:<tcps_port>/SID). 참고: SSL Mode가 활성화되면 커넥터가 XStream URL에 SSL_SERVER_DN_MATCH와 MY_WALLET_DIRECTORY를 자동으로 추가합니다. 수동으로 포함할 필요가 없습니다	예

테이블의 열 하위 집합 복제

커넥터는 테이블별로 복제된 데이터를 구성된 열의 하위 집합으로 필터링할 수 있습니다. 기본 키 열은 제외와 무관하게 항상 포함됩니다.

열 필터를 적용하려면 Ingestion Parameters 컨텍스트의 Column Filter JSON 파라미터를 필터링하려는 테이블당 하나씩 필터 객체의 JSON 배열로 설정하세요.

열은 이름이나 정규식 패턴으로 포함하거나 제외할 수 있습니다. 테이블당 단일 조건을 적용하거나 여러 조건을 결합할 수 있으며, 제외가 항상 포함보다 우선합니다.

구문

배열의 각 객체는 테이블을 식별하고 포함·제외할 열을 지정합니다. 이 커넥터는 3부분 정규화된 이름(데이터베이스, 스키마, 테이블)을 사용하므로 각 객체는 schema와 table 필드 외에 database 또는 databasePattern 필드를 포함할 수 있습니다.

[
 {
 "database": "<database>" | "databasePattern": "<regex>",
 "schema": "<schema>" | "schemaPattern": "<regex>",
 "table": "<table>" | "tablePattern": "<regex>",
 "included": ["<column>", "<column>"],
 "excluded": ["<column>", "<column>"],
 "includedPattern": "<regex>",
 "excludedPattern": "<regex>"
 }
]

다음 규칙이 적용됩니다.

정확한 이름 일치에는 database, schema, table을, 정규식 일치에는 databasePattern, schemaPattern, tablePattern을 사용하세요. 같은 객체에서 필드와 그 패턴 변형을 둘 다 사용할 수는 없습니다(예: schema와 schemaPattern이 동시에 나타날 수 없음).
included, excluded, includedPattern, excludedPattern 중 최소 하나는 제공되어야 합니다.
included와 excluded 필터가 모두 지정되면 제외가 우선합니다.
여러 필터가 같은 테이블과 일치하면 마지막 일치 필터가 사용되며, 정확한 일치가 패턴 기반 필터보다 우선합니다.
값은 서로 다른 테이블에 서로 다른 필터를 적용하기 위한 객체 배열일 수 있습니다.

예시

이름으로 특정 열 포함:

[
 {
 "database": "my_db",
 "schema": "dbo",
 "table": "orders",
 "included": ["account_id", "status", "created_at"]
 }
]

이름으로 특정 열 제외:

[
 {
 "database": "my_db",
 "schema": "dbo",
 "table": "orders",
 "excluded": ["internal_note", "debug_flag"]
 }
]

포함 패턴과 특정 제외 결합(예: 모든 email 열 포함하되 admin_email 제외):

[
 {
 "database": "my_db",
 "schema": "dbo",
 "table": "contacts",
 "includedPattern": ".*_email",
 "excluded": ["admin_email"]
 }
]

데이터베이스 패턴과 정확한 스키마·테이블 이름을 섞어 데이터베이스 간 필터 적용:

[
 {
 "databasePattern": "prod_.*",
 "schema": "dbo",
 "table": "customers",
 "excluded": ["internal_note"]
 }
]

여러 필터 객체를 전달해 서로 다른 테이블에 서로 다른 규칙 적용:

[
 {"database": "my_db", "schema": "dbo", "table": "orders", "included": ["account_id", "status"]},
 {"database": "my_db", "schema": "dbo", "table": "customers", "excludedPattern": ".*_internal"}
]

같은 열 포함·제외

테이블의 복제 집합에서 열을 제거하면(제외하거나 포함 목록에서 빼면) 목적지에 소스에서 열을 삭제하는 것과 같은 효과가 있습니다. 커넥터가 접미사(기본 __SNOWFLAKE_DELETED)를 붙여 이름을 바꿔 목적지에서 열을 소프트 삭제합니다. 그런 다음 열을 복제 집합에 다시 추가했다가 두 번째로 제거하면, 소프트 삭제된 열 이름이 이미 사용 중이므로 해당 테이블의 복제가 실패합니다. 복구하려면 해당 테이블의 복제를 다시 시작하세요.

테이블에 논리 키 지정

커넥터는 복제하는 모든 테이블에 복제 키를 요구합니다. 기본적으로 커넥터는 기본 키, 그다음 자격이 되는 고유 제약 조건, 그다음 자격이 되는 고유 인덱스 순서로 복제 키를 자동 선택합니다. 전체 선택 규칙은 'How the connector chooses a replication key'를 참조하세요.

논리 키는 자동 감지된 키를 사용자가 선언한 대체물입니다. 다음 경우 논리 키를 구성하세요.

테이블에 기본 키도 자격이 되는 고유 제약 조건도 고유 인덱스도 없지만 하나 이상의 열이 데이터에서 고유한 경우.
커넥터가 자동 감지할 것과 무관하게 특정 열 또는 열 집합을 복제 키로 사용해야 하는 경우(예: 합성 기본 키를 덮어쓰려는 경우).

논리 키는 최우선 순위를 가집니다. 커넥터가 테이블에 대한 논리 키를 찾으면 그 키를 사용하고 테이블의 기본 키, 고유 제약 조건, 고유 인덱스는 무시합니다.

JSON 구문

Table Key Configuration JSON 값은 JSON 배열입니다. 각 항목은 하나의 테이블을 그 논리 키 열에 매핑합니다.

[
 {
 "database": "<database>",
 "schema": "<schema>",
 "table": "<table>",
 "logicalKey": ["<column>", "<column>"]
 }
]

필드는 다음과 같습니다.

필드	설명
database	필수. 테이블의 3부분 정규화된 이름의 데이터베이스와 일치하는 정확한 소스 데이터베이스(PDB 또는 CDB) 이름
schema	필수. 정확한 소스 스키마 이름
table	필수. 정확한 소스 테이블 이름
logicalKey	필수. 테이블에서 행을 고유하게 식별하는 소스 열 이름의 비어 있지 않은 배열

다음 규칙이 적용됩니다.

database, schema, table 일치는 대소문자를 구분합니다. Oracle은 기본적으로 식별자를 대문자로 저장하므로, 대문자 이름을 사용하세요. 큰따옴표로 묶은 혼합 대소문자나 소문자 이름으로 생성된 경우는 예외입니다.
logicalKey 열 일치는 대소문자를 구분하지 않습니다. 커넥터는 대소문자와 무관하게 소스 테이블 스키마에 대해 열 이름을 일치시킵니다.
database, schema, table이 어떤 복제된 테이블과도 일치하지 않는 항목은 조용히 무시됩니다.

논리 키 구성 예시

기본 키가 없는 테이블의 단일 열 논리 키:

[
 {
 "database": "MYPDB",
 "schema": "SALES",
 "table": "AUDIT_LOG",
 "logicalKey": ["EVENT_ID"]
 }
]

복합 논리 키:

[
 {
 "database": "MYPDB",
 "schema": "SALES",
 "table": "ORDER_LINES",
 "logicalKey": ["ORDER_ID", "LINE_ITEM_ID"]
 }
]

하나의 JSON 값에 여러 테이블의 논리 키:

[
 {
 "database": "MYPDB",
 "schema": "SALES",
 "table": "AUDIT_LOG",
 "logicalKey": ["EVENT_ID"]
 },
 {
 "database": "MYPDB",
 "schema": "SALES",
 "table": "ORDER_LINES",
 "logicalKey": ["ORDER_ID", "LINE_ITEM_ID"]
 }
]

제한 사항

다음 중 하나라도 해당되면 커넥터는 구성을 거부합니다.

logicalKey가 누락, 비어 있거나 배열이 아님.
logicalKey가 중복 열 이름을 포함(대소문자 구분 없이 비교).
logicalKey가 유사 열 ROWID를 포함. ROWID는 행이 이동할 때(예: 테이블 재빌드나 파티션 연산 후) 변할 수 있어 신뢰할 수 있는 복제 키가 아님.
logicalKey가 소스 테이블에 존재하지 않는 열 이름을 포함.

구성이 거부되면 커넥터는 컨트롤러 서비스를 활성화하지 못하거나(활성화 시점에 감지된 구조적 문제), 테이블을 NEW 상태로 보류합니다(테이블 초기화 시 감지된 문제). 구성을 고친 뒤 테이블의 복제는 상태를 재설정하지 않고 재개됩니다.

위험한 구성에 대한 경고 로그

커넥터는 다음 구성을 받아들이지만 테이블 초기화 시 경고를 기록합니다. 데이터를 주의 깊게 검증하거나, 드리프트를 교정하기 위해 주기적으로 전체 재로드를 준비하세요.

논리 키 열을 선택할 때 높은 카디널리티와 가능하면 단조 증가하는 값의 열을 선호하세요. SEQUENTIAL_BY_PRIMARY_KEY 전략을 사용하면 복제 키로 행을 정렬하므로, 낮은 카디널리티나 비단조 키는 스냅샷 성능을 저하시킬 수 있습니다.

논리 키 열이 대형 객체 유형(BLOB, CLOB, NCLOB, LONG, LONG RAW)인 경우. 대형 객체를 키로 사용하면 MERGE 성능이 심각하게 저하됩니다.
논리 키 열이 부동 소수점 유형(FLOAT, DOUBLE, REAL, BINARY_FLOAT, BINARY_DOUBLE)인 경우. 부동 소수점 비교는 정밀도 차이로 일관되지 않은 결과를 낼 수 있습니다.
복합 논리 키가 5개 이상의 열을 포함하는 경우. 긴 복합 키는 종종 설계 문제를 나타내며 MERGE 성능을 저하시킬 수 있습니다.
논리 키가 테이블의 기존 기본 키를 대체하는 경우.

제한 사항: 논리 키 값 변경

중요: 소스 UPDATE가 논리 키 열의 값을 변경하면 커넥터는 새 값으로 키가 지정된 행을 삽입하기 전에 이전 값으로 키가 지정된 행을 소프트 삭제하지 않습니다. 목적지 테이블은 소스의 단일 행에 대해 두 개의 활성 행(이전 키 값 아래에서 여전히 활성인 원래 행과 새 키 값 아래의 새 행)으로 끝납니다. 이는 논리 키를 사용하지 않는 테이블에서 기본 키 값 변경을 커넥터가 처리하는 방식과 다릅니다. 그 동작에 대한 자세한 내용은 'Changes to a replication key value'를 참조하세요. 이 제한을 피하려면 소스에서 값이 변하지 않는 열을 논리 키 열로 선택하세요. 논리 키 값이 정말 바뀐다면 영향을 받는 테이블에 대해 주기적으로 전체 재로드를 실행해 목적지를 소스와 조정하세요.

논리 키에 영향을 주는 스키마 변경

논리 키는 열 이름을 참조합니다. 커넥터는 해당 열의 이름 변경이나 삭제를 따르지 않습니다.

논리 키 열이 소스에서 삭제되면 해당 테이블의 복제가 실패합니다. 테이블이 FAILED로 표시됩니다. 복구 단계는 문제 해결 문서의 'A logical-key column was dropped or renamed on the source'를 참조하세요.
논리 키 열이 소스에서 이름이 바뀌면 구성이 여전히 이전 이름을 참조해 복제가 실패합니다. JSON을 새 이름으로 업데이트하고 테이블 복제를 다시 시작하세요.

병합 작업 일정 구성

커넥터는 웨어하우스를 사용해 변경 데이터 캡처(CDC) 데이터를 목적지 테이블에 병합합니다. Merge Journal to Destination이라는 프로세서가 이 작업을 트리거합니다. 새 변경이 없거나 Merge Journal to Destination 큐에 대기 중인 새 FlowFile이 없으면 병합이 트리거되지 않고 웨어하우스는 자동 일시 중단이 가능해집니다.

웨어하우스 비용을 제한하고 병합을 예약된 시간으로 제한하려면 Merge Task Schedule CRON 파라미터의 CRON 표현식을 사용하세요. 이는 Merge Journal to Destination 프로세서에 도달하는 FlowFiles를 조절해, 병합이 지정된 기간에만 트리거되게 합니다. 커넥터는 UTC 시간대에서 일정을 평가합니다.

추가 정보와 예시는 Quartz 문서의 cron triggers 튜토리얼을 참조하세요.

플로우 실행

평면(plane)을 마우스 오른쪽 버튼으로 클릭하고 Enable all Controller Services를 선택하세요.
가져온 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Start를 선택하세요. 커넥터가 데이터 수집을 시작합니다.

다음 단계

(선택) 스냅샷 없는 증분 복제를 설정하세요.
플로우를 모니터링하세요.

Oracle용 Openflow 커넥터 설치 및 구성