Oracle]MView / DB link를 사용한 테이블 동기화

PURPOSE

 Database의 중요성은 늘 강조해도 지나치지 않다. 데이터의 손실이 기업의 금전적 손실로 이어지기 때문이다. 예를 들면 필자가 A에게 돈을 100만원 입금했다. 근데 해당 거래 은행의 Database에 장애가 생겨 데이터가 날아갔다면...? 그 시간 데이터가 날아갔다고한다면 우리가 상상도 못할 금액인 것이다. 물론, 금융권의 Database는 이중화, 삼중화, 백업, DR 시스템 등등을 갖추어 놓았기 때문에 이런일이 일어나지 않을 것이다. 

 필자가 이런 이야기를 꺼내는 이유는 무엇일까? 데이터가 중요한 만큼 우리는 언제 일어날 지 모르는 상황에 대비를 해야한다. 그렇기 때문에 고객들의 니즈도 점점 운영은 물론 잘 돌아가야하는 것은 기본이고 백업이나 데이터 동기화에 관심이 많아졌다는 이야기이다.

 as-is와 to-be의 동기화를 한다면 보통은 OGG나 Data Guard를 사용할 수 있겠지만 라이센스 비용이 비싸기 때문에 중소형 규모의 DB에는 적용을 못하는 실정이다.

 동기화는 하고 싶은데 데이터의 양이 적고 라이센스 비용이 부담되는 경우가 많을 것으로 예상된다. 그리하여 고안해낸 방법이되겠다.

 

 이 글의 목적은 Active Data Guard나 Oracle Golden Gated와 같은 솔루션을 사용하지 않고 AS-IS 특정 Table에 대해 TO-BE에서도 동일하게 sync를 맞추는 것이다.

PLAN

 AS-IS 특정 table에 대하여 TO-BE쪽에 DB link를 사용하여 MView를 생성한다. 사용자가 원할 때에 AS-IS와 TO-BE의 테이블 데이터 동기화를 한다.

STEP

 먼저 시작하기에 앞서 지난번에 포스팅 되었던 MView에 대한 간략한 소개와 Syntax를 먼저 보고 시작하는게 조금이나마 도움이 될 것이다.

> MVIEW란? MVIEW INTRO / SYNTAX

STEP 1. TO-BE에서 DB LINK 생성

 TO-BE 쪽에서 AS-IS의 데이터를 읽어 오기 위하여 DB LINK를 생성한다. 우선 tnsnames.ora 파일을 설정해줘야하며 그 이후 tnsnames.ora의 alias명을 가지고 DB LINK를 생성한다.

-- in TO-BE

- DB LINK 생성을 위한 TNS설정

 - Database link 생성

 SQL> create database link source_link connect to scott identified by tiger using 'mtest';    Database link created.

- Database link 확인

STEP 2. AS-IS 특정 Table에 대하여 Materialized Log 생성

-- in AS-IS

 Materialized Log는 적용한 Table에 대해 수정이 발생할 경우 이를 Log로 남기는 역할을 한다. 즉, 변경분에 대한 refresh 옵션인 FAST 옵션을 사용하려면 Materialized Log를 생성해야한다. 생성하지 않을 경우 FAST 옵션을 사용할 수 없다.

SQL> create materialized view log on emp;       ## emp table에 대한 mview log를 달겠다.

mview log를 생성하면 아래와 같이 MLOG$_[TABLE명], RUPD$_[TABLE명]이 생성 된다.

생성 후 해당 테이블을 select하면 아무 data도 존재하지 않는다.

STEP 3. TO-BE에 DB LINK를 이용하여 Materialized View 생성

-- in TO-BE

SQL> create materialized view mv_emp

        build immediate                ## 생성과 동시에 data 생성하겠다

        refresh on demand fast    ## dbms_view를 통한 refresh를 진행, 변경분만 refresh

        as select * from emp@source_link;

STEP 4. 동기화(Sync)

-- in AS-IS

SQL> select * from emp;                                   ## emp table 조회

SQL> select * from mlog$_emp;                         ## emp mlog 조회

SQL> delete from emp where empno=1111;        ## emp table 변경 발생      

SQL> commit;                                                          

SQL> select * from mlog$_emp;                         ## emp mlog 조회(변경분에 대한 Data)

-- in TO-BE

SQL> select * from mv_emp;                                   ## refresh 전 emp 조회

SQL> exec dbms_mview.refresh('MV_EMP','C');          ## complet 옵션으로 refresh

SQL> select * from mv_emp;                                   ## refresh 후 emp 조회

-- AS-IS

SQL> select * from mlog$_emp;

no rows selected

 TO-BE 쪽의 mview가 refresh 되면서 mlog의 변경사항이 TO-BE mview에 적용됨 -> 즉, 동기화가 됐기 때문에 as-is의 emp table과 to-be의 mv_emp mview가 같다는 것 -> 두 오브젝트간 변경분이 없다는 말과 같음.

ETC...

Etc 1.

  아래와 같이 emp 테이블에 대해 변경을 준 뒤 log 테이블을 확인해보면 EMPNO 컬럼을 볼 수 있다. 이것은 mlog 자체가 소스 테이블의 pk를 기준으로 log를 남기기 때문이다. 반대로 생각해보면 소스 테이블에 pk가 존재하지 않는다면 mlog를 사용할 수 없다.

Etc 2.

 Materialized view는 옵션을 잘 사용해야 한다. 위에서 잠깐 언급했지만 아래 사용한 변경분에 대한 refresh 옵션은 fast를 사용한다. 소스 테이블에 대해 Log가 남지 않으면 변경분에 대한 기록을 할 수 없고 변경에 대한 기록이 없기 때문에 FAST 옵션을 사용할 수 없다. 어쩌면 당연한 이야기이다.

-- in AS-IS

-- in TO-BE

Etc 3.

 이렇게 귀찮은 절차 필요없이 그냥 complet 옵션을 쓰면 되지 않을까? 라는 의문이 있을 수도 있다. 테스트한 테이블이 작기 때문에 문제없이 진행됐지만... 몇억, 몇십억건의 row를 갖은 테이블이라 했을때... 매초마다 refresh가 가능할까?