Инструкции UPDATE могут быть реплицированы как пары DELETE/INSERT

В этой статье описывается, что инструкции обновления могут реплицироваться как пары DELETE/INSERT.

Оригинальная версия продукта: SQL Server
Исходный номер базы знаний: 238254

Итоги

Если любой столбец, являющийся частью уникального ограничения, обновляется, SQL Server реализует обновление как "отложенное обновление", то есть как пара операций DELETE/INSERT . Это "отложенное обновление" приводит к тому, что репликация отправляет пару DELETE/INSERT операторов подписчикам. Существуют и другие ситуации, которые могут вызвать отложенное обновление. Таким образом, любая бизнес-логика, реализуемая в триггерах или пользовательских хранимых процедурах на подписчике, также должна быть включена в UPDATEDELETE/INSERT триггеры или пользовательские хранимые процедуры.

Дополнительная информация

Поведение по умолчанию в репликации транзакций — использовать INSERTUPDATEпользовательские хранимые процедуры для DELETE применения изменений у подписчиков.

INSERT операторы, сделанные на издателе, применяются к подписчикам через вызов хранимой INSERT процедуры. Аналогичным образом DELETE оператор применяется через вызов хранимой DELETE процедуры.

Однако при UPDATE выполнении инструкции в качестве "отложенного обновления" агент чтения журналов помещает пару DELETE/INSERT вызовов хранимой процедуры в базу данных распространителя, которая будет применена к подписчикам, а не вызову хранимой процедуры обновления. Например, предположим, что у вас есть таблица публикации с именем TABLE1с этими тремя столбцами:

• col1 int
• col2 int
• col3 varchar(30)

Единственное уникальное ограничение определяется col1 с помощью ограничения TABLE1 первичного ключа. Предположим, что у вас есть одна запись (1,1, Даллас).

При выполнении этого кода:

UPDATE TABLE1 set col1 = 3 where col3 = 'Dallas'

Инструкция UPDATE реализуется SQL Server как пара операторовINSERTDELETE/после обновленияcol1, который имеет уникальный индекс. Таким образом, средство чтения журналов помещает пару вызовов DELETE/INSERT в базу данных распространителя. Это может повлиять на любую бизнес-логику, которая присутствует в триггерах или пользовательских хранимых процедурах на подписчике. Для обработки этой ситуации следует включить дополнительную бизнес-логику и DELETEINSERT триггеры или хранимые процедуры.

Если вы предпочитаете реплицировать однострочные обновления в виде UPDATE инструкций вместо INSERTDELETE пар, можно включить флаг трассировки 8207.

Кроме того, если вы используете горизонтальный фильтр в публикации и если обновленная строка не соответствует условию фильтра, вызов процедуры отправляется подписчикам.DELETE Если обновленная строка ранее не соответствовала условию фильтра, но соответствует условию после обновления, вызов процедуры отправляется только INSERT через процесс репликации.

В предыдущем примере предположим, что у вас также есть горизонтальный фильтр, определенный в TABLE1: where col3 = 'Dallas'. При выполнении этого кода:

UPDATE table1 set col3 = 'New York' where col1 = 3

Агент чтения журналов помещает вызов хранимой DELETE процедуры только для подписчиков, так как обновленная строка не соответствует критериям горизонтального фильтра.

Теперь, если выполнить этот код:

UPDATE table1 set col3 = 'Dallas' where col1 = 3

Средство чтения журналов создает только INSERT вызов хранимой процедуры, так как строка ранее не соответствовала условию фильтра.

UPDATE Хотя операция была выполнена на издателе, на подписчике применяются только соответствующие команды.