처리를 위해 테이블 준비

Db2 LUW에 대한 Oracle GoldenGate 환경에서 사용할 테이블을 준비하려면 다음 작업을 수행해야 합니다.

트리거 비활성화 및 제약 조건 연쇄화

대상 Db2 LUW 테이블에서 트리거, 계단식 삭제 제약 조건 및 계단식 업데이트 제약 조건을 사용 안함으로 설정합니다. Oracle GoldenGate는 트리거 또는 캐스케이드 제약 조건에서 발생하는 DML을 복제합니다. 대상 테이블에서 동일한 트리거 또는 제약 조건이 활성화되면 복제된 버전으로 인해 중복되고 데이터베이스가 오류를 반환합니다. 소스 테이블이 emp_src 및 salary_src이고 대상 테이블이 emp_targ 및 salary_targ인 다음 예를 고려해 보십시오.

emp_src에 대해 삭제가 실행됩니다.
삭제를 salary_src로 캐스케이드합니다.
Oracle GoldenGate는 두 삭제를 대상으로 전송합니다.
상위 삭제가 먼저 도착하여 emp_targ에 적용됩니다.
상위 삭제는 삭제를 salary_targ로 캐스케이드합니다.
salary_src에서 계단식 삭제가 salary_targ에 적용됩니다.
행은 5단계에서 이미 삭제되었으므로 찾을 수 없습니다.

테이블에 대한 행 고유성 보장

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

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

기본 키
시간 기록 또는 비구체화된 계산 열을 포함하지 않는 첫 번째 고유 키 영숫자.
앞의 키 유형이 없는 경우(테이블에 정의된 다른 유형의 키가 있더라도) Oracle GoldenGate는 모든 열의 의사 키를 생성합니다. Oracle GoldenGate가 키 또는 Oracle GoldenGate 구성에서 제외된 키에서 지원하지 않는 데이터베이스를 제외하고 고유 키에서 사용할 수 있습니다.

주: 테이블에 사용할 수 없는 다른 키가 있거나 테이블에 키가 전혀 없는 경우 Oracle GoldenGate는 적절한 메시지를 보고서 파일에 기록합니다. 모든 열에서 키를 구성하면 소스 시스템에서 Oracle GoldenGate의 성능이 저하됩니다. 대상에서 이 키로 인해 Replicat는 더 크고 덜 효율적인 WHERE 절을 사용합니다.
테이블에 적절한 키가 없거나 기존 키가 사용되지 않도록 하려는 경우 테이블에 항상 고유한 값을 포함하는 열이 있는 경우 대체 키를 정의할 수 있습니다. Extract TABLE 매개변수 및 Replicat MAP 매개변수 내에 KEYCOLS 절을 포함하여 이 대체 키를 정의합니다. 지정된 키는 Oracle GoldenGate가 찾은 기존 기본 또는 고유 키를 무효화합니다. Oracle GoldenGate에 대한 매개변수 및 함수 참조의 TABLE \| MAP를 참조하십시오.

KEYCOLS를 사용하여 커스텀 키 지정

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

주요 변경 방지

Oracle GoldenGate가 테이블에서 데이터 추출을 시작한 후에는 키에 열을 추가하지 마십시오. 이 규칙은 기본 키, 고유 키, KEYCOLS 키 또는 모든 열 키에 적용됩니다. Db2 LUW는 테이블에 추가된 열에 대해 이전 이미지를 제공하지 않습니다. 소스에서 키의 열이 업데이트되면 Oracle GoldenGate는 업데이트를 복제할 때 대상 테이블의 현재 값과 비교할 이전 이미지가 필요합니다.

Materialized Query 테이블 유지 관리

소스 및 대상 구체화된 질의 테이블(MQT) 간의 패리티를 유지 관리하려면 MQT가 아닌 기본 테이블을 복제합니다. Target Database는 Replicat가 기본 테이블에 적용하는 변경 사항에 따라 MQT를 유지 관리합니다.

다음은 이러한 테이블을 구성하는 규칙입니다.

TABLE 및 MAP 문에 기본 테이블을 포함시킵니다.
TABLE 및 MAP 문에 MQT를 포함하지 마십시오.
와일드카드는 일반 테이블 이름과 함께 MQT 이름을 분석할 수도 있지만 TABLE 및 MAP 문에서 사용할 수 있습니다. Oracle GoldenGate는 대체된 테이블 목록에서 자동으로 MQT를 제외합니다. 하지만 이름별로 Extract TABLE 문에 명시적으로 나열된 MQT는 Extract가 비정상 종료됩니다.

임시 테이블 생성

임시 테이블은 해당 데이터의 기록과 데이터가 유효한 기간을 유지 관리하는 테이블입니다. 임시 테이블은 Oracle GoldenGate에서 테이블에서 삭제되거나 갱신된 모든 이전 행을 추적하는 데 사용됩니다. 임시 테이블은 해당 행과 데이터의 업무 유효성을 유지 관리하는 데도 사용됩니다. 예를 들어, Oracle GoldenGate는 행이 유효한 기간을 추적합니다. 임시 테이블에는 시스템 기간, 응용 프로그램 기간 및 비트 시간 기준 테이블의 세 가지 유형이 있습니다.

임시 테이블로 변환

기존 테이블을 테이블의 구조를 변경하는 임시 테이블로 변환할 수 있습니다. 이 절에서는 테이블의 구조가 변경되는 방법에 대해 설명합니다. 다음 예제의 기존 테이블은 이 섹션의 예제에서 세 가지 임시 테이블 유형으로 모두 변환됩니다.

Table policy_info
(
Policy_id char[4] not null primary key,
Coverage int not null
              )
And the tables contains the following initial rows
                   POLICY_ID       COVERAGE
                   -------------        -----------
                     ABC                12000
                     DEF                 13000
                     ERT                 14000

예제 1 기존 테이블을 시스템 기간 임시 테이블로 변환

다음과 같이 SYSTEM_PERIOD, transaction id 열 및 SYSTEM_TIME 기간을 추가하여 샘플 기존 테이블을 시스템 기간 임시 테이블로 변환합니다.

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

그런 다음 다음 다음 두 가지 방법 중 하나를 사용하여 새 임시 테이블에 대한 기록 테이블을 생성합니다.

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;

CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

RESTRICT ON DROP 절에서는 시스템 기간 임시 테이블을 삭제하는 동안 내역 테이블을 삭제할 수 없습니다. 그렇지 않으면 연관된 임시 테이블을 삭제하는 동안 기록 테이블이 암시적으로 삭제됩니다. RESTRICT ON DROP. 없이 내역 테이블을 생성할 수 있습니다. 기록 테이블은 명시적으로 삭제할 수 없습니다.

기록 테이블을 생성하는 동안에는 GENERATED ALWAYS 절을 사용하면 안됩니다. 기본 테이블의 특정 행에 대한 많은 갱신이 있을 수 있으므로 시스템 기간 임시 테이블의 기본 키도 여기에 적용되지 않습니다. 이 경우 동일한 기본 키 집합에 대해 기록 테이블에 많은 삽입이 트리거됩니다. 이 외에도 기록 테이블의 구조는 연관된 시스템 기간 임시 테이블과 정확히 동일해야 합니다. 내역 테이블은 시스템 기간 임시 테이블과 동일한 열 수 및 순서를 가져야 합니다. 기록 테이블 열은 명시적으로 추가, 삭제 또는 변경할 수 없습니다. 시스템 기간 임시 테이블을 해당 기록 테이블과 다음 명령문과 연관시켜야 합니다.

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

테이블의 GENERATED ALWAYS 열은 데이터베이스 관리자가 항상 채우는 열이므로 이러한 열을 제어할 수 없습니다. 데이터베이스 관리자는 시스템 시간에 따라 이러한 열을 채웁니다.

추가 SYSTEM_PERIOD 및 transaction id 열은 다음과 같이 기존 행에 대한 기본값을 가집니다.

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

시간 기준 테이블 업데이트를 시작하면 연관된 내역 테이블이 이전 이미지로 채워집니다.

예 2 기존 테이블을 애플리케이션 기간 임시 테이블로 변환

다음과 같이 시간 열과 BUSINESS_TIME 기간을 추가하여 샘플 기존 테이블을 애플리케이션 기간 시간 기준 테이블로 변환할 수 있습니다.

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

시간 열을 추가하는 동안 기존 시간 열의 비즈니스 유효성 시간 값을 입력하는 동안 bus_start 열의 값이 항상 bus_end보다 작은지 확인해야 합니다. 이러한 열은 행의 비즈니스 유효성을 지정하기 때문입니다.

새 애플리케이션 기간 임시 테이블은 다음과 유사합니다.

POLICY_ID   COVERAGE    BUS_START  BUS_END
--------- ----------- ---------- -------------------------------
ERT             14000              10/10/2001  10/10/2002
DEF             13000             10/10/2001   10/10/2002
ABC             12000             10/10/2001   10/10/2002

예제 3 기존 테이블을 비트 시간 기준 테이블로 변환

다음과 같이 SYSTEM_TIME 및 BUSINESS_TIME 기간과 함께 SYSTEM_PERIOD, 시간 열을 추가하여 샘플 기존 테이블을 비트 시간 기준 테이블로 변환할 수 있습니다.

ALTER TABLE policy_info
   ADD COLUMN sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN;
ALTER TABLE policy_info
   ADD COLUMN sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END;
ALTER TABLE policy_info
   ADD COLUMN ts_id TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS TRANSACTION START ID;
ALTER TABLE policy_info ADD PERIOD SYSTEM_TIME(sys_start, sys_end);

ALTER TABLE policy_info ADD COLUMN bus_start DATE NOT NULL DEFAULT '10/10/2001'"
ALTER TABLE policy_info ADD COLUMN bus_end DATE NOT NULL DEFAULT '10/10/2002'
ALTER TABLE policy_info ADD PERIOD BUSINESS_TIME(bus_start, bus_end)

시간 열을 추가하는 동안 기존 시간 열의 비즈니스 유효성 시간 값을 입력하는 동안 bus_start 열은 행의 비즈니스 유효성을 지정하므로 항상 bus_end보다 작은 값을 가져야 합니다.

그런 다음 다음 다음 두 가지 방법 중 하나를 사용하여 새 임시 테이블에 대한 기록 테이블을 생성합니다.

    CREATE TABLE hist_policy_info
(
 policy_id     CHAR(4) NOT NULL,

coverage     INT NOT NULL,
sys_start    TIMESTAMP(12) NOT NULL ,

sys_end      TIMESTAMP(12) NOT NULL,

ts_id            TIMESTAMP(12) NOT NULL

           );
 ALTER TABLE hist_policy_info ADD RESTRICT ON DROP;
CREATE TABLE hist_policy_info LIKE policy_info with RESTRICT ON DROP;

RESTRICT ON DROP 절에서는 시스템 기간 임시 테이블을 삭제하는 동안 내역 테이블을 삭제할 수 없습니다. 그렇지 않으면 연관된 임시 테이블을 삭제하는 동안 기록 테이블이 암시적으로 삭제됩니다. RESTRICT ON DROP. 없이 내역 테이블을 생성할 수 있습니다. 기록 테이블은 명시적으로 삭제할 수 없습니다.

기록 테이블을 생성하는 동안에는 GENERATED ALWAYS 절을 사용하면 안됩니다. 기본 테이블의 특정 행에 대한 많은 갱신이 있을 수 있으므로 시스템 기간 임시 테이블의 기본 키도 여기에 적용되지 않습니다. 이 경우 동일한 기본 키 집합에 대해 기록 테이블에 많은 삽입이 트리거됩니다. 이 외에도 기록 테이블의 구조는 연관된 시스템 기간 임시 테이블과 정확히 동일해야 합니다. 내역 테이블은 시스템 기간 임시 테이블과 동일한 열 수 및 순서를 가져야 합니다. 기록 테이블 열은 명시적으로 추가, 삭제 또는 변경할 수 없습니다. 시스템 기간 임시 테이블을 해당 기록 테이블과 다음 명령문과 연관시켜야 합니다.

ALTER TABLE policy_info ADD VERSIONING USE HISTORY TABLE hist_policy_info.

추가 SYSTEM_PERIOD 및 transaction id 열은 다음과 같이 기존 행에 대한 기본값을 가집니다.

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID

--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

시간 기준 테이블 업데이트를 시작하면 연관된 내역 테이블이 이전 이미지로 채워집니다.

추가 SYSTEM_TIME 기간, 트랜잭션 ID 및 시간 열은 다음과 같이 기존 행에 대한 기본값을 가집니다.

POLICY_ID COVERAGE    SYS_START                        SYS_END                          TS_ID                            BUS_START         BUS_END
--------- ----------- -------------------------------- -------------------------------- -------------------------------- ---------- -------------------------------------
ABC   12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
DEF             13000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002
ERT             14000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000 10/10/2001 10/10/2002

사용자가 시간 기준 테이블 업데이트를 시작하면 내역 테이블이 이전 이미지로 채워집니다.

이기종 환경에서의 복제 예 4

적용측에 임시 테이블이 없는 이기종 구성에서는 연관된 기록 테이블이 아니더라도 시스템 기간 및 비트 시간 기준 테이블만 복제할 수 있습니다. 이 경우 복제를 수행하는 동안 SYSTEM_PERIOD 및 트랜잭션 ID 열 값을 처리해야 합니다. 이러한 열에는 대상 데이터베이스가 지원하지 않을 수 있는 일부 값이 포함됩니다. 먼저 맵 변환 함수를 사용하여 이러한 값을 Target Database에서 지원하는 형식으로 변환한 다음 그에 따라 열을 매핑해야 합니다.

예를 들어, MySQL에는 1000-01-01 00:00:00.000000에서 9999-12-31 23:59:59.999999까지의 DATETIME 범위가 있습니다. 0001-01-01-00.00.00.000000000000의 시간 기록 값을 MySQL에 복제할 수 없습니다. 이러한 값을 복제하려면 이 값을 MySQL DATETIME 값 1000-01-01 00:00:00.000000로 변환한 다음 열을 매핑해야 합니다. policy_info 시스템 기간 테이블에 다음 행이 있는 경우

POLICY_ID                                   COVERAGE    SYS_START                                         SYS_END                                                TS_ID
--------- ----------- -------------------------------- -------------------------------- -------------------------------------------------------------------------------
ABC             12000 0001-01-01-00.00.00.000000000000 9999-12-30-00.00.00.000000000000 0001-01-01-00.00.00.000000000000

행을 MySQL에 복제하려면 colmap() 함수를 사용합니다.

map *source_schema*.policy_info, target *target_schema*.policy_info colmap
(policy_id=policy_id, coverage=coverage, sys_start= @IF( ( @NUMSTR( @STREXT(sys_
start,1,4))) > 1000, sys_start, '1000-01-01 00.00.00.000000'), sys_end=sys_end,
 ts_id= @IF( ( @NUMSTR( @STREXT(ts_id,1,4))) > 1000, ts_id, '1000-01-01
 00.00.00.000000'));

임시 테이블로 복제

다음 방법 중 하나를 선택하여 다음과 같이 시스템 기간 또는 비트 시간 기준 테이블을 복제할 수 있습니다.

임시 테이블은 다른 임시 테이블로만 복제할 수 있습니다. 이것이 기본 동작입니다. Oracle GoldenGate는 적용 측면에서 자동으로 생성된 열이므로 SYSTEM_TIME 기간 및 트랜잭션 ID 열을 복제하지 않습니다. 데이터베이스 관리자는 시스템 시계 시간과 기본값을 사용하여 대상 시간 기준 테이블의 열을 채웁니다. 이러한 열의 원래 값을 보존한 후 다음 중 하나를 사용할 수 있습니다.
- 대상 임시 테이블에 추가 시간 기록 열을 추가하고 그에 따라 열을 매핑합니다. 연관된 기록 테이블에 추가 열이 자동으로 추가됩니다.
- 적용측에서 비시간 기준 테이블을 사용하고 열을 적절히 매핑합니다. 이 시나리오에서는 기록 테이블을 유지 관리할 수 없습니다.
- 소스가 Db2 LUW이고 대상이 다른 데이터베이스인 이기종 구성에서는 자동으로 생성된 열을 무시하거나 적합한 열 변환 함수를 사용하여 Target Database에서 지원하는 형식으로 열 값을 변환하고 그에 따라 대상 열에 매핑할 수 있습니다.
또는
연관된 기록 테이블이 있는 임시 테이블을 임시 및 기록 테이블에 각각 복제할 수 있습니다. 그러면 복제 매개변수 DBOPTIONS SUPPRESSTEMPORALUPDATES를 지정해야 합니다. Extract 매개변수 파일에서 캡처할 시간 기준 테이블과 내역 테이블을 모두 지정해야 합니다. Oracle GoldenGate는 SYSTEM_TIME 기간 및 트랜잭션 ID 열 값을 복제합니다. 적용측에서 내장 프로시저를 실행하려면 데이터베이스 Instance에 실행 권한이 있는지 확인해야 합니다.

Oracle GoldenGate는 기본 복제를 SYSTEM_TIME 기간으로 사용하고 transactionstart id 열이 자동 생성된 상태로 유지하면서 충돌을 감지하고 해결할 수 없습니다. 이러한 열은 set 및 where 절에 지정할 수 없습니다. SUPPRESSTEMPORALUPDATES 매개변수를 사용하는 경우 Oracle GoldenGate는 CDR을 지원합니다.