Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения:
SQL Server Управляемый экземпляр SQL Azure
Репликация поддерживает широкий диапазон изменений схем для опубликованных объектов. При внесении любого из следующих изменений схемы на соответствующий опубликованный объект на издателе Microsoft SQL Server это изменение распространяется по умолчанию ко всем подписчикам SQL Server:
ALTER TABLE
ALTER TABLE SETЭСКАЛАЦИЮ БЛОКИРОВОК не следует использовать, если включена репликация изменений схемы и топология включает подписчиков SQL Server 2005 (9.x) или SQL Server Compact 3.5.
ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGER можно использовать только для триггеров языка обработки данных [DML], так как триггеры языка определения данных [DDL] не могут быть реплицированы.
Внимание
Изменения схемы в таблицах должны вноситься с помощью объектов Управления Transact-SQL или SQL Server (SMO). При внесении изменений в схему в SQL Server Management Studio программа пытается удалить и заново создать таблицу. Опубликованные объекты невозможно удалить, поэтому не удаётся изменить схему.
При репликации транзакций и репликации слиянием изменения схемы распространяются в режиме последовательных добавлений при запусках агента распространителя или агента слияния. При репликации снимков изменения схемы распространяются при применении нового снимка у подписчика. В репликации моментальных снимков при каждой синхронизации подписчику отправляется новая копия схемы. Поэтому все изменения схемы (не только перечисленные выше) в ранее опубликованных объектах автоматически распространяются при каждой синхронизации.
Дополнительные сведения о добавлении и удалении статей в существующих публикациях см. в этой статье.
Репликация изменений схемы
Перечисленные выше изменения схемы реплицируются по умолчанию. Сведения об отключении репликации изменений схемы см. в разделе Replicate Schema Changes.
Вопросы изменений схемы
При репликации изменений схемы учитывайте следующее.
Общие рекомендации
Изменения схемы подвергаются любым ограничениям, введенным Transact-SQL. Например, ALTER TABLE не позволяет изменять столбцы первичного ключа.
Сопоставление типов данных выполняется только для исходного моментального снимка. Изменения схемы не сопоставляются с предыдущими версиями типов данных. Например, если инструкция
ALTER TABLE ADD datetime2 columnиспользуется в SQL Server 2012 (11.x), тип данных не преобразуется в nvarchar для подписчиков SQL Server 2005 (9.x). В некоторых случаях изменения схемы блокируются на издателе.Если в публикации разрешено распространение изменений схемы, то изменения схемы распространяются независимо от того, как установлен соответствующий параметр схемы для статьи в публикации. Например, если вы решили не реплицировать ограничения внешнего ключа для статьи, представляющей таблицу, а затем выполняете команду ALTER TABLE, которая добавляет внешний ключ в таблицу на узле Publisher, этот внешний ключ добавляется и в таблицу на узле Subscriber. Чтобы предотвратить это, отключите распространение изменений схемы перед выдачой ALTER TABLE команды.
Изменения схемы должны выполняться только на издателе, а не на подписчиках (включая переиздающих подписчиков). Репликация слиянием не допускает изменения схемы у подписчика. Репликация транзакций не предотвращает изменения, однако изменения могут быть причиной ошибки репликации.
Изменения, переданные подписчику, выполняющему повторную публикацию, по умолчанию передаются и его подписчикам.
Если изменение схемы ссылается на объекты или ограничения, существующие на Издателе, но отсутствующие на Подписчике, изменение схемы будет успешно выполнено на Издателе, но завершится ошибкой на Подписчике.
Любой объект на подписчике, на который имеются ссылки, при добавлении внешнего ключа должен иметь то же имя и того же владельца, что и соответствующий объект на издателе.
Явное добавление, удаление или изменение индексов не реплицируются, и любое изменение, включающее явный индекс, должно выполняться отдельно для каждого набора реплик. Поддерживается неявное создание индексов для ограничений (например, для ограничения первичного ключа).
Изменение или удаление столбцов идентификаторов, управляемых репликацией, не поддерживается. Дополнительные сведения об автоматическом управлении столбцами идентификаторов см. в статье Репликация столбцов идентификаторов.
Изменения схемы, включающие недетерминированные функции, не поддерживаются, поскольку они могут привести к разным данным на издателе и на подписчике (эта разница данных называется расхождением). Например, если на узле Publisher выполнить следующую команду:
ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), то при ее репликации на узел Subscriber и выполнении значения будут другими. Дополнительные сведения о недетерминированных функциях см. в разделе Deterministic and Nondeterministic Functions.Рекомендуется именовать ограничения явным образом. Если ограничение не имеет явного имени, SQL Server создает имя ограничения, и эти имена будут отличаться на издателе и каждом подписчике. Это может стать причиной проблем во время репликации изменений схемы. Например, если на издателе удаляется столбец и зависимое ограничение, то во время репликации будет произведена попытка удалить ограничение на подписчике. Удаление на подписчике завершится ошибкой, так как имя ограничения отличается. Если синхронизация завершается сбоем из-за проблемы с именованием ограничения, вручную удалите ограничение у подписчика, а затем повторно запустите агент слияния.
При публикации какой-либо таблицы для репликации невозможно изменить данные столбца в этой таблице на данные типа XML, если моментальный снимок публикации уже создан. Перед изменением столбца необходимо вначале удалить репликацию.
Уровень изоляции «read uncommitted» не поддерживается при выполнении операций DDL для публикуемой таблицы.
SET CONTEXT_INFO не следует использовать для изменения контекста транзакций, в которых изменения схемы выполняются для опубликованных объектов.
Добавление столбцов
Чтобы добавить новый столбец в таблицу и включить этот столбец в существующую публикацию, выполните команду ALTER TABLE<Add >Column<.> По умолчанию этот столбец затем реплицируется всем подписчикам. Столбец должен допускать использование значений NULL или содержать ограничение по умолчанию. Дополнительные сведения о добавлении столбцов см. в подразделе «Репликация слиянием» этого раздела.
Чтобы добавить новый столбец в таблицу и не включать этот столбец в существующую публикацию, отключите репликацию изменений схемы, а затем выполните ALTER TABLE<Таблица> ADD <Столбец>.
Чтобы включить существующий столбец в существующую публикацию, используйте sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) или диалоговое окно «Свойства публикации — <Публикация>».
Дополнительные сведения см. в разделе Define and Modify a Column Filter. Это потребует повторной инициализации подписок.
Добавление столбца идентификации в опубликованную таблицу не поддерживается, поскольку это может привести к отсутствию сходимости при репликации этого столбца подписчику. Значения в столбце идентификатора у издателя зависят от порядка, в котором строки затрагиваемой таблицы физически хранятся. Строки могут храниться у подписчика по-разному; поэтому значение в столбце IDENTITY может отличаться для одних и тех же строк.
Удаление столбцов
Чтобы удалить столбец из существующей публикации и удалить столбец из таблицы в Publisher, выполните ALTER TABLEкоманду Drop Column<><.> По умолчанию столбец затем удаляется из таблицы у всех подписчиков.
Чтобы удалить столбец из существующей публикации, но сохранить этот столбец в таблице на узле-издателе, используйте sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) или диалоговое окно Свойства публикации — <Публикация>.
Дополнительные сведения см. в разделе Define and Modify a Column Filter. Это потребует создания нового моментального снимка.
Удаляемый столбец не может использоваться в предложениях фильтра любой статьи любой публикации в базе данных.
При удалении столбца из опубликованной статьи имейте в виду возможное влияние на базу данных ограничений, индексов и свойств столбца. Например:
Нельзя удалять из статей в транзакционных публикациях столбцы, входящие в первичный ключ, так как они используются репликацией.
Нельзя удалить столбец rowguid из статей в публикациях слияния или столбец mstran_repl_version из статей в публикациях транзакционной репликации, поддерживающих обновляемые подписки, поскольку они используются в репликации.
Изменения индексов не распространяются на подписчиков: если удалить столбец у издателя и при этом будет удален зависимый индекс, удаление индекса не реплицируется. Необходимо удалить индекс на подписчике перед удалением столбца на издателе, чтобы удаление столбца прошло успешно при репликации от издателя к подписчику. Если синхронизация завершается сбоем из-за индекса у подписчика, вручную удалите этот индекс, а затем повторно запустите агент слияния.
Ограничениям следует явно задавать имена, чтобы их можно было удалить. Дополнительные сведения см. в подразделе «Общие вопросы» этого раздела.
репликация транзакций
Изменения схемы распространяются на подписчиков, использующих более ранние версии SQL Server, но оператор DDL должен включать только синтаксис, поддерживаемый версией, используемой на подписчике.
Если подписчик публикует данные повторно, поддерживаемые изменения схемы включают только добавление и удаление столбца. Эти изменения следует вносить в Publisher с помощью sp_repladdcolumn (Transact-SQL) и sp_repldropcolumn (Transact-SQL) вместо ALTER TABLE синтаксиса DDL.
Репликация изменений схемы не выполняется для подписчиков, отличных от подписчиков SQL Server.
Изменения схемы не распространяются от издателей, отличных от SQL Server.
Индексированные представления, которые реплицируются в виде таблиц, невозможно изменить. Индексированные представления, которые реплицируются как индексированные представления, могут быть изменены, однако их изменение приведет к тому, что они станут обычными, а не индексированными представлениями.
Если публикация поддерживает подписки с немедленным обновлением или подписки с обновлением через очереди, перед внесением изменений в схему система должна быть переведена в состояние покоя: вся активность в опубликованной таблице должна быть остановлена на издателе и подписчиках, а ожидающие применения изменения данных должны быть переданы на все узлы. После распространения изменений схемы на все узлы можно возобновить действия в опубликованных таблицах.
Если публикация использует одноранговую топологию, перед внесением изменений в схему систему необходимо перевести в состояние покоя. Дополнительные сведения см. в статье Приостановка топологии репликации (программирование Transact-SQL для репликации).
Добавление в таблицу столбца типа timestamp и сопоставление timestamp с 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 Разрешить изменение Разрешить изменение* Блокировать изменения файловый поток Разрешить изменение Блокировать изменения Блокировать изменения date, time, datetime2и datetimeoffset Разрешить изменение Разрешить изменение* Блокировать изменения * Подписчики SQL Server Compact преобразуют эти типы данных на стороне подписчика.
Если при применении изменения схемы возникает ошибка (например, ошибка по причине добавления внешнего ключа, ссылающегося на таблицу, которая недоступна на подписчике), синхронизация завершается ошибкой, и подписка должна быть инициализирована повторно.
Если изменение схемы выполняется в столбце, входящем в фильтр соединения или параметризованный фильтр, потребуется повторно инициализировать все подписки и заново создать моментальный снимок.
Репликация слиянием обеспечивает игнорирование хранимыми процедурами изменений схемы во время устранения неполадок. Дополнительные сведения см. в статьях sp_markpendingschemachange (Transact-SQL) и sp_enumeratependingschemachanges (Transact-SQL).