OGG 11.2.0.1.0 Replication Gap v1.0
|
12.07.31 |
|
|
|
|
|
|
|
|
|
|
1. Lag of OGG Replication
OGG 에서 Source 에서 Target 에 이르기까지 다음과 같은 흐름을 가진다.
a. Source
b. extract (process)
c. Source Trail
d. pump (process)
e. Network
f. Target Trail
g. Replicat (process)
h. Target
Source 의 변경이 Target 에 적용되기까지 간격(lag) 은 다음과 같이 있다.
Extract lag : Source 에 Trail 로 만들기까지의 시간 ( a ~ c )
Pump lag : Target 에 Trail 로 만들기까지의 시간 ( a ~ f )
Replicat lag “end-to-end” latency : Target 에 적용되기까지의 시간 ( a ~ h )
2. Time Gap 을 줄일 수 있는 Parameters
- EOFDELAYCSEC : Log에서 추출 전에 Extract Process가 Delay 되는 시간 설정 (1/100초)
- FLUSHCSEC : 데이터 추출 주기 및 queue 적재 주기의 제어
- GROUPTRANSOPS : 처리할 Transaction을 그룹화 처리하여 disk I/O 감소
- MAXTRANSOPS : 대량 Transaction 내 레코드를 분할하여 처리
/*+ 각 값의 default value 에 대한 질문 */
3. Test outline
a. 소스, 타겟에 테이블 생성
b. 소스에 데이터입력 + commit
c. 타겟에 데이터 복제되는 시간 측정
l 테스트 환경
- 물리적으로 동일한 하나의 컴퓨터
- host only 로 묶여 있는 두 개의 Virtual Machine
l 테스트 이전에 가정한 내용
- Extract lag 은 없을 것이다.
- Network lag 은 없을 것이다.
- Trail 에 기록하는데 지연은 발생하지 않는다.
è 결과적으로 지연이 발생하는 부분은 Replicat Process 가 변경을 Target 에 적용하기까지 걸리는 시간
4. Test #1
l set timing on ( Source & Target )
l Create Table ( Source & Target )
|
create table commit_test( id1 int primary key, id2 char(2000), id3 char(2000), id4 char(2000)); |
l Insert & Commit ( Source )
|
insert into commit_test select level + 1, dbms_random.value, dbms_random.value, dbms_random.value from dual connect by level < 30000;
commit; select systimestamp from dual; |
l 시간측정 ( Target )
|
select systimestamp,count(*) from commit_test; |
Source 의 Insert 완료까지 17.69 초가 소요되었다.
이후 commit 완료 후 systimestamp 조회값이 11:06:41 이었고,
Target 에서 Insert 된 데이터가 최초 관측 된 시간이 11:07:08 이었다.
위 두 Timestamp 로 소요 된 시간의 차는 27초이다.
이 시간간격으로 보아 Source 의 Transaction 을 트랙잭션의 성공여부를 떠나 Target 에 재현하지는 않는다란 걸 알 수 있다.
만약 Source 의 Transaction 을 Target 에 재현하고 있었다면 Source 의 commit 시점과 타겟의 commit 시점간의 시간차이는 거의 나지 않아야 한다.
5. TEST #2
l 데이터 저장용 테이블 (source & target)
|
create table commit_test( id1 int primary key, id2 char(100), id3 char(100), id4 char(100)); |
테스트 데이터 입력에 사용 될 테이블이다.
l 시간정보 저장용 테이블 (target)
|
create table commit_test_timetable(dttm varchar2(6), maxid int); |
위 테이블에는 값이 입력 된 시각과 commit_test 의 max(id1) 값을 입력한다.
l 시간정보 저장을 위한 프로시저와 스케쥴러 (target)
|
create or replace procedure commit_test_plsql as begin insert into commit_test_timetable values(to_char(systimestamp,'HH24MISS'), (select max(id1) from test.commit_test)); commit; end; /
BEGIN DBMS_SCHEDULER.create_job ( job_name => 'commit_test', job_type => 'PLSQL_BLOCK', job_action => 'BEGIN commit_test_plsql; END;', start_date => SYSTIMESTAMP, repeat_interval => 'freq=minutely; bysecond=0;', end_date => NULL, enabled => TRUE); END; / |
하단의 스케쥴러는 1분마다 commit_test_plsql 을 호출한다.
commit_test_plsql 은 commit_test 의 max(id1) 를 뽑아 commit_test_timetable 에 입력한다.
이는 변경사항이 언제 target 에 적용되었는지 확인하기 위한 조치이다.
l 데이터 Insert (source)
|
select systimestamp from dual;
declare begin for i in 1..1000 loop insert into commit_test select level + 30000 * (i - 1), dbms_random.value, dbms_random.value, dbms_random.value from dual connect by level < 30000; end loop; commit; end; / select systimestamp from dual; |
위 수행결과로 10000333 의 rows 가 입력된다.
l 수행결과
<Source>
|
SYSTIMESTAMP --------------------------------------------------------------------------- 12/08/07 15:41:06.929847 +09:00
SQL> SQL> 2 3 4 5 6 7 8 9 10 11
PL/SQL procedure successfully completed.
SQL> SYSTIMESTAMP --------------------------------------------------------------------------- 12/08/07 15:57:40.498267 +09:00 |
Procedure 의 수행에 15:41 ~ 15:57 (16m) 소요되었다.
<Target>
|
DTTM MAXID ------ ---------- 162500 162600 162700 162800 10000333 162900 10000333 |
위 내용은 commit_test_timetable 을 조회하여 일부를 발췌한 결과로 max(id1) 에 대한 값이 감지된 시점이
16:28 임을 알 수 있었다.
다시 말해 16:28 에 변경내용이 적용되었다는 것이다.
Source
15:41 ~ 15:57 (16m)
???
15:57 ~ 16:28 (31m)
Target
16:28 변경내용 적용
6. 결론
결과적으로 결과를 보아 Source 측에서 commit 한 내용이 Target 에서 바로 commit 되지 않았다.
수행시간을 보아 Source 에서 commit 된 내용이 Target 에서 다시 쿼리 실행을 밟지 않았나 추측한다.