게시 데이터베이스의 스키마 변경
적용 대상: 
SQL Server Azure SQL Managed Instance
복제는 게시된 개체에 대한 광범위한 스키마 변경을 지원합니다. Microsoft SQL Server 게시자에 게시된 개체에 대해 다음 스키마 변경을 수행하면 기본적으로 모든 SQL Server 구독자에 변경 내용이 전파됩니다.
ALTER TABLE
스키마 변경 복제를 사용하도록 설정하고 토폴로지에서 SQL Server 2005(9.x) 또는 SQL Server Compact 3.5 구독자를 포함하는 경우 ALTER TABLE SET LOCK ESCALATION을 사용하면 안 됩니다.
ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
데이터 정의 언어 [DDL] 트리거는 복제할 수 없으므로 ALTER TRIGGER는 데이터 조작 언어 [DML] 트리거에만 사용할 수 있습니다.
Important
테이블에 대한 스키마 변경은 Transact-SQL 또는 SMO(SQL Server 관리 개체)를 사용하여 수행해야 합니다. SQL Server Management Studio에서 스키마를 변경하면 Management Studio에서는 해당 테이블을 삭제하고 다시 만들려고 합니다. 게시된 개체를 삭제할 수 없으므로 스키마가 변경되지 않습니다.
트랜잭션 복제 및 병합 복제의 경우 배포 에이전트 또는 병합 에이전트를 실행할 때 스키마 변경 내용이 증분 방식으로 전파됩니다. 스냅샷 복제의 경우 새 스냅샷이 구독자에 적용될 때 스키마 변경 내용이 전파됩니다. 스냅샷 복제에서 스키마의 새 복사본은 동기화가 발생할 때마다 구독자로 전달됩니다. 그러므로 이전에 게시된 개체에 대한 모든 스키마 변경(위에서 나열한 것 이외의 스키마 변경도 포함)이 동기화를 수행할 때마다 자동으로 전파됩니다.
게시에서 아티클을 추가 및 제거하는 방법에 대한 자세한 내용은 기존 게시에 대한 아티클 추가 및 삭제를 참조하세요.
스키마 변경을 복제하려면
위에 나열된 스키마 변경 내용은 기본적으로 복제됩니다. 스키마 변경 내용 복제를 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 스키마 변경 내용 복제를 참조하세요.
스키마 변경에 대한 고려 사항
스키마 변경 복제 시 다음 사항을 고려하십시오.
일반적인 고려 사항
스키마 변경은 Transact-SQL에서 부과한 모든 제한 사항이 적용됩니다. 예를 들어 ALTER TABLE에서는 기본 키 열을 ALTER할 수 없습니다.
데이터 형식 매핑은 초기 스냅샷에 대해서만 수행됩니다. 스키마 변경은 이전 버전의 데이터 형식에 매핑되지 않습니다. 예를 들어 SQL Server 2012(11.x)에서
ALTER TABLE ADD datetime2 column문을 사용하는 경우 데이터 형식은 SQL Server 2005(9.x) 구독자의 경우 nvarchar로 변환되지 않습니다. 게시자에서 스키마 변경이 차단되는 경우도 있습니다.게시가 스키마 변경의 전파를 허용하도록 설정된 경우 게시의 아티클에 관련 스키마 옵션을 설정한 방식에 관계없이 스키마 변경 내용이 전파됩니다. 예를 들어, 테이블 아티클에 대한 외래 키 제약 조건을 복제하지 않도록 선택했지만, 게시자에서 테이블에 외래 키를 추가하는 ALTER TABLE 명령을 실행하면, 해당 외래 키는 구독자의 테이블에 추가됩니다. 이를 방지하려면 ALTER TABLE 명령을 실행하기 전에 스키마 변경 전파를 해제합니다.
스키마 변경은 구독자(재게시 구독자 포함)가 아닌 게시자에서만 수행해야 합니다. 병합 복제에서는 구독자에서 스키마를 변경할 수 없습니다. 트랜잭션 복제는 변경 내용을 방지하지 않지만 변경으로 인해 복제가 실패할 수 있습니다.
재게시 구독자로 전파된 변경 내용은 기본적으로 해당 구독자로 전파됩니다.
스키마 변경이 게시자에는 존재하지만 구독자에는 존재하지 않는 개체나 제약 조건을 참조하는 경우, 스키마 변경은 게시자에서는 성공하지만 구독자에서는 실패합니다.
외래 키를 추가할 때 참조되는 구독자의 모든 개체에는 게시자의 해당 개체와 동일한 이름과 소유자가 있어야 합니다.
명시적으로 인덱스를 추가, 삭제 또는 변경하는 작업은 복제되지 않으며 명시적 인덱스를 포함하는 모든 변경 내용은 개별적으로 각 복제본 집합에서 실행해야 합니다. 제약 조건(예: 기본 키 제약 조건)에 대해 암시적으로 만든 인덱스가 지원됩니다.
복제로 관리되는 ID 열 변경 또는 삭제는 지원되지 않습니다. ID 열 자동 관리에 대한 자세한 내용은 ID 열 복제를 참조하세요.
비결정 함수를 포함하는 스키마 변경은 게시자와 구독자의 데이터가 다를 수 있기 때문에 지원되지 않습니다(불일치라고 함). 예를 들어 게시자
ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE()에서 다음 명령을 실행하면 명령이 구독자에 복제되고 실행될 때 값이 다릅니다. 비결정 함수에 대한 자세한 내용은 결정적 함수 및 비결정적 함수를 참조하세요.제약 조건의 이름을 명시적으로 지정하는 것이 좋습니다. 제약 조건에 명시적으로 이름을 지정하지 않으면, SQL Server는 제약 조건의 이름을 생성하며, 이 이름은 게시자와 각 구독자에서 다릅니다. 이로 인해 스키마 변경 복제 시 문제가 발생할 수 있습니다. 예를 들어 게시자에서 열을 삭제하고 종속 제약 조건이 삭제되면 복제가 구독자에서 제약 조건을 삭제하려고 시도합니다. 제약 조건의 이름이 다르므로 구독자에서 삭제가 실패합니다. 제약 조건 명명 문제 때문에 동기화가 실패할 경우 수동으로 구독자에서 제약 조건을 삭제하고 병합 에이전트를 다시 실행합니다.
테이블이 복제를 위해 게시된 경우, 게시 스냅샷이 이미 생성되었다면 해당 테이블의 열을 XML 데이터 유형으로 변경할 수 없습니다. 열을 변경하려면 먼저 복제를 제거해야 합니다.
커밋되지 않은 읽기는 게시된 테이블에서 DDL을 수행할 때 지원되는 격리 수준이 아닙니다.
SET CONTEXT_INFO 는 게시된 개체에 대해 스키마 변경 내용이 수행된 트랜잭션 컨텍스트 수정에 사용할 수 없습니다.
열 추가
테이블에 새 열을 추가한 후 이 열을 기존 게시에 포함하려면 ALTER TABLE <Table> ADD <Column>을 실행합니다. 기본적으로 이 열은 모든 구독자로 복제됩니다. 열은 NULL 값을 허용하거나 기본 제약 조건을 포함해야 합니다. 열 추가에 대한 자세한 내용은 이 항목의 "병합 복제" 섹션을 참조하세요.
테이블에 새 열을 추가한 후 이 열을 기존 게시에 포함하지 않으려면 스키마 변경 내용의 복제를 사용하지 않도록 설정하고 ALTER TABLE <Table> ADD <Column>을 실행합니다.
기존 게시에 기존 열을 포함하려면 sp_articlecolumn(Transact-SQL), sp_mergearticlecolumn(Transact-SQL) 또는 게시 속성 - <게시> 대화 상자를 사용합니다.
자세한 내용은 열 필터 정의 및 수정을 참조하세요. 이렇게 하려면 구독을 다시 초기화해야 합니다.
열이 구독자로 복제될 때 데이터가 일치하지 않을 수 있기 때문에 게시 테이블에는 ID 열을 추가할 수 없습니다. 게시자의 ID 열 값은 영향을 받는 테이블 행이 실제로 저장된 순서에 따라 달라집니다. 구독자에는 행이 다르게 저장될 수 있으므로 ID 열의 값이 동일한 행에 대해 다를 수 있습니다.
열 삭제
기존 게시에서 열을 삭제하고 게시자의 테이블에서 열을 삭제하려면 ALTER TABLE <Table> DROP <Column>을 실행합니다. 기본적으로 해당 열이 모든 구독자의 테이블에서 삭제됩니다.
열을 기존 게시에서는 삭제하지만 게시자의 테이블에서는 유지하려면 sp_articlecolumn(Transact-SQL), sp_mergearticlecolumn(Transact-SQL) 또는 게시 속성 - <게시> 대화 상자를 사용합니다.
자세한 내용은 열 필터 정의 및 수정을 참조하세요. 이렇게 하려면 새 스냅샷을 생성해야 합니다.
삭제할 열은 데이터베이스에 있는 게시 아티클의 필터 절에서 사용할 수 없습니다.
게시된 아티클에서 열을 삭제하면 데이터베이스에 영향을 줄 수 있는 열의 제약 조건, 인덱스 또는 속성을 고려합니다. 예시:
트랜잭션 게시 아티클에서 기본 키에 사용되는 열은 복제에 사용되므로 삭제할 수 없습니다.
복제에 사용되므로 병합 게시의 아티클의 rowguid 열 또는 구독 업데이트를 지원하는 트랜잭션 게시의 아티클에서 mstran_repl_version 열을 삭제할 수 없습니다.
인덱스 변경 사항은 구독자에게 전파되지 않습니다: 게시자에서 열을 삭제하고 종속된 인덱스가 삭제된 경우, 인덱스 삭제는 복제되지 않습니다. 게시자에서 열을 삭제하기 전에 구독자에서 인덱스를 삭제해야 열이 게시자에서 구독자로 복제될 때 열 삭제가 성공합니다. 구독자의 인덱스 때문에 동기화가 실패할 경우 수동으로 인덱스를 삭제하고 병합 에이전트를 다시 실행하십시오.
삭제할 수 있도록 제약 조건의 이름을 명시적으로 지정해야 합니다. 자세한 내용은 이 항목의 앞부분에 있는 “일반적인 고려 사항” 섹션을 참조하세요.
트랜잭션 복제
스키마 변경은 이전 버전의 SQL Server를 실행하는 구독자에게 전파되지만 DDL 문에는 구독자의 버전에서 지원하는 구문만 포함되어야 합니다.
구독자에서 데이터를 다시 게시하면 열을 추가 및 삭제하는 스키마 변경만 지원됩니다. 이러한 변경은 ALTER TABLE DDL 구문 대신 sp_repladdcolumn(Transact-SQL) 및 sp_repldropcolumn(Transact-SQL)을 사용하여 게시자에서 수행해야 합니다.
스키마 변경은 SQL Server 이외 구독자에게 복제되지 않습니다.
스키마 번경은 SQL Server 이외 게시자로부터 전파되지 않습니다.
테이블로 복제되는 인덱싱된 뷰는 변경할 수 없습니다. 인덱싱된 뷰로 복제된 인덱싱된 뷰는 변경할 수 있지만 이를 변경하면 인덱싱된 뷰가 아닌 일반 보기가 됩니다.
게시에서 즉시 업데이트 구독 또는 지연 업데이트 구독을 지원하면 스키마를 변경하기 전에 시스템을 정지해야 합니다. 즉, 게시된 테이블에 대한 모든 작업을 게시자와 구독자에서 중지하고 보류 중인 데이터 변경 내용을 모든 노드에 전파해야 합니다. 스키마 변경을 모든 노드로 전파하면 게시된 테이블에 대한 작업을 재개할 수 있습니다.
게시가 피어 투 피어 토폴로지에 있는 경우 스키마 변경 전에 시스템을 정지해야 합니다. 자세한 내용은 복제 토폴로지 정지(복제 Transact-SQL 프로그래밍)를 참조하세요.
테이블에 타임스탬프 열을 추가하고 이 타임스탬프를 binary(8)로 매핑하면 아티클이 모든 활성 구독에 대해 다시 초기화됩니다.
병합 복제
병합 복제에서 스키마 변경을 처리하는 방법은 게시 호환성 수준과 스냅샷이 기본 모드(기본값) 또는 문자 모드로 설정되어 있는지 여부로 결정됩니다.
스키마 변경 내용을 복제하려면 게시의 호환성 수준이 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)를 참조하세요.