Конфликт расширенной репликации слиянием: разрешение в логической записи
Область применения: 
SQL Server
В разделе рассматриваются различные комбинации подходов к распознаванию конфликтов и устранению конфликтов, возможные при использовании логических записей. В репликации слиянием возникает конфликт, когда изменение одних и тех же данных производится более чем одним узлом, или же в репликации слиянием возникают определенные типы ошибок, такие как нарушение ограничений, когда изменяется репликация. Дополнительные сведения о распознавании и разрешении конфликтов см. в разделе Advanced Merge Replication Conflict Detection and Resolution.
Чтобы указать уровень отслеживания и разрешения конфликтов для статьи, см. раздел Указание параметров репликации слиянием.
Обнаружение конфликтов
Способ обнаружения конфликтов в логических записях определяется двумя свойствами статьи: column_tracking и logical_record_level_conflict_detection. SQL Server 2005 (9.x) и более поздних версий также поддерживают обнаружение на уровне логических записей.
Значением свойства статьи logical_record_level_conflict_detection может быть TRUE или FALSE. Значение должно быть задано только для родительской статьи верхнего уровня. Кроме того, его должны игнорировать все дочерние статьи. Если это значение равно FALSE, репликация слиянием обнаруживает конфликты, как и в предыдущих версиях SQL Server, исключительно на основе значения свойства column_tracking для статьи. Если значение этого параметра TRUE, репликация слиянием игнорирует значение свойства column_tracking для статьи и определяет конфликт, если где-либо в логической записи были сделаны изменения. В качестве примера рассмотрен сценарий:
Конфликт обнаруживается, если два пользователя изменяют любые значения логической записи Customer2 в таблицах Customers, Orders, или OrderItems . В этом примере учитываются изменения, сделанные посредством инструкции UPDATE, но конфликт может быть также обнаружен, если изменения сделаны с помощью инструкций INSERT или DELETE.
Разрешение конфликтов
По умолчанию в репликациях слиянием для разрешения конфликтов используется логика, основанная на приоритетах. Если изменения, приводящие к конфликту, сделаны в базах данных двух подписчиков, предпочтение отдается изменениям подписчика с высшим приоритетом подписки; в случае одинаковых приоритетов побеждает подписчик, чьи изменения достигли издателя раньше. При обнаружении конфликтов на уровне строк или столбцов данные из строки победившего участника записываются поверх данных проигравшей базы данных.
Значением свойства статьи logical_record_level_conflict_resolution может быть TRUE или FALSE. Значение должно быть задано только для родительской статьи верхнего уровня. Кроме того, его должны игнорировать все дочерние статьи. При значении TRUE значение выигравшей логической записи записывается поверх проигравшей логической записи. При значении параметра FALSE, отдельные выигравшие строки могут быть взяты из различных подписчиков и издателей. Например, подписчик А может выиграть конфликт по строке из таблицы Orders , а подписчик В выигрывает по соответствующей строке из таблицы OrderItems table. Результатом будет логическая запись, содержащая данные из строки Orders подписчика А и строки OrderItems подписчика В.
Взаимодействие настроек обнаружения и устранения конфликтов
Исходы конфликтов зависят от взаимодействия настроек обнаружения и разрешения конфликтов. В примере ниже предполагается использование устранения конфликта на основе приоритетов. При использовании логических записей, возможны следующие варианты.
Обнаружение на уровне строк или столбцов, разрешение на уровне строк.
Обнаружение на уровне столбцов, разрешение на уровне логических записей.
Обнаружение на уровне строк, разрешение на уровне логических записей.
Обнаружение на уровне логических записей, разрешение на уровне логических записей.
Обнаружение на уровне строк или столбцов, разрешение на уровне строк.
В этом примере публикация настраивается с помощью:
параметрcolumn_tracking принимает значения TRUE или FALSE;
параметрlogical_record_level_conflict_detection имеет значение FALSE;
параметрlogical_record_level_conflict_resolution имеет значение FALSE.
В этом случае обнаружение конфликтов осуществляется на уровне строк или столбцов, а разрешение — на уровне строк. С помощью этих настроек используется преимущество, когда все изменения в логической записи реплицируются как одно целое, но без обнаружения или разрешения конфликта на уровне логических записей.
Обнаружение на уровне столбцов, разрешение на уровне логических записей.
В этом примере публикация настраивается с помощью:
параметрcolumn_tracking имеет значение TRUE;
параметрlogical_record_level_conflict_detection имеет значение FALSE;
параметрlogical_record_level_conflict_resolution имеет значение TRUE.
Издатель и подписчик начинают работать с одним и тем же набором данных, логическая запись определяется между таблицами orders и customers . Издатель изменяет столбец custcol1 в таблице customers , а так же ordercol1 в таблице orders . Подписчик изменяет custcol1 в той же самой строке таблицы customers и столбец ordercol2 в той же строке таблицы orders . Изменения одного и того же столбца в таблице customer приводят к конфликту, но изменения таблицы orders к конфликту не приводят.
Поскольку разрешение конфликтов производится на уровне логических записей, выигравшими изменениями, сделанными издателем, заменяются изменения, сделанные в таблицах подписчика во время обработки репликации.
Обнаружение на уровне строк, разрешение на уровне логических записей.
В этом примере публикация настраивается с помощью:
параметрcolumn_tracking имеет значение FALSE;
параметрlogical_record_level_conflict_detection имеет значение FALSE;
параметрlogical_record_level_conflict_resolution имеет значение TRUE.
Издатель и подписчик запускаются с одинаковым набором данных. Издатель изменяет столбец custcol1 в таблице пользователи . Подписчик изменяет столбец custcol2 в таблице customers , а так же ordercol2 в таблице orders . Изменения одной и той же строки в таблице customers приводят к конфликту, но изменения подписчиком таблицы orders к конфликту не приводят.
Поскольку разрешение конфликтов производится на уровне логических записей, во время синхронизации изменения, сделанные в таблицах подписчика, заменяются выигравшими изменениями, сделанными издателем.
Обнаружение на уровне логических записей, разрешение на уровне логических записей.
В этом примере публикация настраивается с помощью:
параметрlogical_record_level_conflict_detection имеет значение TRUE;
параметрlogical_record_level_conflict_resolution имеет значение TRUE.
Издатель и подписчик запускаются с одинаковым набором данных. Издатель изменяет столбец custcol1 в таблице пользователи . Подписчик изменяет столбец ordercol1 в таблице orders . Изменения не относятся к одной и той же строке или одним и тем же столбцам, но поскольку изменения произошли в одной и той же логической записи для custid=1, они распознаны как конфликт на уровне логической записи.
Поскольку разрешение конфликтов производится также на уровне логических записей, во время синхронизации изменения, сделанные в таблицах подписчика, заменяются выигравшими изменениями, сделанными издателем.
