Приложение

чртранитель

Данные или транзакции Записи журналов событий и ошибок с. 15-1. Процесс репликации моментальных снимков

1:

It

Если используется немедленное обновление подписки, при любой попытке подписчика обновить реплицированные данные он сам или издатель инициируют транзакцию с тапным подтверждением (two-phase commit, 2PC). 2РС-транзакция включает этап подготовки и этап подтверждения, и выполняется под управлением службы MS DTC, запущенной на подписчике и выступающей в качестве диспетчера транзакций. На подготовительном этапе MS DTC координирует действия служб SQL Server, запущенных на издателе и подписчике и играющих роль диспетчеров ресурсов, чтобы гарантировать успешное выполнение транзакции в обеих БД. На этапе подтверждения MS DTC получает от диспетчеров ресурсов уведомления об успешной подготовке, затем диспетчерам передается команда подтверждения и транзакция подтверждается на сервере-издателе и сервере-подписчике. Если на издателе имеется конфликт (конфликтующее обновление еще не было тиражировано на сервер-подписчик), транзакция, иницииропанная подписчиком, завершается неудачно. 2РС-транзакция гарантирует отсутствие конфликтов, поскольку издатель вьшвляет все конфликты до подтверждения транзакции.

Если очередь обновлений (Queued Updating), сделанные подписчи-

ком изменения помещаются в очередь и периодически передаются издателю. Изменения могут быть выполнены при отсутствии соединения с издателем. Изменения, которые находятся в очереди, пересылаются на данный сервер, когда устанавливается соединение. Очередь может храниться либо в БД SQL Server, либо вы можете выбрать использование Microsoft Message Queuing, если работаете в среде Windows 2000. Подробнее об использовании Microsoft Message Queuing - в разделе Queued Updating Components*, справочной системы SQL Server Boolcs Online. Так как обновления происходят не в реальном времени, то конфликты могут происходить, если другой подписчик или издатель изменили одни и те же данные. Конфликты разрешаются с ис-

пользованием стратегии разрешения конфликтов, в момент создания

публикации.

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

Репликация транзакций

При репликации транзакций агент Snapshot создает исходный моментальный снимок

данных, помеченных для репликации, и копирует его с в папку мо-

ментальных снимков распространителя. Агент Distribution направляет полученный снимок каждому подписчику. Агент Log Reader следит за изменениями данных, участвующих в репликации, и фиксирует каждое изменение журнала транзакций в БД распространения на сервере-распространителе. Агент Distribution отправляет каждое изменение всем подписчикам в первоначальном порядке выполнения этих изменений. Если хранимая процедура используется для обновления большого количества записей, можно реплицировать эту процедуру, а не каждую обновленную строку.

три этих агента репликации заносят информацию о событиях и ошибках в БД распространения. На рис. 15-2 показан процесс репликации транзакций.

Пол ьз □ в ателье кое приложение

Агент Snapshot , i; Агент 1лв (евИег

Папка моментальных снимков

Агент Istrlbution

БД распространения

\ Распро- ,странитвль J

Начальные данные и схема -> Новые транзакции - Записи журналов событий и ошибок

Рис. 15-2. Процесс репликации транзакций

Агент Distribution может работать постоянно, чтобы задержку в

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

получат реплицированные транзакции, агент Distribution Clean Up удаляет эти транзакции из БД распространения. Если по окончании заданного периода хранения (по умолчанию - 72 часа) подписчик не получил реплицируемые транзакции, те удаляются из БД распространения и подписка дезактивируется. Это позволяет предотвратить чрезмерное увеличение размера БД распространения. Дезактивированная подписка может быть повторно и тогда подписчику с целью обновления

его данных передается новый моментальный снимок.

Кроме того, репликацию транзакций, по аналогии со снимочной репликацией,

можно настроить для поддержки обновляемых подписок.

Репликация сведением

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

Пользовательское приложение

Пользовательское приложение

ПОДПИ<Я№

Распре-

.странитель

Начальные данные и схема -Новые транзакции -* Записи журналов событий и ошибок

VI

Рис. 15-3. Процесс репликации сведением

Чтобы различать записи х копий реплицируемой таблицы и выявлять конфликты между записями, агент Merge использует специальный уникальный стол-