트랜잭션 복제를 위한 업데이트 가능 구독Updatable Subscriptions - For Transactional Replication

이 항목은 다음에 적용됩니다.예SQL Server(2008부터)아니요Azure SQL Database아니요Azure SQL Data Warehouse 아니요병렬 데이터 웨어하우스 THIS TOPIC APPLIES TO:yesSQL Server (starting with 2008)noAzure SQL DatabasenoAzure SQL Data Warehouse noParallel Data Warehouse

참고

이 기능은 SQL ServerSQL Server 2012부터 2016 버전에서 계속 지원됩니다.This feature remains supported in versions of SQL ServerSQL Server from 2012 through 2016. Microsoft SQL Server의 이후 버전에서는 이 기능이 제거됩니다.This feature will be removed in a future version of Microsoft SQL Server. 새 개발 작업에서는 이 기능을 사용하지 않도록 하고, 현재 이 기능을 사용하는 응용 프로그램은 수정하세요.Avoid using this feature in new development work, and plan to modify applications that currently use this feature.

트랜잭션 복제에서는 업데이트할 수 있는 구독과 피어 투 피어 복제를 통해 구독자에서 업데이트를 수행할 수 있습니다.Transactional replication supports updates at Subscribers through updatable subscriptions and peer-to-peer replication. 업데이트할 수 있는 구독에는 다음 두 가지 유형이 있습니다.The following are the two types of updatable subscriptions:

  • 즉시 업데이트.Immediate updating. 구독자에서 데이터를 업데이트하려면 게시자와 구독자를 연결해야 합니다.The Publisher and Subscriber must be connected to update data at the Subscriber.

  • 지연 업데이트. 구독자에서 데이터를 업데이트하기 위해 게시자와 구독자를 연결할 필요가 없습니다.Queued updating The Publisher and Subscriber do not have to be connected to update data at the Subscriber. 구독자나 게시자가 오프라인 상태일 때도 업데이트할 수 있습니다.Updates can be made while the Subscriber or Publisher is offline.

    구독자에서 데이터를 업데이트하면 이 데이터는 먼저 게시자로 전파된 다음 다른 구독자로 전파됩니다.When data is updated at a Subscriber, it is first propagated to the Publisher and then propagated to other Subscribers. 즉시 업데이트를 사용하는 경우 변경 내용은 2단계 커밋 프로토콜을 사용하여 즉시 전파됩니다.If immediate updating is used, the changes are propagated immediately using the two-phase commit protocol. 지연 업데이트를 사용하는 경우 변경 내용은 큐에 저장됩니다. 그런 다음 네트워크 연결이 가능할 때마다 지연 트랜잭션이 게시자에서 비동기적으로 적용됩니다.If queued updating is used, the changes are stored in a queue; the queued transactions are then applied asynchronously at the Publisher whenever network connectivity is available. 업데이트한 내용은 게시자에 비동기식으로 전파되기 때문에 같은 데이터를 게시자나 다른 구독자가 업데이트할 수 있고 업데이트를 적용할 때 충돌이 발생할 수 있습니다.Because the updates are propagated asynchronously to the Publisher, the same data may have been updated by the Publisher or by another Subscriber and conflicts can occur when applying the updates. 게시를 만들 때 설정한 충돌 해결 정책에 따라 충돌을 감지하고 해결합니다.Conflicts are detected and resolved according to a conflict resolution policy that is set when creating the publication.

    새 게시 마법사에서 업데이트할 수 있는 구독이 있는 트랜잭션 게시를 만드는 경우 즉시 업데이트와 지연 업데이트를 모두 설정할 수 있습니다.If you create a transactional publication with updatable subscriptions in the New Publication Wizard, both immediate updating and queued updating are enabled. 저장 프로시저가 있는 게시를 만드는 경우 이 두 가지 옵션 중 하나 또는 둘 다를 설정할 수 있습니다.If you create a publication with stored procedures, you can enable one or both options. 게시에 대한 구독을 만드는 경우에는 사용할 업데이트 모드를 지정합니다.When you create a subscription to the publication, you specify which update mode to use. 그런 다음 필요에 따라 업데이트 모드를 전환할 수 있습니다.You can then switch between update modes if necessary. 자세한 내용은 다음에 나올 "업데이트 모드 전환" 섹션을 참조하십시오.For more information, see the following section "Switching between Update Modes".

    트랜잭션 게시에 대해 업데이트할 수 있는 구독을 설정하려면 Enable Updating Subscriptions for Transactional Publications을 참조하세요.To enable updatable subscriptions for transactional publications, Enable Updating Subscriptions for Transactional Publications

    트랜잭션 게시에 대해 업데이트할 수 있는 구독을 만들려면 트랜잭션 게시에 업데이트할 수 있는 구독 만들기(Management Studio)를 참조하세요.To create updatable subscriptions for transactional publications, see Create an Updatable Subscription to a Transactional Publication (Management Studio)

업데이트 모드 전환Switching Between Update Modes

업데이트할 수 있는 구독을 사용할 때는 구독에서 특정 업데이트 모드를 사용하도록 지정한 다음 응용 프로그램의 필요에 따라 다른 업데이트 모드로 전환할 수 있습니다.When using updatable subscriptions you can specify that a subscription should use one update mode and then switch to the other if the application requires it. 예를 들어 구독에서 즉시 업데이트를 사용하도록 지정한 다음 시스템 오류로 인해 네트워크 연결이 손실된 경우에 지연 업데이트로 전환할 수 있습니다.For example, you can specify that a subscription should use immediate updating, but switch to queued updating if a system failure results in the loss of network connectivity.

참고

복제에서는 업데이트 모드가 자동으로 전환되지 않습니다.Replication does not switch automatically between update modes. 모드를 전환하려면 SQL Server Management Studio를 통해 업데이트 모드를 설정하거나 응용 프로그램에서 sp_setreplfailovermode(Transact-SQL)를 호출해야 합니다.You must set the update mode through SQL Server Management Studio or your application must call sp_setreplfailovermode (Transact-SQL) to switch between modes.

즉시 업데이트에서 지연 업데이트로 전환하면 구독자와 게시자가 연결되고 큐 판독기 에이전트에서 큐의 보류 중인 모든 메시지를 게시자에 적용할 때까지는 즉시 업데이트로 다시 전환할 수 없습니다.If you switch from immediate updating to queued updating, you cannot switch back to immediate updating until the Subscriber and Publisher are connected and the Queue Reader Agent has applied all pending messages in the queue to the Publisher.

업데이트 모드를 전환하려면To switch between update modes

업데이트 모드를 전환하려면 이 두 업데이트 모드에 대한 게시와 구독을 설정한 다음 필요에 따라 모드를 전환합니다.To switch between updating modes, you must enable the publication and subscription for both update modes, and then switch between them if necessary. 자세한 내용은For more information, see
Switch Between Update Modes for an Updatable Transactional Subscription을 참조하세요.Switch Between Update Modes for an Updatable Transactional Subscription.

업데이트할 수 있는 구독 사용 시 고려 사항Considerations for Using Updatable Subscriptions

  • 구독 업데이트나 지연 업데이트 구독에 대해 게시를 설정한 다음에는 구독에서 게시를 사용할 필요가 없더라도 해당 옵션을 해제할 수 없습니다.After a publication is enabled for updating subscriptions or queued updating subscriptions, the option cannot be disabled for the publication (although subscriptions do not need to use it). 이 옵션을 해제하려면 해당 게시를 삭제하고 새 게시를 만들어야 합니다.To disable the option, the publication must be deleted and a new one created.

  • 데이터 재게시는 지원되지 않습니다.Republishing data is not supported.

  • 복제는 추적을 위해 msrepl_tran_version 열을 게시된 테이블에 추가합니다.Replication adds the msrepl_tran_version column to published tables for tracking purposes. 이 추가 열 때문에 모든 INSERT 문에 열 목록이 포함되어야 합니다.Because of this additional column, all INSERT statements should include a column list.

  • 구독 업데이트를 지원하는 게시의 테이블에서 스키마를 변경하려면 게시자와 구독자에서 해당 테이블에 대한 모든 작업을 중단해야 하고 보류 중인 데이터 변경 내용이 스키마를 변경하기 전에 모든 노드로 전파되어야 합니다.To make schema changes on a table in a publication that supports updating subscriptions, all activity on the table must be stopped at the Publisher and Subscribers, and pending data changes must be propagated to all nodes before making any schema changes. 이렇게 하면 처리 중인 트랜잭션이 보류 중인 스키마 변경과 충돌하지 않습니다.This ensures that outstanding transactions do not conflict with the pending schema change. 스키마 변경을 모든 노드로 전파하면 게시된 테이블에 대한 작업을 재개할 수 있습니다.After the schema changes have propagated to all nodes, activity can resume on the published tables. 자세한 내용은 복제 토폴로지 정지(복제 Transact-SQL 프로그래밍)를 참조하세요.For more information, see Quiesce a Replication Topology (Replication Transact-SQL Programming).

  • 업데이트 모드를 전환하려면 구독을 초기화한 후 큐 판독기 에이전트를 최소한 한 번은 실행해야 합니다. 큐 판독기 에이전트는 기본적으로 계속 실행됩니다.If you plan to switch between update modes, the Queue Reader Agent must run at least once after the subscription has been initialized (by default, the Queue Reader Agent runs continuously).

  • 구독자 데이터베이스가 수평으로 분할되고 파티션에 구독자에는 존재하면서 게시자에는 없는 행이 있다면 구독자는 기존 행을 업데이트할 수 없습니다.If the Subscriber database is partitioned horizontally and there are rows in the partition that exist at the Subscriber, but not at the Publisher, the Subscriber cannot update the preexisting rows. 이러한 행을 업데이트하려고 하면 오류가 발생합니다.Attempting to update these rows returns an error. 테이블에서 이 행을 삭제한 다음 게시자에서 추가해야 합니다.The rows should be deleted from the table and then added at the Publisher.

  • 고유하게 필터링된 인덱스를 사용하면 지연 업데이트 구독자로 인해 트랜잭션 복제 성능이 저하될 수 있습니다.Transactional replication with Queued updateable subscribers could experience slow performance when unique filtered indexes are used. 고유하게 필터링된 인덱스가 있는 아티클에 충돌이 발생한 경우 충돌을 해결하면 구독자에서 고유하게 필터링된 인덱스가 적용되지 않은 행에 대한 추가 삭제 및 삽입이 발생합니다.If a conflict occurs on an article that has unique filtered indexes then conflict resolution would lead to additional deletes and inserts on the subscriber for the rows that are not covered by the unique filtered index.

구독자에서의 업데이트Updates at the Subscriber

  • 구독자에서의 업데이트는 구독이 만료되었거나 비활성화 상태에 있더라도 게시자로 전파됩니다.Updates at the Subscriber are propagated to the Publisher even if a subscription is expired or is inactive. 이러한 구독은 삭제하거나 다시 초기화하십시오.Ensure that any such subscriptions are either dropped or reinitialized.

  • TIMESTAMP 또는 IDENTITY 열을 사용하고 이러한 열이 자체 기본 데이터 형식으로 복제되는 경우에는 이러한 열의 값을 구독자에서 업데이트할 수 없습니다.If TIMESTAMP or IDENTITY columns are used, and they are replicated as their base data types, values in these columns should not be updated at the Subscriber.

  • 복제에 대한 변경 내용 추적 트리거 내의 삽입 테이블 또는 삭제 테이블에서는 읽기 작업을 수행할 수 없으므로 구독자는 text, ntext 또는 image 값을 업데이트하거나 삽입할 수 없습니다.Subscribers cannot update or insert text, ntext or image values because it is not possible to read from the inserted or deleted tables inside the replication change-tracking triggers. 마찬가지로 게시자가 데이터를 덮어쓰므로 구독자는 WRITETEXT 또는 UPDATETEXT 를 사용하여 text 또는 image 값을 업데이트하거나 삽입할 수 없습니다.Similarly, Subscribers cannot update or insert text or image values using WRITETEXT or UPDATETEXT because the data is overwritten by the Publisher. 대신 textimage 열을 별개의 테이블에 분할할 수 있고 트랜잭션 내에서 두 테이블을 수정할 수 있습니다.Instead, you could partition the text and image columns into a separate table and modify the two tables within a transaction.

    구독자에서 큰 개체를 업데이트하려면 text, ntextimage 데이터 형식 대신 varchar(max), nvarchar(max)varbinary(max) 데이터 형식을 사용합니다.To update large objects at a Subscriber, use the data types varchar(max), nvarchar(max), varbinary(max) instead of text, ntext, and image data types, respectively.

  • 중복을 생성하는 고유 키(기본 키 포함)에 대한 업데이트(예: UPDATE <column> SET <column> =<column>+1 형식의 업데이트)는 허용되지 않으며 고유성 위반 때문에 거부됩니다.Updates to unique keys (including primary keys) that generate duplicates (for example, an update of the form UPDATE <column> SET <column> =<column>+1 are not allowed and will be rejected because of a uniqueness violation. 이는 구독자에서의 업데이트 설정이 영향을 받는 각 행에 대한 개별 UPDATE 문으로 복제에 의해 전파되기 때문입니다.This is because set updates made at the Subscriber are propagated by replication as individual UPDATE statements for each row affected.

  • 구독자 데이터베이스가 수평으로 분할되고 파티션에 구독자에는 존재하면서 게시자에는 없는 행이 있다면 구독자는 기존 행을 업데이트할 수 없습니다.If the Subscriber database is partitioned horizontally and there are rows in the partition that exist at the Subscriber but not at the Publisher, the Subscriber cannot update the pre-existing rows. 이러한 행을 업데이트하려고 하면 오류가 발생합니다.Attempting to update these rows returns an error. 테이블에서 이 행을 삭제하고 다시 삽입해야 합니다.The rows should be deleted from the table and inserted again.

사용자 정의 트리거User-defined Triggers

  • 응용 프로그램이 구독자에 대한 트리거를 요구하는 경우에는 게시자와 구독자에서 NOT FOR REPLICATION 옵션을 사용하여 트리거를 정의해야 합니다.If the application requires triggers at the Subscriber, the triggers should be defined with the NOT FOR REPLICATION option at the Publisher and Subscriber. 이렇게 하면 원래 데이터가 변경될 때만 트리거가 발생되고 변경 내용이 복제될 때는 트리거가 발생되지 않습니다.This ensures that triggers fire only for the original data change, but not when that change is replicated.

    복제 트리거에 의해 테이블이 업데이트될 때 사용자 정의 트리거가 발생되지 않도록 합니다.Ensure that the user-defined trigger does not fire when the replication trigger updates the table. 이는 사용자 정의 트리거 본문에서 sp_check_for_sync_trigger 프로시저를 호출하여 수행할 수 있습니다.This is accomplished by calling the procedure sp_check_for_sync_trigger in the body of the user-defined trigger. 자세한 내용은 sp_check_for_sync_trigger(Transact-SQL)를 참조하세요.For more information, see sp_check_for_sync_trigger (Transact-SQL).

즉시 업데이트Immediate Updating

  • 즉시 업데이트 구독의 경우에 구독자에서의 변경 내용은 게시자로 전파되고 MS DTC(Microsoft Distributed Transaction Coordinator)를 사용하여 적용됩니다.For immediate updating subscriptions, changes at the Subscriber are propagated to the Publisher and applied using Microsoft Distributed Transaction Coordinator (MS DTC). 게시자와 구독자에 MS DTC가 설치되고 구성되어 있는지 확인하십시오.Ensure that MS DTC is installed and configured at the Publisher and Subscriber. 자세한 내용은 Windows 설명서를 참조하십시오.For more information, see the Windows documentation.

  • 변경 내용을 복제하려면 즉시 업데이트 구독에 사용되는 트리거를 게시자에 연결해야 합니다.The triggers used by immediate updating subscriptions require a connection to the Publisher to replicate changes.

  • 게시에서 즉시 업데이트 구독을 허용하고 게시의 아티클에 열 필터가 있는 경우에는 기본값이 없고 Null을 허용하지 않는 열을 필터를 사용하여 제외할 수 없습니다.If the publication allows immediate updating subscriptions and an article in the publication has a column filter, you cannot filter out non-nullable columns without defaults.

지연 업데이트Queued Updating

  • 병합 게시에 포함된 테이블도 지연 업데이트 구독을 허용하는 트랜잭션 게시의 일부로 게시할 수 없습니다.Tables included in a merge publication cannot also be published as part of a transactional publication that allows queued updating subscriptions.

  • 지연 업데이트를 사용할 경우에는 기본 키가 모든 쿼리에 대해 레코드 로케이터로 사용되기 때문에 기본 키 열에 대해 업데이트를 하지 않는 것이 좋습니다.Updates made to primary key columns are not recommended when using queued updating because the primary key is used as a record locator for all queries. 충돌 해결 정책이 구독자 내용을 적용하도록 설정된 경우 기본 키는 주의해서 업데이트해야 합니다.When the conflict resolution policy is set to Subscriber Wins, updates to primary keys should be made with caution. 게시자 및 구독자 모두에서 기본 키를 업데이트하면 그 결과로 다른 기본 키를 가진 두 개의 행이 생성됩니다.If updates to the primary key are made at both the Publisher and at the Subscriber, the result will be two rows with different primary keys.

  • 데이터 형식이 SQL_VARIANT인 열의 경우: 데이터를 구독자에서 삽입하거나 업데이트하면 해당 데이터가 구독자에서 큐로 복사될 때 큐 판독기 에이전트에 의해 다음과 같은 방식으로 매핑됩니다.For columns of data type SQL_VARIANT: when data is inserted or updated at the Subscriber, it is mapped in the following way by the Queue Reader Agent when it is copied from the Subscriber to the queue:

    • BIGINT, DECIMAL, NUMERIC, MONEYSMALLMONEYNUMERIC으로 매핑됩니다.BIGINT, DECIMAL, NUMERIC, MONEY, and SMALLMONEY are mapped to NUMERIC.

    • BINARYVARBINARYVARBINARY 데이터로 매핑됩니다.BINARY and VARBINARY are mapped to VARBINARY data.

충돌 감지 및 해결Conflict Detection and Resolution

  • "구독자 내용 적용" 충돌 정책을 사용하는 경우: 기본 키 열에 대한 업데이트에 대해서는 충돌 해결이 지원되지 않습니다.For the Subscriber Wins conflict policy: conflict resolution is not supported for updates to primary key columns.

  • FOREIGN KEY 제약 조건 오류로 인한 충돌은 복제로 해결되지 않습니다.Conflicts due to foreign key constraint failures are not resolved by replication:

    • 충돌이 예상되지 않고 데이터가 제대로 분할된 경우(구독자가 같은 행을 업데이트하지 않음)에는 게시자와 구독자에서 FOREIGN KEY 제약 조건을 사용할 수 있습니다.If conflicts are not expected and data is well partitioned (Subscribers do not update the same rows), you can use foreign key constraints on the Publisher and Subscribers.

    • 충돌이 예상되는 경우에는 "구독자 내용 적용" 충돌 해결 사용 시 게시자나 구독자에서 외래 키 제약 조건을 사용해서는 안 되며 "게시자 내용 적용" 충돌 해결 사용 시 구독자에서 외래 키 제약 조건을 사용해서는 안 됩니다.If conflicts are expected: you should not use foreign key constraints at the Publisher or Subscriber if you use "Subscriber wins" conflict resolution; you should not use foreign key constraints at the Subscriber if you use "Publisher wins" conflict resolution.

관련 항목:See Also

피어 투 피어 트랜잭션 복제 Peer-to-Peer Transactional Replication
트랜잭션 복제에 대한 게시 유형 Publication Types for Transactional Replication
데이터 및 데이터베이스 개체 게시 Publish Data and Database Objects
게시 구독 Subscribe to Publications