처리를 위해 테이블 준비

이 절에서는 처리할 테이블을 준비하는 방법에 대해 설명합니다. 테이블을 준비하려면 다음 작업이 필요합니다.

테이블에 대한 행 고유성 확인

Oracle GoldenGate에는 복제된 업데이트 및 삭제를 위한 올바른 대상 행을 찾기 위해 소스 및 대상 테이블에서 특정 형식의 고유한 행 식별자가 필요합니다.

KEYCOLS 절이 TABLE 또는 MAP 문에 사용되지 않는 한 Oracle GoldenGate는 다음 우선 순위 순서로 사용할 행 식별자를 선택합니다.

  1. 기본 키

  2. 시간 기록 또는 비구체화된 계산 열을 포함하지 않는 첫 번째 고유 키 영숫자.

  3. 앞의 키 유형이 없는 경우(테이블에 정의된 다른 유형의 키가 있더라도) Oracle GoldenGate는 모든 열의 의사 키를 생성합니다. Oracle GoldenGate가 키 또는 Oracle GoldenGate 구성에서 제외된 키에서 지원하지 않는 데이터베이스를 제외하고 고유 키에서 사용할 수 있습니다.

주: 테이블에 사용할 수 없는 다른 키가 있거나 테이블에 키가 전혀 없는 경우 Oracle GoldenGate는 적절한 메시지를 보고서 파일에 기록합니다. 모든 열에서 키를 구성하면 소스 시스템에서 Oracle GoldenGate의 성능이 저하됩니다. 대상에서 이 키로 인해 Replicat는 더 크고 덜 효율적인 WHERE 절을 사용합니다.

  1. 테이블에 적절한 키가 없거나 기존 키가 사용되지 않도록 하려는 경우 테이블에 항상 고유한 값을 포함하는 열이 있는 경우 대체 키를 정의할 수 있습니다. Extract TABLE 매개변수 및 Replicat MAP 매개변수 내에 KEYCOLS 절을 포함하여 이 대체 키를 정의합니다. 지정된 키는 Oracle GoldenGate가 찾은 기존 기본 또는 고유 키를 무효화합니다. Oracle GoldenGate에 대한 참조에서 TABLE | MAP를 참조하십시오.

고유 인덱스에서 파생된 Primary Key가 있는 테이블

테이블에 기본 키가 없는 경우 MySQL는 인덱스화된 열이 NOT NULL인 경우 고유 인덱스를 기본 키로 승격합니다. 이러한 널이 아닌 인덱스가 두 개 이상 있는 경우 처음 생성된 인덱스가 기본 키가 됩니다. Replicat 오류를 방지하려면 소스 및 대상 테이블에서 동일한 순서로 이러한 인덱스를 생성합니다.

예를 들어, ggvam.emp라는 소스 및 대상 테이블에 각각 first, middle 및 last라는 열이 있고 모두 NOT NULL로 정의되어 있다고 가정합니다. 고유 인덱스를 다음 순서로 생성하는 경우 테이블 정의가 일치하지 않으므로 Oracle GoldenGate가 대상에서 비정상 종료됩니다.

출처:

CREATE UNIQUE INDEX UQL ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ2 on ggvam.emp(middle);
CREATE UNIQUE INDEX UQ3 on ggvam.emp(last);

대상:

CREATE UNIQUE INDEX UQ1 ON ggvam.emp(last);
CREATE UNIQUE INDEX UQ2 ON ggvam.emp(first);
CREATE UNIQUE INDEX UQ3 ON ggvam.emp(middle);

이 시퀀스의 결과는 MySQL가 소스 "first" 열의 인덱스를 기본 키로 승격시키고 대상 "last" 열의 인덱스를 기본 키로 승격시키는 것입니다. Oracle GoldenGate는 메타데이터 레코드를 작성할 때 기본 키를 식별자로 선택하고 메타데이터가 일치하지 않습니다. 이 오류를 방지하려면 기본 키로 승격할 열을 결정한 다음 먼저 소스와 대상에서 해당 인덱스를 생성하십시오.

Oracle GoldenGate에 사용할 고유 키 지정

테이블에 앞의 행 식별자 유형 중 하나가 없거나 이러한 식별자를 사용하지 않으려는 경우 테이블에 항상 고유한 값을 포함하는 열이 있는 경우 대체 키를 정의할 수 있습니다. Extract TABLE 매개변수 및 Replicat MAP 매개변수 내에 KEYCOLS 절을 포함하여 이 대체 키를 정의합니다. 지정된 키는 Oracle GoldenGate가 찾은 기존 기본 또는 고유 키를 무효화합니다.

키가 없는 테이블의 행 변경 제한

대상 테이블에 기본 키나 고유 키가 없으면 중복 행이 존재할 수 있습니다. 이 경우 Oracle GoldenGate는 너무 많은 대상 행을 업데이트하거나 삭제할 수 있으므로 오류 메시지 없이 소스 및 대상 데이터가 동기화되지 않고 경보를 보낼 수 있습니다. 업데이트되는 행 수를 제한하려면 Replicat 매개변수 파일에서 DBOPTIONS 매개변수를 LIMITROWS 옵션과 함께 사용합니다. LIMITROWS는 하나의 행만 처리되므로 대상 시스템에서 Oracle GoldenGate의 성능을 향상시킬 수 있습니다.

트리거 및 계단식 제약 조건 고려 사항

트리거

대상 테이블에서 트리거를 사용 안함으로 설정하거나 Oracle GoldenGate 데이터베이스 사용자가 변경한 사항을 무시하도록 변경합니다. Oracle GoldenGate는 트리거의 결과인 DML을 복제합니다. 대상 테이블에서 동일한 트리거가 활성화되면 복제된 버전으로 인해 중복되고 데이터베이스에서 오류가 반환됩니다.

제약 조건 계단식 배열 고려 사항

Oracle GoldenGate에서 캡처한 계단식 업데이트 및 삭제는 바이너리 로그에 기록되지 않으므로 캡처되지 않습니다. 이는 MySQL 및 MariaDB에 모두 유효합니다. 예를 들어, 테이블 간의 상위 하위 관계를 사용하여 상위 테이블에서 delete 문을 실행하는 경우 하위 테이블에 대해 계단식 삭제(있는 경우)가 발생하지만 이진 로그에 기록되지 않습니다. 상위 테이블에 대한 삭제 또는 업데이트 레코드만 이진 로그에 기록되고 Oracle GoldenGate에서 캡처됩니다.

자세한 내용은 https://mariadb.com/kb/en/replication-and-foreign-keys/ 및 https://dev.mysql.com/doc/refman/8.0/en/innodb-and-mysql-replication.html를 참조하십시오.

캐스케이딩 작업의 복제를 제대로 처리하려면 상위 레코드를 수정하기 전에 애플리케이션에서 캐스케이딩 삭제 및 업데이트를 사용 안함으로 설정하고 하위 레코드를 명시적으로 삭제 또는 업데이트하도록 응용 프로그램을 코딩하는 것이 좋습니다. 또는 대상 상위 테이블에 소스 상위 테이블로 구성된 동일한 캐스케이드 제약 조건이 있는지 확인해야 하지만, 이로 인해 특히 양방향 복제의 경우 소스와 대상 간에 동기화되지 않은 조건이 발생할 수 있습니다.