Несовпадение данных на издателе и подписчике

Следующие действия устраняют причины, перечисленные в разделе «Объяснение».

• Данные обновляются на подписчике вне репликации:

  • Если требуется разрешить пользователям вставлять, обновлять и удалять данные на подписчике, используйте репликацию слиянием, репликацию транзакций с обновляемыми подписками или одноранговую репликацию транзакций. Дополнительные сведения см. в разделах Обзор репликации слиянием и Типы публикации для репликации транзакций.

  • Если требуется запретить пользователям вставлять, обновлять и удалять данные на подписчике, создайте триггер для каждой таблицы, содержащий слово ROLLBACK, и используйте параметр NOT FOR REPLICATION (предотвращающий срабатывание триггера в случае, когда агент репликации выполняет операцию). Например:

    USE AdventureWorks
    GO
    CREATE TRIGGER prevent_user_dml
    ON Person.Address
    FOR INSERT, UPDATE, DELETE
    NOT FOR REPLICATION
    AS
    ROLLBACK
    

    Дополнительные сведения см. в разделах CREATE TRIGGER (Transact-SQL) и Управление ограничениями, идентификаторами и триггерами с помощью параметра «NOT FOR REPLICATION».

• Триггеры используются на подписчике. Следует правильно управлять триггерами на подписчике, чтобы они не вызвали расхождения данных или появления других проблем.

  • Триггеры должны вызывать изменения данных на подписчике, если только используется репликация слиянием, репликация транзакций с обновляемыми подписками или одноранговая репликация транзакций. Дополнительные сведения см. в разделах Обзор репликации слиянием и Типы публикации для репликации транзакций.

  • Во многих случаях в триггерах должен использоваться параметр NOT FOR REPLICATION. Рассмотрим триггер, который вставляет данные в таблицу отслеживания: при первоначальной вставке строки пользователем уместно, чтобы триггер включался и вводил строку в отслеживающую таблицу; однако триггер не должен включаться, когда данные реплицируются на подписчик, так как это привело бы к вставке ненужной строки в таблицу отслеживания.

    Если триггер содержит инструкцию ROLLBACK и при этом в нем не используется параметр NOT FOR REPLICATION, строки, реплицированные на подписчик, могут быть не применены.

  • Для репликации транзакций существуют дополнительные вопросы, касающиеся параметра XACT_ABORT и использования инструкций COMMIT и ROLLBACK в триггере. Дополнительные сведения см. в подразделе «Триггеры» раздела Вопросы использования репликации транзакций.

• Сценарии выполняются репликацией на подписчике, но не на издателе.

  Параметры @pre_snapshot_script и @post_snapshot_script хранимых процедур sp_addpublication и sp_addmergepublication позволяют указать сценарии, которые запускаются до и после применения моментального снимка. Дополнительные сведения см. в разделе Выполнение сценариев до и после применения моментального снимка. Хранимая процедура sp_addscriptexec позволяет выполнять сценарий во время процесса синхронизации. Дополнительные сведения см. в разделе Как выполнять сценарии во время синхронизации (программирование репликации на языке Transact-SQL).

  Эти сценарии обычно используются для административных задач, таких как добавление имен входа на подписчике. Если сценарии используются для обновления данных на подписчике, который должен быть доступен только для чтения, администратору следует убедиться в том, что это не приводит к расхождению данных.

• Репликация выполнения хранимой процедуры для публикации транзакций приводит к разным результатам на подписчике.

  При репликации выполнения хранимой процедуры определение процедуры реплицируется на подписчик при инициализации подписки. Когда процедура выполняется на издателе, репликация выполняет соответствующую процедуру на подписчике. Дополнительные сведения см. в разделе Публикация выполнения хранимых процедур в репликации транзакций.

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

• Нарушение ограничений или другие проблемы препятствуют вставке, обновлению или удалению строк на подписчике.

  В репликации транзакций нарушения ограничений рассматриваются как ошибки; по умолчанию при возникновении этих ошибок агент распространителя прекращает синхронизацию (сведения о пропуске этих ошибок см. в разделе Пропуск ошибок в репликации транзакций). В репликации слиянием нарушения ограничений обрабатываются как конфликты. Они регистрируются, но не вызывают прекращения синхронизации агентом слияния. В обоих типах репликации нарушения ограничений могут повлечь расхождение данных, если вставка, обновление или удаление, успешно выполненные на одном узле, завершатся неудачей на другом узле.

  При публикации таблицы параметры схемы по умолчанию указывают, что ограничения внешнего ключа и проверочные ограничения должны быть созданы в базе данных подписки с установленным параметром NOT FOR REPLICATION. Если для приложения необходимы другие установки ограничений, измените параметры схемы. Дополнительные сведения см. в разделах Как указать параметры схемы (среда SQL Server Management Studio) и Как задать параметры схемы (программирование репликации на языке Transact-SQL).