적용 대상:
SQL ServerAzure SQL Managed Instance
복제는 게시된 개체에 대한 광범위한 스키마 변경을 지원합니다. Microsoft SQL Server 게시자에 게시된 개체에 대해 다음 스키마 변경을 수행하면 기본적으로 모든 SQL Server 구독자에 변경 내용이 전파됩니다.
ALTER TABLE
ALTER TABLE SET LOCK ESCALATION스키마 변경 복제가 활성화되어 있고 토폴로지에 SQL Server 2005 (9.x) 또는 SQL Server Compact 3.5 Subscribers가 포함되어 있다면 사용하지 않아야 합니다.ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGER데이터 정의 언어(DDL) 트리거는 복제할 수 없기 때문에 데이터 조작 언어(DML) 트리거에만 사용할 수 있습니다.
중요
테이블에 스키마 변경은 Transact-SQL 또는 SQL Server 관리 객체(SMO)를 사용해야 합니다. SQL Server Management Studio에서 스키마를 변경하면, Management Studio가 테이블을 삭제하고 다시 생성하려고 시도합니다. 게시된 객체를 드롭할 수 없기 때문에 스키마 변경이 실패합니다.
트랜잭션 복제 및 병합 복제의 경우 배포 에이전트 또는 병합 에이전트를 실행할 때 스키마 변경 내용이 증분 방식으로 전파됩니다. 스냅샷 복제의 경우 새 스냅샷이 구독자에 적용될 때 스키마 변경 내용이 전파됩니다. 스냅샷 복제에서 스키마의 새 복사본은 동기화가 발생할 때마다 구독자로 전달됩니다. 따라서 이전에 게시된 객체에 대한 모든 스키마 변경(앞서 나열된 것뿐만 아니라)은 각 동기화마다 자동으로 전파됩니다.
게시에서 아티클을 추가 및 제거하는 방법에 대한 자세한 내용은 기존 게시에 대한 아티클 추가 및 삭제를 참조하세요.
스키마 변경을 복제하려면
앞서 언급한 스키마 변경은 기본적으로 복제됩니다. 스키마 변경 내용 복제를 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 스키마 변경 내용 복제를 참조하세요.
스키마 변경 시 고려해야 할 사항
스키마 변경 복제 시 다음 사항을 고려하십시오.
일반적인 고려 사항
스키마 변경은 Transact-SQL에서 부과한 모든 제한 사항이 적용됩니다. 예를 들어,
ALTER TABLE기본 키 열을 변경할 수 없습니다.데이터 타입 매핑은 초기 스냅샷에서만 수행됩니다. 스키마 변경은 이전 버전의 데이터 타입에 매핑되지 않습니다. 예를 들어, SQL Server 2012(11.x)에서 사용할
ALTER TABLE ADD datetime2 column경우, SQL Server 2005 (9.x) 구독자에게는 데이터 타입이 nvarchar로 변환되지 않습니다. 게시자에서 스키마 변경이 차단되는 경우도 있습니다.출판물을 스키마 변경 전파를 허용하도록 설정하면, 관련 스키마 옵션을 어떻게 설정하든 출판물 변경이 전파됩니다. 예를 들어 테이블 아티클에 대한 외래 키 제약 조건을 복제하지 않고 Publisher 테이블에 외래 키를 추가하는 명령을 실행
ALTER TABLE하면 외래 키가 구독자의 테이블에 추가됩니다. 이 현상을 방지하기 위해 명령을 발행하기 전에 스키마 변경 전파를 비활성화하세요ALTER TABLE.스키마 변경은 Publisher에서만 수행하고, Subscribers(재게시 Subscribers 포함)에서는 수행하지 마세요. 병합 복제는 구독자에서 스키마 변경을 허용하지 않습니다. 트랜잭션 복제가 변경 사항을 막지는 못하지만, 변경 사항이 복제 실패를 초래할 수 있습니다.
재게시 구독자로 전파된 변경 내용은 기본적으로 해당 구독자로 전파됩니다.
스키마 변경이 Publisher에 존재하지만 Subscriber에는 없는 객체나 제약 조건을 참조한다면, Publisher에서는 성공하지만 Subscriber에서는 실패합니다.
외부 키를 추가할 때 참조하는 Subscriber 내 모든 객체는 Publisher의 해당 객체와 동일한 이름과 소유자를 가져야 합니다.
명시적으로 인덱스를 추가하거나 삭제하거나 변경하는 것은 복제되지 않습니다. 각 복제본 세트에 명시적 인덱스가 포함된 변경 사항은 개별적으로 실행해야 합니다. 제약 조건(예: 기본 키 제약 조건)에 대해 암시적으로 만든 인덱스가 지원됩니다.
복제가 관리하는 아이덴티티 컬럼을 변경하거나 삭제하는 것은 지원되지 않습니다. ID 열 자동 관리에 대한 자세한 내용은 ID 열 복제를 참조하세요.
비결정적 함수를 포함하는 스키마 변경은 지원되지 않는데, 이는 Publisher와 Subscriber의 데이터가 다를 수 있기 때문입니다(비수렴이라고 합니다). 예를 들어 게시자
ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE()에서 다음 명령을 실행하면 명령이 구독자에 복제되고 실행될 때 값이 다릅니다. 비결정 함수에 대한 자세한 내용은 결정적 함수 및 비결정적 함수를 참조하세요.이름 제약 조건을 명시적으로 지정하세요. 제약 조건을 명시적으로 지정하지 않으면, SQL Server가 그 제약 조건에 대해 이름을 생성하며, 이 이름들은 Publisher와 각 Subscriber마다 다릅니다. 이 차이는 스키마 변경 복제 시 문제를 일으킬 수 있습니다. 예를 들어, Publisher에서 열을 드롭하고 종속 제약 조건이 삭제되면, 복제는 Subscriber에서 그 제약을 드롭하려고 시도합니다. 구독자 측에서 삭제 작업이 실패하는 이유는 제약 조건의 이름이 서로 다르기 때문입니다. 제약 조건 명명 문제 때문에 동기화가 실패할 경우 수동으로 구독자에서 제약 조건을 삭제하고 병합 에이전트를 다시 실행합니다.
복제용 테이블을 게시하면, 이미 출판 스냅샷을 생성한 경우 그 테이블의 열을 XML 데이터 타입으로 변경할 수 없습니다. 열을 변경하려면 먼저 복제를 제거해야 합니다.
게시된 테이블에서 DDL을 수행할 때 Read uncommitted는 지원되는 격리 수준이 아닙니다.
게시된 객체에 대해 스키마 변경이 이루어지는 트랜잭션의 컨텍스트를 수정하는 데 사용하지 SET CONTEXT_INFO 마세요.
열 추가하기
테이블에 새 열을 추가하고 해당 열을 기존 게시에 포함하려면
ALTER TABLE <Table> ADD <Column>을(를) 실행합니다. 기본적으로 이 열은 모든 구독자로 복제됩니다. 열은NULL값을 허용하거나 기본 제약 조건을 포함해야 합니다. 열을 추가하는 방법에 대한 자세한 내용은 이 문서의 "복제 병합" 섹션을 참조하세요.테이블에 새 열을 추가하고 기존 출판물에 해당 열을 포함하지 않으려면, 스키마 변경 복제를 비활성화한 후
ALTER TABLE <Table> ADD <Column>.기존 게시에 기존 열을 포함하려면 sp_articlecolumn(Transact-SQL), sp_mergearticlecolumn(Transact-SQL) 또는 게시 속성 - <게시> 대화 상자를 사용합니다.
자세한 내용은 열 필터 정의 및 수정을 참조하세요. 이 작업을 하려면 구독을 재초기화해야 합니다.
게시된 테이블에 정체성 열을 추가하는 것은 지원되지 않는데, 이는 해당 열이 구독자에게 복제될 때 수렴하지 않을 수 있기 때문입니다. 게시자의 ID 열 값은 영향을 받는 테이블 행이 실제로 저장된 순서에 따라 달라집니다. 구독자에는 행이 다르게 저장될 수 있으므로 ID 열의 값이 동일한 행에 대해 다를 수 있습니다.
기둥 삭제
기존 게시에서 열을 삭제하고 게시자의 테이블에서도 해당 열을 삭제하려면
ALTER TABLE <Table> DROP <Column>를 실행합니다. 기본적으로 해당 열이 모든 구독자의 테이블에서 삭제됩니다.열을 기존 게시에서는 삭제하지만 게시자의 테이블에서는 유지하려면 sp_articlecolumn(Transact-SQL), sp_mergearticlecolumn(Transact-SQL) 또는 게시 속성 - <게시> 대화 상자를 사용합니다.
자세한 내용은 열 필터 정의 및 수정을 참조하세요. 이 작업을 하려면 새로운 스냅샷을 생성해야 합니다.
데이터베이스 내 어떤 출판물의 어떤 기사든 필터 절을 넣기 위해 이 열을 사용할 수 없습니다.
출판된 기사에서 열을 삭제할 때, 데이터베이스에 영향을 줄 수 있는 열의 제약 조건, 인덱스 또는 속성을 고려하세요. 예시:
트랜잭션 게시의 아티클에서 기본 키에 사용되는 열은 복제에서 사용되므로 삭제할 수 없습니다.
복제에서 해당 열을 사용하므로 병합 게시의 아티클에서는
mstran_repl_version열을 삭제할 수 없고, 업데이트 구독을 지원하는 트랜잭션 게시의 아티클에서는rowguid열을 삭제할 수 없습니다.인덱스 변경은 구독자에게 전달되지 않습니다. 만약 Publisher에서 열을 드롭하고 종속 인덱스가 삭제되면, 그 인덱스 드롭은 복제되지 않습니다. 게시자에서 열을 삭제하기 전에 구독자에서 인덱스를 삭제해야, 해당 열이 게시자에서 구독자로 복제될 때 열 삭제 작업이 성공적으로 수행됩니다. 구독자의 인덱스 때문에 동기화가 실패할 경우 수동으로 인덱스를 삭제하고 병합 에이전트를 다시 실행하십시오.
제약 조건을 명시적으로 지정해서 삭제할 수 있게 하세요. 자세한 내용은 이 글 앞부분의 "일반 고려사항" 섹션을 참조하세요.
트랜잭션 복제
스키마 변경은 이전 버전의 SQL Server를 실행하는 구독자에게 전파되지만 DDL 문에는 구독자의 버전에서 지원하는 구문만 포함되어야 합니다.
구독자에서 데이터를 다시 게시하면 열을 추가 및 삭제하는 스키마 변경만 지원됩니다. 이러한 변경 작업은
ALTER TABLEDDL 구문 대신 sp_repladdcolumn (Transact-SQL) 및 sp_repldropcolumn (Transact-SQL)을 사용하여 게시자에서 수행합니다.스키마 변경은 비SQL Server 구독자에게는 복제되지 않습니다.
스키마 변경은 비SQL Server 퍼블리셔로부터 전파되지 않습니다.
테이블로 복제된 인덱스 뷰는 변경할 수 없습니다. 인덱싱된 뷰를 복제한 경우 변경할 수 있지만, 이를 변경하면 인덱스 뷰가 아닌 일반 뷰가 됩니다.
출판물이 즉시 업데이트 또는 대기열에 저장된 업데이트 구독을 지원한다면, 스키마 변경 전에 시스템을 정지시켜: Publisher와 Subscribers에서 게시된 테이블의 모든 활동을 중단하고, 대기 중인 데이터 변경 사항을 모든 노드에 전파하세요. 스키마 변경이 모든 노드에 전파되면 게시된 테이블에서 활동이 재개될 수 있습니다.
출판물이 피어 투 피어 토폴로지라면, 스키마 변경을 하기 전에 시스템을 정지시켜야 합니다. 자세한 내용은 복제 토폴로지 정지(복제 Transact-SQL 프로그래밍)를 참조하세요.
테이블에 타임스탬프 열을 추가하고 타임스탬프를
binary(8)에 매핑하면 모든 활성 구독의 아티클이 다시 초기화됩니다.
병합 복제
머지(merge) 복제가 스키마 변경을 처리하는 방식은 출판 호환성 수준과 스냅샷이 네이티브 모드(기본값)로 설정되어 있는지, 아니면 문자 모드로 설정되어 있는지에 따라 달라집니다:
스키마 변경을 복제하려면 출판 호환성 수준을 최소 90RTM으로 설정하세요. 구독자가 이전 버전의 SQL Server을 사용하거나 호환성 수준이 90RTM 미만인 경우, sp_repladdcolumn(Transact-SQL)와 sp_repldropcolumn(Transact-SQL)를 사용해 열을 추가하거나 삭제하세요. 그러나 이러한 절차는 더 이상 사용되지 않습니다.
SQL Server 2008(10.0.x)에서 도입된 데이터 형식의 열을 기존 아티클에 추가하려는 경우 SQL Server는 다음과 같이 동작합니다.
100RTM, 기본 스냅샷 100RTM, 문자 스냅샷 기타 모든 호환성 수준 hierarchyid 변경 허용 변경 차단 변경 차단 geography 및 geometry 변경 허용 변경 허용* 변경 차단 filestream 변경 허용 변경 차단 변경 차단 date, time, datetime2 맟 datetimeoffset 변경 허용 변경 허용* 변경 차단 *SQL Server Compact 구독자는 이러한 데이터 형식을 구독자 측에서 변환합니다.
스키마 변경을 적용할 때 오류(예: 구독자에서 사용할 수 없는 테이블을 참조하는 외래 키를 추가할 때 발생하는 오류)가 발생하면 동기화가 실패하므로 구독을 다시 초기화해야 합니다.
조인 필터 또는 매개 변수가 있는 필터와 관련된 열에서 스키마 변경이 이루어진 경우 모든 구독을 다시 초기화하고 스냅샷을 다시 생성해야 합니다.
병합 복제는 문제 해결 중에 스키마 변경을 건너뛰는 저장 프로시저를 제공합니다. 자세한 내용은 sp_markpendingschemachange(Transact-SQL) 및 sp_enumeratependingschemachanges(Transact-SQL)를 참조하세요.