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

Процесс репликации путем слияния

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

1. Триггеры, установленные с помощью СУБД SQL Server, отслеживают изменения в публикуемых данных.

2. Изменения, полученные от издателя, применяются к базам данных подписчиков.

3. Изменения, полученные от подписчиков, применяются к базе данных издателя, и происходит разрешение всех конфликтов.

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

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

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

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

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

Специальные требования к планированию

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

В СУБД SQL Server определенный столбец обозначается как глобально уникальный идентификатор для каждой строки в публикуемой таблице. Если в таблице уже имеется столбец, для которого определен тип данных uniqueidentifier, то в СУБД SQL Server этот столбец вводится в действие автоматически. В противном случае к таблице добавляется столбец с типом данных rowguid (которому, если есть такая возможность, присваивается имя, совпадающее с обозначением этого типа данных, т.е. rowguid) и на основе этого столбца создается индекс.

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

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

обнаружение и разрешение конфликтов;

отслеживание изменений в данных;

синхронизация;

формирование отчетов.

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

Транзакционная репликация

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

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

Следует отметить, что действие такой системы репликации распространяется только на операции, зарегистрированные в журнале базы данных. Репликация нерегистрируемых в журнале массовых операций (таких как операции с помощью утилиты ВСР, для которых отменено ведение журнала) или операций с большими двоичными объектами (Binary Large Object - BLOB) не может быть выполнена должным образом.

Как показано на рис. 20.6, при использовании рассматриваемой системы репликации в ее простейшей форме изменения могут быть внесены только в базу данных издателя. Распространение изменений по базам данных подписчиков с помощью средств реплихсации может осуществляться через установленные интервалы или в режиме, напоминающем режим реального времени. Безусловно, в последнем случае обеспечивается менее строгий контроль над тем, когда осуществляется репликация, но, как правило, в связи с выполнением 1саждой операции репликации приходится перемещать меньше данных. Обновления происходят намного чаще по сравнению с другими методами репликации, а время задержки сводится к минимум) Для обеспечения надежного и неизменно соответствующего требованиям режима реального времени обновления баз данных подписчР1ков (т.е. для непосредственного обеспечения транзакционной согласованности) необходимо поддерживать надежные сетевые соединения межд) издателем и подписчиками (а если объем и частота обновлений очень высоки, то следует также предусмотреть достаточно высокую пропускную способность соединений, чтобы в них нормально проходил весь трафик данных между издателем и подписчиками).

И здате л ь/расп редел итель

Опубликованные данные

Транзакции

Подписчик

Транзакции

Подписчик

Рис. 20.6. Схема функционирования системы транзакционной репликации