DataCloud

1. OGG 가 복제 소스 서버에서 메모리 사용하는 경우

  -- 기본적으로 복제 Source 서버의 OS Memory 를 사용하도로 설정 됨

  -- v$session 과 v$transaction 등을 모니터링 하다가, 추출 대상이 될 가능성이 있는 변경 사항을 확인하면, OS Memory 를 사용해 cache 하고 있다가, 조건이 충족되면 (예> commit 발생 등) 지정된 Trail 에도 저장

  -- BR 을 사용하지 않는 경우 (11gR2 이상 버전은 BR Enable 이 Default) OS Memory 를 더 사용하는 것 같음 => 이 부분에 대한 근거는 없음

2. 사용 메모리 제어방법 

  --  Extract 에 CACHEMGR 옵션을 사용 : OGG 11gR1 - 12cR1 까지 공통사항

  # CACHESIZE 2G 를 설정하면, 해당 Extract 는 2G 까지만 OS Memory 를 사용, 별도 Directory 를 지정하지 않아도 됨

  # 설정 된 CACHESIZE 로 부족할 경우, $OGG_HOME/dirtmp 에 기본적으로 저장, CACHEDIRECTORY 옵션으로 특정 Directory 를 지정하는 경우, 해당 Directory 에 임시 파일들을 생성 했다가 지우게 됨 ==> 따라서 어느 정도 까지 해당 Directory 의 space 가 필요할 지는 사전에 계산하기 어려움

  # 이렇게 2개 이상의 Directory 에 각각 Size 가 지정된 경우, 해당 Directory 는 지정된 size 내에서만 임시 파일을 생성, 삭제

ps. 이 내용들은 다음 URL 을 참조했습니다. https://docs.oracle.com/goldengate/1212/gg-winux/GWURF/gg_parameters017.htm#GWURF413 

1. (CDC 제품에서 일반적으로) Supplemental Logging 이 필요한 이유

   복제의 원본이 되는 "소스DB"에서 Update Query 등이 수행될 때, Update Query 등으로 실제 변경이 발생된 column 뿐 아니라, 나머지 Column 들의 정보를 함께 Archive Log 에 남기기 위해서는  Supplemental Logging 이 활성화 되어야만 합니다.

<< 해설 >>

    The EMP table has a primary key defined on the EMPID column.
    --> If supplemental logging is turned on for primary key columns, then any update to EMP logs the EMPID column.
    --> Without supplemental logging, We can find following data in redo/Archive log :      

        update "SCOTT"."EMP" set "SAL" = '150000' where "SAL" = '100000' and ROWID ='AAABOaAABAAANZ/AAA';     

    --> But, with the log group test_always defined above :     

        update "SCOTT"."EMP" set "SAL" = '150000' where "EMPID" = '10' and "SAL" ='100000' and ROWID = 'AAABOaAABAAANZ/AAA';    


2. Supplemental Logging 개요 (Level 및 방법)

   Database-Level 과 Table-Level 로 나눌 수 있습니다.
    --> Oracle Documents : http://docs.oracle.com/cd/E11882_01/server.112/e22490/logminer.htm#SUTIL1582

   일반적으로,

   Database-Level 로 설정하는 경우, 해당 DB Instance 의 모든 Table 들에 대해, 자동으로 Supplemental Logging 이 됩니다.  따라서, 기존 대비 많은 양의 Rodo log switch 가 발생되고 (Archive Log 량이 증가), log switch 에 따른 overhead 가 증가됩니다.

   Table-Level 로 설정하는 경우, 각 대상 table 들에 대해서 각각 alert 해 주어야 하는 불편함이 있지만
   Database-Level 설정 대비, overhead 가 감소되어 운영 부담이 줄어드는 장점이 있습니다.  


  2-A. Database-Level Supplemental Logging
 
    -- 최소 단위 (MIN) 으로 설정하는 방법

    -- 확인하는 방법

    -- PK/UK 정보를 추가로 남기기 위해서 설정하는 방법

    -- 확인하는 방법

  2-B. Table-Level Supplemental Logging

   Table 전체(모든 Column)를 지정하는 방법과 Table 의 특정 Column 들만 지정하는 방법이 있습니다.

   Table 전체(모든 Column)를 지정하면, 해당 table 의 모든 column 에 Supplemental Logging 이 활성화 됩니다.
   해당 table 의 column 이 추가되면, 자동으로 추가된 column 에 Supplemental Logging 이 활성화 됩니다.

   Table 의 특정 Column 들만 지정하면, 해당 table 의 지정된 column 들에 Supplemental Logging 이 활성화 됩니다.
   해당 table 의 column 이 추가되면, 추가된 column 들은 자동으로 Supplemental Logging 되지 않습니다.
   추가로 alter 를 수행하여, 새로운 column 에 Supplemental Logging 을 활성화 해야만 합니다

    -- Table 의 전체 Column 을 지정하는 방법

    -- 확인하는 방법 : 하기 참조

    -- Table 의 특정 Column 을 지정하는 방법

    -- 확인하는 방법 : 하기 참조


  2-C. Table-Level Level Supplemental Logging 설정 및 조회 방법

    -- GGSCI 에서 add trandata 수행

    -- SQL Plus 에서 add supplemental log 수행

    -- 결과 조회 (column 단위 Logging)

    -- SQL Plus 에서 모든 Column 에 대한 Logging 수행

3. OGG 제품에서 Supplemental Logging 설정 Review

  3-A. 일반적인 복제(1:1) 요건을 충족하기 위한 Logging 설정 시

   OGG 설치 단계중에서 CDC 대상 Table 에 대한 Add TranData 작업은 Table Level 의 Supplemental logging 처리이며, Log Group Name 은 기본적으로 OGG_[Table Name]_[Object ID] 가 됩니다.

   즉

   이 아니라 아래의 DDL 이 수행된 결과입니다.

   추가로, Add TranData 작업을 하기 위해서는,  Database-Level Supplemental logging 의 SUPPLEMENTAL_LOG_DATA_MIN 이 YES 이여야만 합니다.


  3-B. Historial Table 을 모든 Column 을 기준으로 남기기 위한 Logging 설정 시

   특정 Table 에 대해서 Table 의 모든 column 에 대하여 Supplemental logging 처리를 위해서 다음과 같이 수행한다.

   특정 Table 에 대해서 특정 column 에 대해서 Supplemental logging 처리를 위해서 다음과 같이 수행한다. 

   S사의 사례처럼, Historial Table 을 모든 Column 을 기준으로 남기기 위해서

   을 수행하는 경우,

   Database-Level Supplemental logging 의 SUPPLEMENTAL_LOG_DATA_MIN 이 YES 이여야만 합니다.
   Add TranData 작업은 불필요 합니다. (Add TranData 작업을 하게 되면, 중복해서 Logging 설정됨)
      
   
4. S사 환경에서, 향후(2012.01.26 이후) 복제대상으로 새로운 Table 이 추가시 절차 (간략 흐름도)

  4-A. 추가 Table 에 대한 SUPPLEMENTAL Logging

    - DBA 가 해당 table 에 대한 ALTER TABLE [Table Owner].[TABLE Name] ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS; 수행

      cf> GGSCI> add trandata owner.table 은 수행하지 않는다.

  4-B. 추가 Table 을 OGG Configuration 에 반영
 
    - 해당 extract, pump 및 replicat 에 해당 table mapping 을 반영
    - 소스서버#] defgen 으로 새로운 table layout 을 추출해, 타켓서버에 반영

  4-C. OGG 에서 복제 반영을 시작

    - (필요시 pump 및) Replicat 을 restart 하여, 복제를 반영할 준비 완료 후
    - Extract 를 restart 하여, 새로운 table 에 대한 추출을 시작

End of Documents.