Предыдущие посты по этой теме:

· Change Tracking

· Репликация таблиц средствами Change Tracking

· Краткое введение в сервис-брокер

· Репликация средствами Change Tracking. Небольшое упражнение на FOR XML PATH и XQuery.

В посте Репликация таблиц средствами Change Tracking мы рассмотрели вариант синхронизации таблиц tbl_1 и tbl_2 при помощи появившегося в SQL Server 2008 механизма отслеживания изменений Change Tracking. В данном посте мы разовьем этот сценарий на случай, когда таблицы находятся на разных серверах. В качестве транспорта будет использоваться появившийся в SQL Server 2005 механизм асинхронного взаимодействия сервис-брокер. Таблица tbl_1 будет находиться на сервере Маша. Change Tracking будет отслеживать происходящие над ней изменения (delete, insert, update). Эти изменения будут превращаться в XML-сообщение и доставляться сервис-брокером на сервер Дубровский, где XML превратится обратно в DML-команды, которые будут применены к таблице tbl_2 на этом сервере. Вместо сервис-брокера можно задействовать свой транспорт по доставке XML, тогда этот сценарий может применяться, когда Маша и Дубровский оба SQL Expressы. Сервис-брокер входит в состав SQL Express, однако два SQL Expressа чер...

Продолжение. Начало - см. пост Репликация таблиц средствами Change Tracking.

Пусть имеем накопленные изменения с версии номер 1320.

select ct.SYS_CHANGE_VERSION, ct.SYS_CHANGE_CREATION_VERSION, ct.SYS_CHANGE_OPERATION, sct.commit_time, ct.id1, ct.id2, t.fld1, t.fld2 from changetable(changes tbl_1, 1320) ct join sys.dm_tran_commit_table sct on ct.sys_change_version = sct.commit_ts left join tbl_1 t on t.id1 = ct.id1 and t.id2 = ct.id2 order by 1

В 1997 г. в составе NT4 Option Pack был выпущен MSMQ 1.0 - см. http://www.emanual.ru/download/www.eManual.ru_4364.html.

Восемь лет спустя механизм асинхронной работы на основе очередей под названием Service Broker появился в составе SQL Server 2005. Мы его уже затрагивали в посте про Event Notification. Здесь придется коснуться его чуть более подробно, т.к. далее он понадобится в развитии репликации с помощью Change Tracking на распределенный сценарий. Подобно MSMQ сервис-брокер предназначен для асинхронного взаимодействия, что позволяет реализовать отсоединенные сценарии, когда SQL Serverное приложение отправляет сообщение другому SQL Serverному приложению и может заниматься дальше своими делами, не подвисая в ожидании ответа от удаленного участника. В MSMQ, он же Queued Components в СОМ+, размер сообщения ограничен 4 МБ, в сервис-брокере сообщение представляет собой, вообще говоря, varbinary(max) - 2 ГБ. Поддерживается (в пределах беседы) порядок и корреляция сообщений, нет нужды прибегать к дополнительному программированию для поддержки транзакций, синхронизации и блокировкам при одновременной обработке очереди с нескольких потоков, резервного копирования и пр., т.к. все это является штатной функциональностью SQL Server, а очереди в сервис-брокере построены на основе таблиц. То есть данные сообщения и транзакционные бизнес-данные в случае SQL Server имеют одинаковую природу и хранятся вместе, что разом снимает массу головной боли, присущей архитектуре MSMQ, вообще всем очередникам общего назначения. Однако это накладывает свою специфику - сервис-брокер есть составная часть SQL Server и работает только с ним. Это не есть излишне строгое ограничение, поскольку SQL Server является нынче неотъемлемым атрибутом каждого уважающего себя разработчика. Кстати, все уже поставили себе 2010 СТР2 (http://technet.microsoft.com/en-us/evalcenter/ee315247.aspx)? Сравнение сервис-брокера с MSMQ можно посмотреть, например, здесь - http://www.devx.com/dbzone/Article/34110.

SQL Server 2008 R2 CTP2 - http://technet.microsoft.com/en-us/evalcenter/ee315247.aspx.