ORACLE GoldenGate 11g INSERTUPDATES v1.1
|
13.07.23 |
1.1 |
INSERTUPDATES 내용 보정 |
|
13.07.17 |
1.0 |
|
|
|
|
|
1. INSERTUPDATES
INSERTUPDATES 는 REPLICAT 에 사용하는 GoldenGate Parameter 이다.
위 파라미터는 존재하지 않는 ROW 에 대한 UPDATE 에 대해 INSERT 로 데이터를 복제해 준다.
(위 내용은 INSERTMISSINGUPDATES 에 대한 이야기다.)
위 파라미터는 UPDATE 를 INSERT 로 처리한다.
처리되는 결과만을 보고 이야기 한다면 존재하지 않는 데이터에 대해서는 새로이 INSERT 된 결과를 얻고,
존재하는 데이터에 대해서는 PK 유무에 따라 결과가 달라진다.
PK 가 있는 경우 Replicat process 가 중지되며 ( INSERT 가 불가능 하기에) ,
PK 가 없는 경우 UPDATE 구문에 대해 INSERT 로 변환되어 정상 수행된다.
다만 원치않는 경우를 초래한다.
ex) PK 가 없는 경우 (1,1) 데이터에 대해 두 번째 컬럼의 데이터를 2 로 업데이트 하게 되면
타겟의 보유 데이터는 (1,1) 에서 (1,1), (1,2) 가 된다.
2. ENVIRONMENT
<SOURCE : ORACLE>
동기화 대상 : CTEST ( ID, TXT )
ID 에 PRIMARY KEY
CHARACTERSET 은 KO16KSC5601 을 사용
<TARGET : MariaDB>
동기화 대상 : CTEST ( ID, TXT )
ID 에 PRIMARY KEY
CHARACTERSET 은 EUCKR 을 사용
DEFINITION FILE 은 TABLE 구성 컬럼 타입이 바뀌었을 때 (CLOB 으로) 확인
3. TEST OUTLINE
PRIMARY KEY INDEX 가 있을 때, NON-UNIQUE INDEX 가 있을 때, 인덱스가 없을 때, 컬럼 타입이 다를 때 definition file 의 차이
PRIMARY KEY INDEX 가 있을 때, NON-UNIQUE INDEX 가 있을 때, 인덱스가 없을 때 definition file 의 차이
PRIMARY KEY INDEX 가 있을 때, TXT 가 일반 문자열 일 때
PRIMARY KEY INDEX 가 없을 때 (NON-UNIQUE INDEX 가 있을 때와 없을 때), TXT 가 일반 문자열 일 때
PRIMARY KEY INDEX 가 있을 때, TXT 가 CLOB 일 때
PRIMARY KEY INDEX 가 없을 때 (NON-UNIQUE INDEX 가 있을 때와 없을 때), TXT 가 CLOB 일 때
INSERTUPDATES 를 이용한 데이터 복제
4. TEST
PRIMARY KEY INDEX 가 있을 때, NON-UNIQUE INDEX 가 있을 때, 인덱스가 없을 때,
컬럼 타입이 다를 때 definition file 의 차이
OGG 의 ADD TRANDATA 의 수행 유무는 definition file 의 내용에 영향을 끼치지 못한다.
|
PRIMARY INDEX 가 있을 때
Definition for table CTEST Record length: 48 Syskey: 0 Columns: 2 ID 134 13 0 0 0 1 0 8 8 8 0 0 0 0 1 0 1 3 TXT 64 30 12 0 0 1 0 30 30 0 0 0 0 0 1 0 0 0
NON-UNIQUE INDEX 가 있을 때
Definition for table CTEST Record length: 48 Syskey: 0 Columns: 2 ID 134 13 0 0 0 1 0 8 8 8 0 0 0 0 1 0 1 3 TXT 64 30 12 0 0 1 0 30 30 0 0 0 0 0 1 0 1 0
INDEX 가 없을 때
Definition for table CTEST Record length: 48 Syskey: 0 Columns: 2 ID 134 13 0 0 0 1 0 8 8 8 0 0 0 0 1 0 1 3 TXT 64 30 12 0 0 1 0 30 30 0 0 0 0 0 1 0 1 0 End of definition
PRIMARY KEY 가 있고 컬럼 타입이 다를 때 (CLOB)
Definition for table CTEST Record length: 4018 Syskey: 0 Columns: 2 ID 134 13 0 0 0 1 0 8 8 8 0 0 0 0 1 0 1 3 TXT 64 4000 12 0 0 1 0 4000 4000 0 0 0 0 0 1 0 0 0 End of definition
INDEX 가 없고 컬럼 타입이 다를 때 (CLOB)
Definition for table CTEST Record length: 4018 Syskey: 0 Columns: 2 ID 134 13 0 0 0 1 0 8 8 8 0 0 0 0 1 0 1 3 TXT 64 4000 12 0 0 1 0 4000 4000 0 0 0 0 0 1 0 0 0 End of definition |
Definition file 을 확인한 결과 다음의 사실을 알 수 있었다
l Unique Index 의 유무에 따라 definition file 의 내용이 변경 됨
l Non-Unique Index 의 유무는 definition file 의 내용에 영향을 미치지 않음
l 컬럼 타입이 달라지면 definition file 의 내용이 변경 됨
l CLOB 컬럼이 들어간 경우 인덱스의 유무는 definition file 내용에 영향을 미치지 않음
아래 각 테스트 케이스에 대해선 모두 definition file 을 재생성하여 진행하였다.
소스가 1, ‘안녕’ 를 가지고 타겟이 데이터가 없는 상황에 1, ‘안녕하세요’ 로 update 할 때의 결과이다.
case 1. PRIMARY KEY INDEX 가 있을 때, TXT 가 일반 문자열 일 때
case 2. PRIMARY KEY INDEX 가 없을 때, TXT 가 일반 문자열 일 때
case 3. PRIMARY KEY INDEX 가 있을 때, TXT 가 CLOB 일 때
case 4. PRIMARY KEY INDEX 가 없을 때, TXT 가 CLOB 일 때
|
case 1 |
update 에 대해 해당 값이 타겟으로 복제 됨을 확인 |
|
case 2 |
update 에 대해 해당 값이 타겟으로 복제 됨을 확인 |
|
case 3 |
update 에 대해 해당 값이 타겟으로 복제 됨을 확인 |
|
case 4 |
update 에 대해 해당 값이 타겟으로 복제 됨을 확인 |
위 표를 보면 결과적으로 data type 에 상관없이 update 구문에 대해 insert 로 처리되었음을 볼 수 있다.
위 케이스는 타겟에 데이터가 없는 상황에 대해서 작업한 것으로 source 와 target 에 데이터가
동일하게 있는 상황에서 update 를 실시하면 다음과 같은 결과를 얻는다.
|
case 1 |
replicat process 가 중지 됨 |
|
case 2 |
update 한 값이 새로이 insert 된다. |
|
case 3 |
replicat process 가 중지 됨 |
|
case 4 |
update 한 값이 새로이 insert 된다. |
case 2, 4 에 대해 GoldenGate log 를 확인해 보면 ‘SQL error 1062’ 를 확인할 수 있다.
이는 Duplicate entry 에러로 DML 이 UNIQUE 제약조건을 위배하였기에 발생한 것이다.
INSERTUPDATES 를 이용한 데이터 복제
존재하지 않는 데이터에 대한 update 가 GoldenGate Replicat parameter (INSERTUPDATES) 를 통해
데이터가 복제 (INSERT) 될 수 있다는 점은 상당히 매력적이다.
이 점을 이용해 소스에서 타겟으로 데이터 마이그레이션을 할 수 있지 않을까 생각할 수 있다.
Primary key 가 구성되어 있는 상황에서 다음과 같이 쿼리를 수행하였다.
(테스트를 위해 테이블 구조를 바꿨다.)
update ctest set prd_no = prd_no;
위에서 prd_no 는 primary key column 이다.
위 결과로 위 테이블이 가지고 있는 rows 수 만큼 타겟에 복제되었다.
하지만 내용을 조회하면 prd_no 를 제외한 모든 컬럼은 NULL 값이 들어가 있었다.
골든게이트는 리두로그, 아카이브 로그에서 데이터를 추출하는 걸 생각하면 이 일은 당연한 것이다.
update ctest set 컬럼1 = 컬럼1, 컬럼2 = 컬럼2, …
위와 같이 전 컬럼에 대해 update 를 수행하면 타겟측에 데이터가 복제되는 걸 확인할 수 있었다.
다만 위와 같은 사용은 프로덕션에 부적합하며 비현실적이다.
추가로 update 구문을 사용하는 방법 외에 supplemental logging 을 사용하는 방법이 있다
ALTER TABLE TABLE_NAME ADD SUPPLEMENTAL LOG GROUP GROUP_NAME ( COLUMN_NAME … ) ALWAYS;
위와 같이 사용하는 방법인데 CLOB 컬럼에는 사용할 수 없는 방법이다.
결론으로 각 컬럼에 대해 update 하는 방법과 일반적인 데이터 타입의 테이블에 대해서는
ALTER TABLE … ADD SUPPLEMENTAL LOG GROUP … (COLUMN_LIST) 에 복제가 필요한 컬럼을 추가하여 복제할 수 있다.