이전에 유니크 제약조건이 있는 게시 데이터 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 명령을 구독에 반영할 지 제어 할 수 있습니다.

-- update로 동작
dbcc traceon (8207)

-- delete / insert로 동작
dbcc traceon (8202)

이 중 8207 flag의 경우 다음 경우에 문제가 될 수 있으므로 주의해야 한다고 말하고 있습니다.

From this point forward, an update to a unique column affects only one row (a singleton update) and is replicated as an UPDATE and not as a DELETE or INSERT pair. If the update affects multiple rows, the update is still replicated as a DELETE or INSERT pair.
(여러개 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:
  • A primary key update can occur at the subscriber. 
        (구독에서 PK가 업데이트 되는 경우)
  • An update to a column that is included in a unique constraint can occur at the subscriber. 
       (구독의 유니크 제약조건에 포함된 컬럼이 업데이트 되는 경우)
  • An update to a column that is included in a unique index can occur at the subscriber.
       (구독의 유니크 인덱스에 포함된 컬럼이 업데이트 되는 경우)
  • 이상한점은, 복제의 경우 로그를 읽어 데이터를 반영하는 방식이기 때문에 동일한 update문을 수행했더라도 유니크 제약조건에 의해 update 와 delete / insert의 경우 로그가 다르게 쌓일거라고 생각했지만 동일하게 쌓인것을 확인할 수 있었습니다.
    확인은 ::fn_dblog 명령을 통해 하였고 엑셀에 붙여서 확인해본 결과 완전히 동일하게 로그가 쌓인것을 확인할 수 있었습니다.



    혹시 "해당 테이블의 인덱스를 참조 하는건가?" 하는 생각이 들어 다음과 같이 데이터 변경 후 인덱스를 변경하는 방식으로 수행해 보았는데 update 구문이 실행 당시의 인덱스 상황에 의해 update 또는 delete / insert로 풀리는것을 확인할 수 있었습니다.
    즉, 로그리더는 게시의 로그파일만 읽어서 배포로 넘기지 테이블의 인덱스 정보를 참조하지는 않았습니다.

    update t1 set col2 = 4 where col2 = 3
    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

    AND