Указание порядка обработки статей слияния
Начиная с версии MicrosoftSQL Server 2005, порядок обработки статей для публикаций слиянием, принятый по умолчанию, можно переопределять. Это полезно, например, при определении ссылочной целостности с помощью триггеров и при этом триггеры должны запускаться в конкретном порядке.
Указание порядка обработки статей
- Программирование репликации на Transact-SQL: Как установить порядок обработки статей таблиц слияния (программирование репликации на языке Transact-SQL)
Как определяется порядок обработки
Во время синхронизации слияния статьи по умолчанию обрабатываются в том порядке, который требуют зависимости между объектами, в том числе ограничения декларативной ссылочной целостности (DRI), определенные для базовых таблиц. Обработка включает нумерацию изменений в таблице и применение этих изменений. Если DRI отсутствуют, но для табличных статей имеются фильтры соединения или логические записи, то статьи обрабатываются в том порядке, который требуют эти фильтры и логические записи. Статьи, не связанные с какой-либо другой статьей через DRI, фильтры соединения, логические записи или другие зависимости, обрабатываются в соответствии с псевдонимами в системной таблице sysmergearticles (Transact-SQL).
Рассмотрим публикацию, включающую таблицы SalesOrderHeader и SalesOrderDetail со столбцом первичного ключа SalesOrderID в таблице SalesOrderHeader и соответствующим столбцом внешнего ключа SalesOrderID в таблице SalesOrderDetail. Во время синхронизации репликация слиянием препятствует нарушениям внешнего ключа путем вставки новых строк в столбец SalesOrderHeader перед тем, как вставить соответствующие строки в столбец SalesOrderDetail. Точно так же строки удаляются из столбца SalesOrderDetail перед удалением соответствующих строк из столбца SalesOrderHeader.
Однако в некоторых приложениях ссылочная целостность принудительно навязывается через триггеры базы данных или на уровне приложения, а не через DRI. В приведенной выше публикации таблица SalesOrderDetail вместо DRI могла бы иметь триггер вставки, который перед вставкой проверял бы, что в таблице SalesOrderHeader существует связанная строка. Таблица SalesOrderHeader могла бы иметь триггер удаления, который перед удалением проверял бы, что в таблице SalesOrderDetail отсутствует связанная строка. Репликация слиянием перед указанием порядка обработки не учитывает триггеры, потому что она перед запуском триггера не может определить, каков будет его результат. Точно так же репликация не может учитывать ограничения, определенные на уровне приложения.
Если ссылочная целостность сохраняется с помощью триггеров или на уровне приложения, необходимо задать порядок, в котором будут обрабатываться статьи. В примере с триггерами следовало бы указать, что таблица SalesOrderHeader должна обрабатываться раньше SalesOrderDetail, потому что упорядочивание статей основано на порядке вставки. Репликация слиянием автоматически меняет этот порядок на обратный для удалений. Репликация слиянием не завершится неудачей, если статьи не упорядочены, потому что, если происходит нарушение ограничения, агент слияния продолжает обрабатывать статьи. Затем, после обработки остальных статей, он пытается выполнить сбойные операции. При указании порядка статей просто исключаются повторные попытки и связанная с ними дополнительная обработка. Если указать неправильный порядок (например, если он задает обработку записей с подробными данными до обработки записей заголовков), репликация слиянием будет продолжать обработку до ее успешного завершения.