본문 바로가기

Oracle GoldenGate2

OGG 11.2.0.1.0 Trigger v1.0

OGG 11.2.0.1.0 Trigger v1.0

 

Date

Ver

Etc.

12.08.29

 

 

 

 

 

 

 

 

 

 

1.    Trigger Configuration

OGG 환경에서는 Target 시스템에 대해 Trigger disable 해야 한다.

 

그 이유는 트리거로 발생하는 operation DML 인 경우 이 또한 Redo log 에 남고, 이는 OGG extract 하여 Target System 에 전파되기 때문이다.

 

이 전파 된 행동 자체는 문제가 없지만 Target 시스템에 동일하게 존재 할 trigger 가 문제된다.

 

Trigger 를 동작시킬 행위 (DML) Target 에 복제되며, Trigger 의 동작도 Target 에 복제 되기 때문에

타겟에서는 Trigger 의 동작이 중첩될 수 있다.

 

2.    PRACTICE

l  OGG 중지

Source Target 에서 다음을 수행한다.

-      GGSCI > stop *

 

참고로 OGG DDL Replication 기능은 사용하지 않았다.

오브젝트를 새로이 생성하는 경우 OGG process RESTART 가 동반된다.

 

l  테이블 생성 (both)

SQL> create table a(no1 int primary key);

 

SQL> create table b(no1 int, no2 date default sysdate,primary key (no1,no2));

 

a 테이블은 데이터를 담는다

b 테이블은 a 에 대한 변경 사항을 기록(insert) 한다.

 

l  ADD TRANDATA (Source)

새롭게 추가 된 오브젝트에 대해 서플리멘탈로깅을 활성화 한다.

 

GGSCI (test1.daumcorp.com) 2> dblogin userid ogg,password oggtest

Successfully logged into database.

 

GGSCI (test1.daumcorp.com) 3> info trandata test.*

 

Logging of supplemental redo log data is disabled for table TEST.A.

 

Logging of supplemental redo log data is disabled for table TEST.B.

 

GGSCI (test1.daumcorp.com) 4> add trandata test.*

 

Logging of supplemental redo data enabled for table TEST.A.

 

Logging of supplemental redo data enabled for table TEST.B.

 

GGSCI (test1.daumcorp.com) 5> info trandata test.*

 

Logging of supplemental redo log data is enabled for table TEST.A.

 

Columns supplementally logged for table TEST.A: NO1.

 

Logging of supplemental redo log data is enabled for table TEST.B.

 

Columns supplementally logged for table TEST.B: NO1, NO2.

 

 

l  OGG 동작

  * 새로 추가 된 테이블에 대해 OGG 에서 수정해야 할 파라미터는 전부 수정되었다.

Source Target 에서 다음을 수행한다.

-      GGSCI > start *

 

l  데이터 입력 (source)

SQL> insert into a select level from dual connect by level < 11;

 

SQL> commit;

 

위로부터 데이터가 Target 으로 복제 됨을 확인하였다.

 

l  OGG 중지

Source Target 에서 다음을 수행한다.

-      GGSCI > stop *

 

l  트리거 생성 (both)

CREATE OR REPLACE TRIGGER NO_TRIGG

AFTER DELETE ON A FOR EACH ROW

DECLARE

BEGIN

INSERT INTO B(NO1) VALUES(:OLD.NO1);

END;

/

 

l  OGG 동작

Source Target 에서 다음을 수행한다.

-      GGSCI > start *

 

l  데이터 수정 (source)

SQL> delete from a where no1 = 5;

 

SQL> commit;

 

l  데이터비교

TABLE b 의 내용을 SELECT 한 결과는 다음과 같다.

 

<SOURCE>

SQL> select * from b;

 

       NO1 NO2

---------- --------

         5 12/08/30

 

<TARGET>

SQL> select * from b;

 

       NO1 NO2

---------- ---------

         5 30-AUG-12

         5 30-AUG-12

 

사용자가 OGG 를 통해 얻고자 하는 것은 동일한 데이터이다.

하지만 위 결과를 보면 rows 수가 차이남을 확인할 수 있다.

 

위 이유는 앞서 말했듯이 Source a 테이블에 대한 삭제가 b 테이블에 대한 Insert 를 유발하였고,

이 동작들이 그대로 복제되어 Target 에 전파되는데 타겟 입장에서 트리거가 되는 Source a 테이블에 대한 삭제가 b 테이블에 대한 Insert 를 또 일으키기 때문에 이런 경우가 생긴다.

 

이를 해결하기 위한 방법은 trigger 의 비활성화이다.

 

SQL> alter trigger no_trigg disable;