Укажите свойства репликации слиянием

Область применения:SQL Server

В этом разделе описано, как задать различные свойства репликации слиянием.

Статья слияния предназначена только для скачивания

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

Рекомендации

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

Использование SQL Server Management Studio

На странице "Статьи"

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

На вкладке «Свойства» в окне «Свойства статьи»

  1. На странице Статьи мастера создания новой публикации или в диалоговом окне Свойства публикации — <Публикация> выберите таблицу и нажмите Свойства статьи.

  2. Щелкните Указать свойства выделенной статьи таблицы или Указать свойства всех статей таблиц.

  3. В разделе Объект назначения на вкладке Свойства диалогового окна Свойства статьи — <Статья> укажите одно из следующих значений для параметра Направление синхронизации:

    • Загрузить подписчику, запретить изменения подписчику
    • Загрузка на подписчика, разрешить внесение изменений на подписчике
  4. Если вы находитесь в диалоговом окне "Свойства публикации — <публикация> ", нажмите кнопку "ОК ", чтобы сохранить и закрыть диалоговое окно.

Использование Transact-SQL

Новая статья

  1. Выполните хранимую процедуру sp_addmergearticle, указав значение 1 или 2 для параметра @subscriber_upload_options. Числа соответствуют следующему поведению.

    • 0 = без ограничений (по умолчанию). Изменения, произведенные на подписчике, передаются на издатель.
    • 1 — изменения на подписчике разрешены, но они не передаются на издатель.
    • 2 — изменения у подписчика не разрешены.

    Примечание.

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

Существующая статья

  1. Чтобы определить, предназначена ли статья только для загрузки, выполните sp_helpmergearticle и проверьте значение upload_options для статьи в результирующем наборе данных.

  2. Если значение, возвращенное на шаге 1, равно 0, выполните хранимую процедуру sp_changemergearticle, указав значение subscriber_upload_options в параметре @property, значение 1 в параметрах @force_invalidate_snapshot и @force_reinit_subscription и значение 1 или 2 в параметре @value, что соответствует следующему:

    • 1 — в Подписчике разрешено вносить изменения, но они не отправляются Издателю.

    • 2 — изменения у подписчика не допускаются.

      Примечание.

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

Интерактивное разрешение конфликтов

Репликация Microsoft SQL Server предоставляет интерактивный механизм разрешения конфликтов, который позволяет разрешать конфликты вручную во время синхронизации по запросу в диспетчере синхронизации Microsoft Windows. После включения интерактивного разрешения конфликтов разрешайте конфликты интерактивно во время синхронизации с помощью средства интерактивного разрешения. Интерактивный модуль разрешения конфликтов доступен в диспетчере синхронизации Microsoft Windows. Дополнительные сведения см. в разделе "Синхронизация подписки с помощью диспетчера синхронизации Windows" (диспетчер синхронизации Windows).

Рекомендации

  • Если синхронизация выполнена вне диспетчера синхронизации Windows (по расписанию или по требованию в среде SQL Server Management Studio или мониторе репликации), конфликты разрешаются автоматически без вмешательства пользователя с помощью метода разрешения конфликтов по умолчанию, указанному для статьи. Дополнительные сведения см. в разделе Interactive Conflict Resolution.

Использование SQL Server Management Studio

Включение интерактивного разрешения конфликтов для статьи

  1. На странице Статьи мастера создания публикаций или в диалоговом окне Свойства публикации — <Публикация> выберите таблицу. Дополнительные сведения об использовании мастера и доступе к этому диалоговому окну см. в статьях Создание публикации и Просмотр и изменение свойств публикации.
  2. Щелкните Свойства статьи, затем щелкните Указать свойства выделенной статьи таблицы или Указать свойства всех статей таблиц.
  3. На странице «Свойства статьи — <Статья>» или «Свойства статьи — <ArticleType>» щелкните вкладку Resolver.
  4. Выберите Позволить подписчикам разрешать конфликты в интерактивном режиме во время синхронизации по требованию.
  5. Нажмите ОК.
  6. Если вы находитесь в диалоговом окне "Свойства публикации — <публикация> ", нажмите кнопку "ОК ", чтобы сохранить и закрыть диалоговое окно.

Указание, что подписка должна использовать интерактивное разрешение конфликтов

  1. В диалоговом окне «Свойства подписки — <подписчик>: <SubscriptionDatabase>» укажите значение True для параметра «Разрешать конфликты в интерактивном режиме». Дополнительные сведения о доступе к этому диалоговому окну см. в разделах Просмотр и изменение свойств принудительной подписки и Просмотр и изменение свойств подписки по запросу.
  2. Нажмите ОК.

Использование Transact-SQL

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

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

  1. На издателе в базе данных публикаций выполните sp_helpmergearticle, указав @publication. Обратите внимание на значение allow_interactive_resolver для каждой статьи в наборе результатов, для которой будет использоваться Interactive Resolver.
    • Если значение равно 1, будет использоваться Interactive Resolver.
    • Если значение этого параметра равно 0, необходимо сначала включить Interactive Resolver для каждого материала. Для этого выполните хранимую процедуру sp_changemergearticle, указав параметр @publication, @article, значение allow_interactive_resolver для параметра @property и значение true для параметра @value.
  2. У подписчика в базе данных подписки выполните процедуру sp_addmergepullsubscription. Дополнительные сведения см. в статье Создание подписки по запросу.
  3. На подписчике в базе данных подписки выполните sp_addmergepullsubscription_agent, указав следующие параметры:
    • @publisher, @publisher_db (публикуемая база данных) и @publication.
    • Значение true в параметре @enabled_for_syncmgr.
    • Значение true в параметре @use_interactive_resolver.
    • Сведения об учётной записи безопасности, требуемые агенту слияния. Дополнительные сведения см. в статье Создание подписки по запросу.
  4. На издателе в базе данных публикации выполните sp_addmergesubscription.

Определите статью, которая поддерживает Интерактивный резолвер

  1. На сервере-издателе в базе данных публикации выполните sp_addmergearticle. Укажите имя публикации, которой принадлежит статья, в параметре @publication, имя статьи в параметре @article, публикуемый объект базы данных в параметре @source_object и значение true в параметре @allow_interactive_resolver. Дополнительные сведения см. в статье определить статью.

Уровень отслеживания и разрешения конфликтов для статей слияния

В этом разделе описывается, как указать уровень отслеживания конфликтов и разрешения для статей слиянием в SQL Server с помощью SQL Server Management Studio или Transact-SQL.

При синхронизации подписки на публикацию со слиянием репликация проверяет конфликты, вызванные изменениями одних и тех же данных, внесёнными как на Издателе, так и на Подписчике. Можно указать, чтобы конфликты определялись на уровне строки, где любое изменение строки будет считаться конфликтом, либо на уровне столбца, где конфликтом будет считаться только изменение в одних и тех же строке и столбце. Разрешение конфликтов статей выполняется на уровне строки. Дополнительные сведения по определению и разрешению конфликтов при использовании логических записей см. в разделе Detecting and Resolving Conflicts in Logical Records.

Ограничения и запреты

  • Если изменить уровень отслеживания после инициализации подписок, то эти подписки потребуется инициализировать повторно. Дополнительные сведения о последствиях изменения свойств см. в статье Изменение свойств публикации и статьи.
  • При отслеживании на уровне строк и столбцов устранение конфликтов всегда выполняется на уровне строк: победившая строка перезаписывает проигравшую строку. Репликация слиянием также позволяет указать отслеживание и разрешение конфликтов на уровне логических записей, однако эти параметры недоступны в SQL Server Management Studio. Сведения об установке данных параметров с помощью хранимых процедур репликации см. в разделе Определение связи логических записей между статьями таблиц слияния.

Использование SQL Server Management Studio

Укажите отслеживание изменений на уровне строк или столбцов для статей слияния на вкладке Свойства диалогового окна Свойства статьи, доступного в мастере создания публикаций и в диалоговом окне Свойства публикации — <публикация>. Дополнительные сведения об использовании мастера и доступе к этому диалоговому окну см. в статьях Создание публикации и Просмотр и изменение свойств публикации.

Укажите отслеживание на уровне строк или столбцов

  1. На странице Статьи мастера создания публикаций или в диалоговом окне Свойства публикации — <Публикация> выберите таблицу.
  2. Щелкните Свойства статьи, затем щелкните Указать свойства выделенной статьи таблицы или Указать свойства всех статей таблиц.
  3. На вкладке «Свойства» диалогового окна Article Properties <Article> выберите одно из следующих значений для свойства Уровень отслеживания: Отслеживание на уровне строк или Отслеживание на уровне столбцов.
  4. Если вы находитесь в диалоговом окне "Свойства публикации — <публикация> ", нажмите кнопку "ОК ", чтобы сохранить и закрыть диалоговое окно.

Использование Transact-SQL

Указание параметров отслеживания конфликтов для новой статьи слияния

  1. В издателе базы данных публикации выполните хранимую процедуру sp_addmergearticle и присвойте параметру @column_tracking одно из приведенных ниже значений.

    • true — использовать для статьи отслеживание на уровне столбцов;
    • false — использовать отслеживание на уровне строк (значение по умолчанию).

Изменение параметров отслеживания конфликтов для статьи публикации типа слияния

  1. Чтобы определить параметры отслеживания конфликтов для статьи слияния, выполните sp_helpmergearticle. Обратите внимание на значение параметра column_tracking в наборе результатов для статьи. Значение 1 означает, что используется отслеживание на уровне столбцов, а значение 0 означает, что используется отслеживание на уровне строк.

  2. В базе данных публикации на издателе выполните процедуру sp_changemergearticle. Присвойте параметру column_tracking значение @property, а параметру @value — одно из приведенных ниже значений.

    • true — использовать для статьи отслеживание на уровне столбцов;
    • false — использовать отслеживание на уровне строк (значение по умолчанию).

    Присвойте значение 1 параметрам @force_invalidate_snapshot и @force_reinit_subscription.

Управление отслеживанием удалений

Примечание.

Эта функция будет удалена в будущей версии SQL Server. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется.

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

Внимание

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

Указать, что операции удаления следует игнорировать для новой статьи слияния

На издателе в базе данных публикации выполните sp_addmergearticle (Transact-SQL). Укажите значение false в параметре @delete_tracking. Дополнительные сведения см. в статье определить статью.

Примечание.

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

Укажите, что операции удаления для существующей статьи слияния должны игнорироваться

  1. Чтобы определить, включена ли компенсация ошибок для статьи, выполните sp_helpmergearticle (Transact-SQL) и запишите значение delete_tracking в результирующем наборе. Если это значение равно 0, то команды удаления уже не обрабатываются.

  2. Если значение из шага 1 равно 1, выполните sp_changemergearticle (Transact-SQL) на узле Publisher в базе данных публикации. Укажите значение delete_tracking для @property и значение false для @value.

    Примечание.

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

Порядок обработки

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

Как определяется порядок обработки

Во время синхронизации слияния статьи по умолчанию обрабатываются в том порядке, который требуют зависимости между объектами, в том числе ограничения декларативной ссылочной целостности (DRI), определенные для базовых таблиц. Обработка включает нумерацию изменений в таблице и применение этих изменений. Если DRI отсутствуют, но для статей таблиц имеются фильтры соединения или логические записи, то статьи обрабатываются в том порядке, который требуют эти фильтры и логические записи. Статьи, не связанные с любой другой статьей с помощью DRI, фильтров соединения, логических записей или других зависимостей, обрабатываются в соответствии с псевдонимом статьи в системной таблице sysmergearticles (Transact-SQL).

Рассмотрим публикацию, включающую таблицы SalesOrderHeader и SalesOrderDetail с первичным ключевым столбцом SalesOrderID в таблице SalesOrderHeader и соответствующим внешним ключевым столбцом SalesOrderID в таблице SalesOrderDetail . Во время синхронизации репликация слиянием предотвращает нарушения ограничений внешнего ключа, вставляя все новые строки в SalesOrderHeader прежде, чем вставлять связанные строки в SalesOrderDetail. Точно так же строки удаляются из столбца SalesOrderDetail перед удалением соответствующих строк из столбца SalesOrderHeader.

Однако в некоторых приложениях ссылочная целостность принудительно навязывается через триггеры базы данных или на уровне приложения, а не через DRI. В приведенной выше публикации таблица SalesOrderDetail вместо DRI могла бы иметь триггер Insert, который перед вставкой проверял бы, что в таблице SalesOrderHeader существует связанная строка. ТаблицаSalesOrderHeader могла бы иметь триггер Delete, который перед удалением проверял бы, что в таблице SalesOrderDetail отсутствует связанная строка. Репликация слиянием не учитывает триггеры при определении порядка обработки статей, потому что не может определить, каким будет результат их выполнения, пока триггер не сработает. Точно так же репликация не может учитывать ограничения, определенные на уровне приложения.

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

Новая статья

  1. На издателе в базе данных публикации выполните sp_addmergearticle (Transact-SQL). Укажите целое значение, представляющее порядок обработки статьи, в параметре @processing_order. Дополнительные сведения см. в статье определить статью.

    Примечание.

    При создании упорядоченных статей необходимо оставлять промежутки между значениями порядковых номеров статей. Это облегчит задание новых значений в будущем. Например, если существуют три статьи, для которых нужно указать фиксированный порядок обработки, укажите в параметре @processing_order значения 10, 20 и 30, а не 1, 2 и 3 соответственно.

Существующая статья

  1. Чтобы определить порядок обработки статьи, выполните sp_helpmergearticle (Transact-SQL) и запишите значение processing_order в результирующем наборе.
  2. На узле издателя в базе данных публикации выполните sp_changemergearticle (Transact-SQL). Укажите значение из свойства processing_order в параметре @property и целое значение, представляющее порядок обработки, в параметре @value.