Oracle용 Openflow 커넥터: 유지 관리

이 문서에서는 Oracle용 Openflow 커넥터의 유지 관리 작업(커넥터 재설치, 시작 redo 로그 위치 설정 등)을 설명합니다. 이러한 작업은 '스냅샷 없는 증분 복제'와 함께 자주 사용됩니다.

출처: Snowflake 문서

본문

테이블의 복제 상태 확인

연결 오류나 고가용성 장애 조치 중 일시적 소스 사용 불가 같은 일시적 실패는 테이블 복제를 막지 않습니다. 복제된 테이블은 현재 상태를 유지하고 커넥터는 다음 폴링 주기에 재시도합니다. 그러나 지원되지 않는 데이터 유형 같은 영구 실패는 테이블 복제를 막습니다.

복제 문제를 해결하거나 테이블이 복제 흐름에서 성공적으로 제거되었는지 확인하려면 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'을 참조하세요.

테이블 복제 다시 시작

참고: 이 절차는 테이블을 제자리에서 다시 스냅샷합니다. 커넥터 버전 0.49.0 이상(임베디드 라이선스) / 0.48.0 이상(임베디드 라이선스, 퍼블릭 섹터) / 0.48.0 이상(독립 라이선스), 그리고 runtime-extensions 2026.9.10.9 이상이 필요합니다. 더 이른 버전에서는 Snowflake에 이미 존재하는 테이블 재스냅샷이 제자리에서 다시 로드하는 대신 실패합니다. 이 절차를 사용하기 전에 커넥터를 업그레이드하세요.

FAILED 상태의 테이블(예: 기본 키 누락이나 지원되지 않는 스키마 변경 때문)은 자동으로 다시 시작되지 않습니다. 테이블이 FAILED 상태에 들어가거나 복제를 처음부터 다시 시작해야 한다면 다음 절차로 테이블을 복제에서 제거하고 다시 추가하세요.

참고: 실패가 기본 키 누락 같은 소스 테이블의 문제 때문이라면 계속하기 전에 소스 데이터베이스에서 해당 문제를 해결하세요.

다음 방법 중 하나로 테이블을 복제에서 제거하세요.
- 테이블을 Re-snapshot Table Exclusions 파라미터에 추가해 일시적으로 복제에서 제외합니다. 이 접근 방식은 테이블이 변경하고 싶지 않은 Included Table Regex와 일치할 때 편리합니다.
- Ingestion Parameters 컨텍스트에서 Included Table Names에서 테이블을 제거하거나, Included Table Regex를 수정해 테이블이 더 이상 일치하지 않게 하세요.
테이블이 제거되었는지 확인하세요.
- Openflow 런타임 캔버스에서 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Controller Services를 선택하세요.
- 테이블 목록 컨트롤러 서비스에서 Table State Store 행을 찾아 행 오른쪽의 세로 점 3개를 클릭한 뒤 View State를 선택하세요.
- 중요: 계속하기 전에 테이블 상태가 이 목록에서 완전히 제거될 때까지 기다려야 합니다. 이 구성 변경이 완료되기 전에는 계속하지 마세요.
테이블을 다시 추가하기 전에 커넥터의 모든 큐가 비워질 때까지 기다리세요. 모든 FlowFile이 처리되면 커넥터 프로세스 그룹의 Queued 값이 0이 됩니다.
- 경고: 제거 전에 캡처된 변경 이벤트가 여전히 큐에 있는 동안 테이블을 다시 추가하지 마세요. 테이블을 다시 추가하면 커넥터가 추가 전용 모드로 새 스냅샷을 로드하므로, 재스냅샷 후 테이블에 병합되는 남은 변경 이벤트가 목적지 테이블에 중복 행을 만들 수 있습니다.
첫 단계에서 한 변경을 되돌려 테이블을 다시 추가하세요. 즉 Re-snapshot Table Exclusions에서 테이블을 제거하거나, Included Table Names 또는 Included Table Regex에 다시 추가하세요.
- 목적지 테이블을 먼저 삭제할 필요는 없습니다. 커넥터가 테이블을 제자리에서 재스냅샷합니다. 즉 현재 목적지 테이블의 제로 카피 클론을 <destination_table>_ARCHIVE_<timestamp>라는 보관 테이블로 만들고, 목적지 테이블을 비운 뒤 같은 목적지 테이블에 새 스냅샷을 로드합니다. 목적지 테이블 객체가 보존되므로 스트림 같은 종속 객체는 연결된 상태로 계속 작동합니다.
- 보관 테이블은 안전 장치로 다시 로드 직전의 목적지 테이블 콘텐츠 복사본을 유지합니다. 커넥터는 그것을 다시 읽거나 쓰지 않으므로, 백업이 더 이상 필요 없어지면 언제든 삭제할 수 있습니다. 일반적으로 재스냅샷이 완료되고 목적지 데이터가 올바른지 확인한 뒤입니다.
다시 시작을 확인하세요. 앞서 주어진 지침으로 Table State Store를 확인하세요. 테이블 상태가 NEW로 나타난 뒤 SNAPSHOT_REPLICATION으로, 마지막으로 INCREMENTAL_REPLICATION으로 전환되어야 합니다.

초과 크기 값 한도 높이기

기본적으로 커넥터는 최대 16 MB까지의 개별 값을 복제하고, 더 큰 값을 포함하는 테이블을 영구 실패로 표시합니다. Snowflake 계정에 ENABLE_OPENFLOW_CDC_ORACLE_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_ORACLE_SSV2 파라미터 값은 쿼리로 확인하지 못할 수 있습니다. 활성화되었는지 확인하려면 FlowFiles가 'Upload Rows via Snowpipe Streaming 2' 프로세서를 통해 흐르는지('Upload Rows via Snowpipe Streaming'이 아닌) 확인하세요.

프로세서 구성

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

Fetch Rows by ROWID Range(Snapshot Load 그룹) — Snapshot Fetching Strategy가 CONCURRENT_BY_ROWID일 때 사용
Fetch Table Rows(Snapshot Load 그룹) — Snapshot Fetching Strategy가 SEQUENTIAL_BY_PRIMARY_KEY일 때 사용
Read Oracle CDC Stream(Incremental Load 그룹)

각 프로세서에 대해:

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

이미 복제 중이고 목적지 열이 VARCHAR(134217728) 또는 BINARY(67108864)보다 좁은 테이블은 '기존 테이블 마이그레이션'을 참조하세요.

기존 테이블 마이그레이션

'초과 크기 값 한도 높이기'의 단계는 새로 생성되는 목적지 테이블의 한도를 높입니다. 이미 복제 중이고 목적지 열 유형이 VARCHAR(134217728)이나 BINARY(67108864)가 아니지만, 지금 원래 16 MB 한도보다 큰 값을 로드하려면 저널 테이블과 목적지 테이블 모두에서 열 유형을 수동으로 넓혀야 합니다.

마이그레이션 전에 현재 목적지 열 유형을 확인하세요. 스냅샷 복제가 수행된 시점에 따라 달라질 수 있기 때문입니다.

경고: 영향을 받는 테이블의 저널 또는 목적지 테이블을 변경하기 전에 해당 테이블의 복제를 중지해야 합니다. 복제가 활성화된 동안 이러한 테이블을 변경하면 진행 중인 데이터가 손상될 수 있습니다.

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

Snapshot Load와 Incremental Load 그룹의 최상위 프로세서를 중지해 모든 큐가 빌 때까지 영향을 받는 테이블의 복제를 중지하세요. 동등한 중지 절차는 'Reinstall the connector'의 하위 단계를 참조하세요.
열 유형에 따라 저널 테이블과 목적지 테이블 모두에서 열을 넓히세요.
- VARCHAR 열: 저널 테이블과 목적지 테이블에서 ALTER TABLE ... ALTER COLUMN ... SET DATA TYPE VARCHAR(134217728)를 실행합니다(테이블당 하나의 문).
- BINARY 열: Snowflake는 BINARY를 제자리에서 넓히는 것을 허용하지 않으므로 저널·목적지 테이블 양쪽에서 다음을 수행하세요.
  - BINARY(67108864) 유형의 새 열을 추가합니다.
  - 원래 열에서 새 열로 데이터를 복사합니다.
  - 원래 열을 삭제하고 새 열 이름을 원래 이름으로 바꿉니다.
프로세서를 다시 활성화해 복제를 다시 시작하세요.

성능 고려 사항

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

Oversized Value Strategy가 Set Null로 설정된 경우에도 커넥터는 값을 NULL로 바꾸기 전에 각 초과 크기 값을 메모리에 로드합니다. 테이블에 수 기가바이트 크기의 LOB 열이 있다면 해당 열을 복제에서 제외하세요.

스냅샷과 증분 복제 모두에서 'Upload Rows via Snowpipe Streaming 2' 프로세서 앞의 큐가 FlowFiles로 차 백프레셔를 유발할 수 있으며, 이는 많은 런타임 디스크 공간을 소비합니다. 큰 테이블에서는 추가 스토리지를 제공하도록 Large 런타임을 사용하세요. 크기 선택에 대한 지침은 Runtime sizing을 참조하세요.

스냅샷 복제

큰 LOB 값은 Fetch Rows by ROWID Range가 FlowFiles를 방출하기 전에 전체 행 페이로드(LOB 포함)를 런타임으로 읽기 때문에 스냅샷 런타임 메모리와 디스크 사용량을 크게 늘릴 수 있습니다.

Split Table into Chunks 프로세서는 테이블 힙 블록에서 ROWID 범위 크기를 정합니다. LOB는 별도 세그먼트에 저장되므로 그 크기는 이 계산에 포함되지 않습니다. 비-LOB 열 데이터가 LOB 페이로드에 비해 작으면 단일 청크가 Fetch Rows by ROWID Range가 수 기가바이트의 데이터를 읽도록 요구할 수 있습니다. 해당 청크의 출력 FlowFiles는 전체 ROWID 범위에 대한 JDBC 페치가 완료될 때까지 다운스트림으로 전달되지 않으므로, 이후 프로세서가 오랫동안 데이터를 받지 못할 수 있습니다.

증분 복제

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

증분 CDC 중 Read Oracle CDC Stream은 처리되기 전에 각 변경 행을 메모리에 구체화합니다. 이는 Oversized Value Strategy가 Set Null로 설정된 경우에도 적용됩니다. 커넥터는 초과 크기 값을 NULL로 바꾸기 전에 모든 LOB 열을 포함한 전체 행을 로드해야 하기 때문입니다. 단일 행에 여러 수 기가바이트 LOB 열이 있으면 총 메모리 내 크기가 런타임 힙을 초과해 메모리 부족 오류가 발생할 수 있습니다. 증분 CDC에 의존하기 전에 그러한 열을 복제에서 제외하세요.

기존 스키마에 오류 로깅 활성화

Error Handling Strategy 파라미터를 Log Errors and Continue로 설정하면 커넥터는 그 후에 만드는 테이블에서만 오류 로깅을 자동으로 활성화합니다. 더 일찍 만든 테이블은 오류 로깅을 켤 때까지 거부된 행을 캡처하지 않습니다. 오류 처리 전략에 대한 자세한 내용은 'Error handling for invalid rows'를 참조하세요.

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

참고: 스키마 이름은 따옴표로 묶인 식별자(예: '"my_schema"')로 전달되어 커넥터가 만든 정확한 대소문자 구분 이름과 일치합니다. 커넥터가 목적지 스키마 이름을 지정하는 방식에 대한 자세한 내용은 'Snowflake 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"');

커넥터 재설치

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

경고: 커넥터가 재설치 전에 중단된 것과 같은 CDC 스트림 위치부터 계속 복제하려면, 소스 데이터베이스가 이전 커넥터가 중지된 시점부터 새 커넥터가 시작되는 시점까지의 시간을 커버할 만큼 오래 보관된 redo 로그를 유지해야 합니다. Oracle 데이터베이스의 보관된 redo 로그 보존 기간이 충분히 높은지 확인하고 재설치 시간을 최소화하세요. 일반적으로 24시간 보존 기간이면 충분하지만, 재설치에 시간이 걸리도록 더 긴 시간이 적절할 수 있습니다. 보관된 redo 로그 보존 구성에 대한 자세한 내용은 'Openflow Connector for Oracle: Configure the Oracle database'를 참조하세요.

사전 준비 사항

커넥터 파라미터 컨텍스트 값을 검토하고 기록하세요. 같은 런타임에 커넥터를 재설치한다면 기존 컨텍스트를 재사용할 수 있습니다. 새 인스턴스가 다른 런타임에 있다면 모든 파라미터를 다시 입력해야 합니다.

기존 커넥터의 진행 중인 모든 FlowFile 처리를 마친 뒤 커넥터를 중지하세요.
- Snowsight에 로그인합니다.
- 내비게이션 메뉴에서 Ingestion » Openflow를 선택합니다.
- Launch Openflow를 선택합니다.
- Openflow 창에서 Runtimes 탭을 선택합니다.
- 커넥터가 포함된 런타임을 선택합니다.
- 커넥터를 선택합니다.
- Snapshot Load 그룹의 최상위 프로세서 Set Tables for Replication을 중지합니다.
- Incremental Load 그룹의 최상위 프로세서 Read Oracle CDC Stream을 중지합니다.
- 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: redo 로그 위치와 증분 복제 상태 같은 구성 요소 상태를 포함해, 복제가 중단된 지점부터 계속되게 함.
대상 런타임에서 커넥터를 만드세요.
- 플로우 정의를 다운로드했다면 새 런타임으로 가져오세요. 플로우 정의를 가져오면 내보내기 중 캡처된 구성 요소 상태가 보존되어 커넥터가 이전 위치부터 증분 복제를 재개합니다.
- 그렇지 않으면 커넥터의 새 인스턴스를 만드세요. 원래 커넥터와 같은 런타임을 사용한다면 기존 파라미터 컨텍스트를 유지하고 설정을 재사용할 수 있습니다.
- 다른 런타임에 설치하거나 이전 파라미터 컨텍스트를 삭제했다면 'Install and configure the Openflow Connector for Oracle'에 설명된 테이블 이름과 패턴을 포함해 구성 설정을 새 파라미터 컨텍스트에 입력하세요. 다운로드한 플로우 정의는 민감한 값(비밀번호 등)이나 업로드된 파일(Oracle auto-login 지갑 파일 등)을 포함하지 않으므로 다시 입력·업로드해야 합니다.
Oracle Ingestion Parameters 컨텍스트로 이동해 다음 파라미터를 설정하세요.
- Ingestion Type 파라미터를 incremental로 설정하세요. 우려 사항에 대한 자세한 내용은 'Enable incremental replication without snapshots on an existing connector'를 참조하세요.
- Starting XStream Position 파라미터를 Earliest로 설정하세요. 자세한 내용과 잠재적 우려 사항은 'Alter XStream outbound server'를 참조하세요.
- 참고: Export with Components State를 선택해 플로우 정의를 가져왔다면 커넥터는 이전 redo 로그 위치를 유지합니다. 이 경우 Starting XStream Position을 Latest로 두고 중단된 지점부터 복제를 계속하세요.
새 커넥터를 시작하세요.

사용 메모

새 커넥터는 원래 커넥터가 만든 기존 목적지 테이블을 사용하지만, 새 저널 테이블을 만듭니다.

XStream 아웃바운드 서버 변경

커넥터는 처리한 최신 SCN 위치로 XStream 서버를 정기적으로 업데이트합니다. 커넥터가 재설치되어 같은 XStream 아웃바운드 서버에 연결하면 중단된 SCN 위치부터 읽기를 재개합니다. 이 SCN 번호는 다음으로 확인할 수 있습니다.

SELECT PROCESSED_LOW_SCN
FROM DBA_XSTREAM_OUTBOUND_PROGRESS
WHERE SERVER_NAME = 'XOUT1';

더 이른 위치부터 데이터를 다시 읽고 싶다면 먼저 XStream 서버의 시작 SCN을 변경해야 합니다.

BEGIN
 DBMS_XSTREAM_ADM.ALTER_OUTBOUND(
 server_name => 'XOUT1',
 start_scn => <start_scn>
 );
END;
/

<start_scn> 값은 사용 가능한 redo 로그 범위 내의 유효한 SCN이어야 합니다. 시작 위치가 재설정될 수 있는 가장 낮은 SCN은 다음으로 확인할 수 있습니다.

SELECT REQUIRED_CHECKPOINT_SCN
FROM DBA_CAPTURE
WHERE CLIENT_NAME = 'XOUT1';

이것은 캡처 프로세스가 redo 정보를 요구하는 가장 낮은 SCN입니다.

XStream 위치에서 로드 지정

Oracle용 Openflow 커넥터는 Oracle redo 로그가 읽히는 시작 위치를 선택할 수 있게 해 줍니다. 기본적으로 커넥터는 최신 사용 가능 위치에서 읽습니다. 또는 소스 인스턴스에서 사용 가능한 가장 이른 위치를 선택할 수 있습니다. 가장 이른 위치에서 시작하는 것은 커넥터를 재설치할 때 흔합니다. 그러면 새 인스턴스가 다시 스냅샷하지 않고 기존 테이블 복제를 따라잡아 계속할 수 있습니다.

참고: 실행 중인 커넥터를 최신 위치에서 가장 이른 위치로 전환하면 모든 사용 가능한 redo 로그가 다시 읽히고, 재처리되고, 목적지 테이블에 다시 적용됩니다.

경고: redo 로그가 다시 읽히는 동안 모든 이벤트가 재처리·병합될 때까지 영향을 받는 목적지 테이블의 열과 데이터가 해당 소스와 동기화되지 않을 수 있습니다.

다음 파라미터는 Ingestion Parameters 컨텍스트에서 사용할 수 있습니다.

파라미터	설명
Starting XStream Position	Latest(기본): CDC 스트림 읽기가 최신 사용 가능 위치에서 시작해 계속됨. Earliest: 증분 로드가 가장 이른 사용 가능한 XStream 위치에서 시작하거나 다시 읽기 시작하도록 전환
Re-read Tables in State	New(기본): redo 로그를 다시 읽는 동안 재읽기 시작 후 복제에 추가된 새 테이블의 LCR(Logical Change Records)만 처리됨. 커넥터가 재읽기 시작 직전 위치에 도달할 때까지 다른 LCR은 폐기됨. Any active: 현재 복제 중인 모든 테이블의 이벤트를 다시 읽고 재처리

커넥터가 redo 로그 재읽기를 끝냈는지 확인하려면:

Openflow 캔버스로 이동합니다.
Incremental Load 프로세스 그룹을 엽니다.
Read Oracle CDC Stream이라는 최상위 프로세서를 마우스 오른쪽 버튼으로 클릭한 뒤 View state를 선택합니다.
상태 항목을 비교합니다.
- lcr.position.rewind: redo 로그 재읽기가 시작되기 전에 프로세서가 읽은 최신 위치.
- lcr.position.last: 프로세서가 읽은 현재 최신 위치. 이 값이 위의 rewind 값보다 낮은 동안 프로세서는 여전히 redo 로그를 재읽는 중입니다.

사용 메모

실행 중인 커넥터가 가장 이른 위치에서 읽도록 전환된 뒤 실행을 시작하면, 프로세스는 재구성되거나 취소될 수 없으며 현재 읽기 위치가 시작 전 위치에 도달할 때까지 계속됩니다.
실행 중인 커넥터에서 가장 이른 위치로 전환하면, 재처리되는 모든 테이블에 대해 기존 저널이 끝나고 새 저널 테이블이 만들어집니다.
redo 로그에 소스 데이터베이스에서 삭제 후 재생성된 이전 테이블의 이벤트가 포함되어 있다면, 스트림 재읽기는 현재 목적지의 모든 이벤트를 재처리합니다. 커넥터는 이름이 같으면 이전 소스 테이블과 현재 소스 테이블을 구분할 수 없습니다.

참고: 가장 이른 위치에서 redo 로그를 다시 읽는 동안 스키마 변경(열을 추가·삭제하는 ALTER TABLE 문 등)은 지원되지 않습니다. 사용 가능한 가장 이른 SCN과 현재 위치 사이에 테이블의 스키마가 변경되었다면 해당 테이블을 복제에서 제거하고 새 스냅샷으로 다시 추가해야 합니다.

Oracle용 Openflow 커넥터: 유지 관리