[복제] 유니크 제약조건이 있는 게시 데이터 update시 구독에 반영하는 방식 - part2
이전에 유니크 제약조건이 있는 게시 데이터 update시 구독에 반영하는 방식에 대해 이야기 한적이 있습니다.
찾아보니 이렇게 유니크인덱스 또는 PK 컬럼이 update 되었을때 delete / insert 로 반영되는것을 "deferred update" 라고 한다는 것을 알았습니다.
- http://support.microsoft.com/kb/238254
- http://support.microsoft.com/kb/302341/EN-US/
- http://support.microsoft.com/kb/160181/EN-US/
그리고 구독의 SP를 변경하여 사용하는 경우 update 명령이 delete / insert로 변경되어 적용될 경우 문제가 될수도 있기 때문에 다음 trace flag를 통하여 어떤 방식으로 update 명령을 구독에 반영할 지 제어 할 수 있습니다.
dbcc traceon (8207)
-- delete / insert로 동작
dbcc traceon (8202)
이 중 8207 flag의 경우 다음 경우에 문제가 될 수 있으므로 주의해야 한다고 말하고 있습니다.
(여러개 row가 업데이트 되는 경우는 delete / insert로 동작함 (민석형님 감사합니다. ㅎㅎ~))
Important: Typically, you use trace flag 8207 with read-only transactional replication. Do not use trace flag 8207 with updatable subscriptions if:
(구독에서 PK가 업데이트 되는 경우)
(구독의 유니크 제약조건에 포함된 컬럼이 업데이트 되는 경우)
(구독의 유니크 인덱스에 포함된 컬럼이 업데이트 되는 경우)
이상한점은, 복제의 경우 로그를 읽어 데이터를 반영하는 방식이기 때문에 동일한 update문을 수행했더라도 유니크 제약조건에 의해 update 와 delete / insert의 경우 로그가 다르게 쌓일거라고 생각했지만 동일하게 쌓인것을 확인할 수 있었습니다.
확인은 ::fn_dblog 명령을 통해 하였고 엑셀에 붙여서 확인해본 결과 완전히 동일하게 로그가 쌓인것을 확인할 수 있었습니다.
혹시 "해당 테이블의 인덱스를 참조 하는건가?" 하는 생각이 들어 다음과 같이 데이터 변경 후 인덱스를 변경하는 방식으로 수행해 보았는데 update 구문이 실행 당시의 인덱스 상황에 의해 update 또는 delete / insert로 풀리는것을 확인할 수 있었습니다.
즉, 로그리더는 게시의 로그파일만 읽어서 배포로 넘기지 테이블의 인덱스 정보를 참조하지는 않았습니다.
create unique index ix_t1_col2 on t1 (col2)
update t1 set col2 = 3 where col2 = 4
drop index t1.ix_t1_col2
혹시 로그리더가 읽어가는 데이터에 대해 좀 더 자세히 아시거나 좀더 상세히 로그를 확인할 수 있는 방법을 알고 계신분이 계시다면 알려 주시면 감사하겠습니다. ^^
하만철 / Ha Man cheol
EMail : feisia@hanmail.net