Инструкции UPDATE могут реплицироваться как пары DELETE/INSERT
В этой статье описывается, что инструкции Update могут реплицироваться как пары DELETE/INSERT.
Оригинальная версия продукта: SQL Server
Исходный номер базы знаний: 238254
Сводка
Если какой-либо столбец, являющийся частью уникального ограничения, обновляется, то SQL Server реализует обновление как "отложенное обновление", то есть как пара операцийDELETE
/INSERT
. Это "отложенное обновление" приводит к тому, что репликация отправляет подписчикам DELETE
/INSERT
пару операторов. Существуют и другие ситуации, которые могут привести к отложению обновления. Поэтому любая бизнес-логика, реализованная в UPDATE
триггерах или пользовательских хранимых процедурах на подписчике, также должна быть включена DELETE
/INSERT
в триггеры или пользовательские хранимые процедуры.
Дополнительная информация
Поведение по умолчанию в репликации транзакций заключается в использовании INSERT
пользовательских UPDATE
хранимых процедур и DELETE
для применения изменений в подписчиках.
INSERT
операторы, сделанные на издателе, применяются к подписчикам через вызов хранимой INSERT
процедуры. Аналогичным образом оператор DELETE
применяется через вызов хранимой DELETE
процедуры.
Однако когда UPDATE
инструкция выполняется как "отложенное обновление", агент logreader помещает пару вызовов DELETE
/INSERT
хранимых процедур в базе данных распространителя для применения к подписчикам, а не вызов хранимой процедуры обновления. Например, предположим, что у вас есть таблица публикации с именем TABLE1
с тремя столбцами:
- col1 int
- col2 int
- col3 varchar(30)
Единственное уникальное ограничение для TABLE1
определяется col1
с помощью ограничения первичного ключа. Предположим, что у вас есть одна запись (1,1, "Даллас").
При выполнении этого кода:
UPDATE TABLE1 set col1 = 3 where col3 = 'Dallas'
Оператор UPDATE
реализуется SQL Server как пара операторовINSERT
DELETE
/, так как выполняется обновление col1
, для которого определен уникальный индекс. Таким образом, средство чтения журнала помещает пару вызовов DELETE
/INSERT
в базу данных распространителя. Это может повлиять на любую бизнес-логику, которая присутствует в триггерах или пользовательских хранимых процедурах на подписчике. Для обработки этой ситуации следует включить дополнительную бизнес-логику в DELETE
INSERT
и триггеры или хранимые процедуры.
Если вы предпочитаете использовать одну логику и хотите, чтобы все UPDATE
команды реплицировались как DELETE
/INSERT
пары, можно включить флаг трассировки.
Кроме того, если в публикации используется горизонтальный фильтр, а обновленная строка не соответствует условию фильтра, подписчикам отправляется только DELETE
вызов процедуры. Если обновленная строка ранее не соответствовала условию фильтра, но соответствует условию после обновления, то в процессе репликации отправляется только INSERT
вызов процедуры.
В предыдущем примере предположим, что у вас также есть горизонтальный фильтр, определенный для TABLE1
: where col3 = 'Dallas'
. При выполнении этого кода:
UPDATE table1 set col3 = 'New York' where col1 = 3
Агент logreader размещает только вызов хранимой DELETE
процедуры для применения к подписчикам, так как обновленная строка не соответствует критериям горизонтального фильтра.
Теперь при выполнении этого кода:
UPDATE table1 set col3 = 'Dallas' where col1 = 3
средство чтения журнала создает только вызов хранимой INSERT
процедуры, так как строка ранее не соответствовала условию фильтра.
Хотя операция UPDATE
была выполнена на издателе, на подписчике применяются только соответствующие команды.
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по