Обычно таким пользователям приходится периодически синхронизировать свои данные с центральной базой, чтобы обеспечить непротиворечивость данных в масштабах предприятия. Одновременное внесение изменений в разные копии баз данных пользователями, находящимися в центральном офисе, и разъездными агентами, что вполне возможно в жизни, усугубляет и без того сложную ситуацию в распределенной системе. Прибавьте к этому скорость работы модемов в гостиничных номерах, и вы поймете, что вас ожидает в будущем.
SQL Server 7.0 добавляет репликацию слиянием к уже имевшимся в SQL Server 6.5 двум видам репликаций: снимкам данных и репликациям транзакций. Хотя репликация слиянием сложнее других видов репликации, она лучше всего подходит для распределенной среды. Из трех видов репликации слияние предоставляет самый высокий уровень автономности. Издатели данных и подписчики могут работать совершенно независимо и лишь периодически связываться для объединения результатов. Если возникает конфликт из-за того, что пользователи из разных мест пытаются изменить один и тот же элемент данных, то он разрешается автоматически. Это делает репликацию слиянием оптимальным решением для территориально разветвленных приложений, в которых пользователям необходим полный доступ по записи/чтению к локальным копиям данных. В предлагаемой статье мы расскажем об одном решении, которое было предложено заказчику, и поясним, как пользоваться мастером репликаций для их конфигурирования.
Представление начинается
 |
| ЭКРАН 1. Просмотр модифицированной схемы базы данных Pubs. |
Пользователям нужны только те данные, за которые они отвечают. Синхронизируя данные, они могут либо получить новые, либо потерять имеющиеся в соответствии со своим идентификатором в таблице field_user. Поэтому было необходимо отфильтровывать данные в таблице field_user по идентификаторам пользователей и обеспечивать возможность вставки и удаления строк в соответствующих таблицах. Кроме того, нужно было поддерживать синхронизацию изменений в базах данных руководства и пользователей. Мы полагали, что все эти требования могут быть выполнены с помощью репликации слиянием, ее динамической фильтрации с соединением таблиц и за счет механизма разрешения конфликтов.
 |
| ЭКРАН 2. Определение местоположения. |
Для демонстрации клиенту желаемой функциональности использовалась пробная база данных Pubs с целью имитации оперативного окружения. Мы добавили в нее таблицу field_user, которая связывала пользователей с событиями. На Экране 1 показана диаграмма части модифицированной базы данных Pubs, в которую входят таблица field_user и связанные с ней таблицы. Используя эту структуру, мы приступили к демонстрации нашему клиенту возможностей комбинирования динамической фильтрации и фильтрации соединением в репликации слиянием.
Механика слияния
Первым делом были созданы таблицы в базе данных. В Листинге 1 приведены операторы SQL для создания этих таблиц. До назначения издателя необходимо определить для него распространитель. В качестве распространителя может выступать как локальный, так и удаленный сервер. В данном случае для конфигурирования сервера в качестве издателя и распространителя использовался мастер-конфигуратор издания и распространения (Configure Publishing and Distribution Wizard). Для запуска мастера-конфигуратора следует выбрать и дважды щелкнуть кнопкой мыши сначала на группе сервера, а затем на сервере. В меню инструментов (Tools) выберите Replication (репликацию), затем щелкните на пункте Configure Publishing and Subscribers (Конфигурирование издания и подписки).
 |
| ЭКРАН 3. Выбор типа публикации. |
На следующем шаге выдается подсказка: определить местоположение базы данных распространения и файла журнала или принять значения, предлагаемые по умолчанию, как на Экране 2. Затем в следующем диалоговом окне следует нажать кнопку Finish (закончить), чтобы разблокировать как распространитель, так и издатель. Заметим, что, выбрав сервер в качестве распространителя, пользователь отдает дополнительное дисковое пространство сервера под базу данных распространения и под снимки издания. Агенты репликации, работающие на сервере, дополнительно расходуют процессорное время.
После установления издателя и распространителя следует приступить к работе с монитором репликации (Replication Monitor). Используя это средство, можно следить за текущей работой и за историей заданий каждого агента репликации. Теперь все готово для создания публикаций.
 |
| ЭКРАН 4. Отбор статей. |
Для запуска мастера создания публикаций щелкните кнопкой мыши на издателе (Publisher). В пункте Replication (репликации) меню инструментов (Tools) выберите Create and Manage Publications (Создание и управление публикациями). В списке баз данных и публикаций выберите базу, из которой собираетесь сделать публикацию, затем нажмите кнопку Create Publication (Создать публикацию), и перед вами появится начальное диалоговое окно мастера создания публикаций (Create Publication Wizard). Для продолжения нажмите кнопку Next (далее). На экране выбора типа публикации (Choose Publication Туре) выберите публикацию слиянием (Merge), как показано на Экране 3. Следующее диалоговое окно позволит вам определить типы подписчиков. В нашем случае все подписчики используют SQL Server. Как показано на Экране 4, окно выбора статей (Specify Articles) дает возможность отобрать все или некоторое подмножество статей (таблиц) для публикации. Причем подписаться можно только на публикацию, а не на отдельную статью в ней.
 |
| ЭКРАН 5. Добавление в таблицу индекса и столбца rowguid. |
SQL Server изменяет схему базы данных при публикации таблицы под управлением репликации слиянием: он вводит столбец с уникальным идентификатором для каждой реплицированной строки таблицы. Этот столбец однозначно идентифицирует строку каждой копии таблицы. Если таблица уже содержит столбец uniqueidentifier со свойством ROWGUIDCOL, то SQL Server автоматически использует его для идентификации строки реплицированной таблицы. В противном случае он добавляет в таблицу столбец uniqueidentifier (со свойством ROWGUIDCOL). Как показано на Экране 5, SQL Server добавляет индекс и столбец rowguid.
После отбора статей мастер напоминает пользователю о необходимости дать публикации название и снабдить ее кратким описанием, как показано на Экране 6. Далее в публикацию встраиваются свойства динамической фильтрации и фильтрации слиянием. Для внедрения фильтрации следует
 |
| ЭКРАН 6. Ввод названия и описания. |
 |
| ЭКРАН 7. Активация динамических фильтров. |
Следующий шаг ведет к созданию фильтров с соединением. Эти фильтры позволяют расширить фильтрацию: отбирать строки не только в одной таблице, но и в связанных с ней таблицах. Мы уже проводили горизонтальную фильтрацию таблицы field_user для публикации. Нам хотелось бы включить в публикацию и другие таблицы, которые содержат данные, связанные с данными в таблице field_user. Однако публиковать эти таблицы полностью нежелательно. Фильтры с соединением позволяют включать только те строки, которые пользователь определит как относящиеся к публикации. На Экране 9 показано, что мастер автоматически определяет необходимые соединения для всех связанных таблиц.
Следующий экран позволяет допустить к публикации анонимных или полномочных подписчиков. Мы выбрали полномочных подписчиков, поскольку хотели ограничить доступ к публикации, разрешив его только квалифицированным выездным представителям. Далее, диалоговое окно дает возможность установить расписание для процесса создания снимков. Мастер автоматически создает и запускает задания в соответствии с этим расписанием. Чтобы подписчик мог участвовать в процессе репликации слиянием, необходимо задать начальное состояние подписки. Таблицы
 |
| ЭКРАН 8. Автоматическая генерация фильтров. |
Теперь можно нажать кнопку Finish (закончить). Мастер создаст публикацию, основываясь на выбранных вами опциях, и выведет на экран диалоговое окно Create and Manage Publications (Создание и управление публикациями), в котором под базой данных Pubs имеется значок, показывающий новую, только что созданную статью pubs_merge.
Со стороны подписчика
Теперь настало время взглянуть на репликацию с другой стороны — с позиции подписчика. Эта часть репликации снабжена подробными объяснениями, мастер активной подписки (Pull Subscription Wizard) помогает пользователям
 |
| ЭКРАН 9. Фильтрация строк таблицы. |
Списки доступа к публикации. SQL Server позволяет определить, кто имеет право доступа к публикации. Он создает PAL с идентификаторами входа по умолчанию, но в этот список можно добавлять новые значения и удалять из него имеющиеся. С помощью меню инструментов (Tools) можно просматривать и модифицировать свойства публикации. Для этого следует: выбрать в меню Replication (репликацию); нажать пункт Create and Manage Publications (Создание и управление публикациями); выбрать нужную публикацию и щелкнуть мышью на пункте Properties and Subscription (Свойства и подписка); в диалоговом окне Properties (свойства) нажать кнопку Publication Access List (Список доступа к публикации). Как показано на Экране 10, мы добавили в список идентификаторы входа всех «выездных» представителей.
 |
| ЭКРАН 10. Добавление идентификаторов входа в список PAL. |
Безопасность входа в систему. Безопасность входа в систему обеспечивается в репликации путем запроса идентификатора входа и пароля пользователя при соединении с издателем, распространителем или подписчиком. Агенты репликации, действующие под управлением серверного агента SQL Server Agent, применяют ассоциированные идентификаторы входа и пароли для соединения с различными объектами репликации и для исполнения своих ролей в процессе синхронизации. На платформах Windows 9x, которые применяются нашим заказчиком на клиентской стороне, агенты репликации и SQL Server Agent используют учетную запись пользователя, входящего в Windows. На платформе NT агенты репликации действуют под идентификатором входа или контекстом безопасности службы SQL Server Agent.
Критерии динамической фильтрации, базирующиеся на идентификаторе входа, подходят для подписчиков Windows 9x, но не для подписчиков NT. Для последних необходимо изменить свойства входа в систему агента слияния (Merge Agent) таким образом, чтобы он работал с учетной записью
 |
| ЭКРАН 11. Выбор свойств активной подписки. |
Если вам приходится иметь дело с разъездными торговыми представителями, хранилищем данных или другим распределенным приложением, то репликация станет краеугольным камнем в организации быстрой и надежной доставки данных в масштабах всего предприятия. SQL Server 7.0 предоставляет разнообразные масштабируемые решения репликации, которые могут удовлетворить самый широкий спектр информационных требований.
Об авторах
Тед Дейли — старший консультант компании CIBER, специализирующей на решениях в области хранилищ данных и систем бизнес-интеллекта. Имеет сертификаты MCSE, MCDBA, MCT. С ним можно связаться по электронной почте по адресу tdaley@ciber.comБоб Пфейф — сотрудник компании CIBER. Имеет сертификаты MCSE, MCSD, MCDBA, MCT и SQL Server MVP. Обладает значительным практическим опытом в построении решений в области хранилищ данных, архитектуры клиент-серверных приложений и оптимизации их производительности. С ним можно связаться по электронной почте по адресу bpfeiff@ciber.comЛистинг 1. Создание таблиц.
CREATE TABLE [dbo].[authors] ( [au_id] [id] NOT NULL , [au_lname] [varchar] (40) NOT NULL , [au_fname] [varchar] (20) NOT NULL , [phone] [char] (12) NOT NULL , [address] [varchar] (40) NULL , [city] [varchar] (20) NULL , [state] [char] (2) NULL , [zip] [char] (5) NULL , [contract] [bit] NOT NULL , ) GO CREATE TABLE [dbo].[events] ( [event_id] [char] (4) NOT NULL , [event_name] [varchar] (40) NULL , [event_descr] [char] (10) NULL , [event_mgnr] [char] (10) NULL , ) GO CREATE TABLE [dbo].[field_user] ( [rep_id] [varchar] (50) NOT NULL , [event_id] [char] (4) NOT NULL , ) ON [PRIMARY] GO CREATE TABLE [dbo].[publishers] ( [pub_id] [char] (4) NOT NULL , [pub_name] [varchar] (40) NULL , [city] [varchar] (20) NULL , [state] [char] (2) NULL , [country] [varchar] (30) NULL , ) GO CREATE TABLE [dbo].[sales] ( [event_id] [char] (4) NOT NULL , [ord_num] [varchar] (20) NOT NULL , [ord_date] [datetime] NOT NULL , [qty] [smallint] NOT NULL , [payterms] [varchar] (12) NOT NULL , [title_id] [tid] NOT NULL , ) GO CREATE TABLE [dbo].[titleauthor] ( [au_id] [id] NOT NULL , [title_id] [tid] NOT NULL , [au_ord] [tinyint] NULL , [royaltyper] [int] NULL , ) GO CREATE TABLE [dbo].[titles] ( [title_id] [tid] NOT NULL , [title] [varchar] (80) NOT NULL , [type] [char] (12) NOT NULL , [pub_id] [char] (4) NULL , [price] [money] NULL , [advance] [money] NULL , [royalty] [int] NULL , [ytd_sales] [int] NULL , [notes] [varchar] (200) NULL , [pubdate] [datetime] NOT NULL , ) GO
За кулисами
Репликации не относятся к внешним средствам, они встроены непосредственно в SQL Server 7.0 и SQL Server Enterprise Manager. Для внедрения репликаций можно использовать хранимые процедуры или распределенные объекты управления SQL-Distributed Management Objects (SQL-DMO). Но если у пользователя нет каких-то специфических требований, гораздо удобнее обратиться к мастеру создания публикаций (Create Publication Wizard).
Для распространения данных SQL Server использует модель «издатель-подписчики». Издатель (исходная база данных) делает данные доступными для подписчиков. Репликация создает распространитель, который управляет движением данных между издателем и подписчиками. При этом необходимо найти компромисс между автономией сайтов и задержкой изменения данных у издателя и подписчиков. Баланс устанавливается с учетом требований распределенной среды передачи.
Статьи, базирующиеся на таблицах, определяют подлежащие публикации данные. Хотя публикации могут состоять из множества статей, при подписке учитываются не статьи, а только публикации. После того как будет создана подписка, происходит синхронизация подписчика и издателя. Обычно она выполняется с помощью снимка исходного состояния данных. Сценарии SQL и утилита копирования массивов создают у подписчика таблицу для статьи и загружают в нее снимок данных издателя. Агент подготовки снимков соединяется с издателем и записывает схему таблицы каждой статьи в файл .sch у распространителя. Если индексы и компоненты декларативной ссылочной целостности (DRI) также подлежат репликации, то агент помещает выбранные индексы в файл с расширением .idx, находящийся у распространителя. Если все подписчики являются машинами базы данных SQL Server, то снимок данных хранится в файле формата .bcp. Если же какой-либо подписчик представляет собой иное хранилище данных, то снимок сохраняется в символьном режиме в файле формата .txt. Пара файлов .sch и .bcp выступает как синхронизирующий набор, отвечающий состоянию таблицы в заданный момент времени. Каждая статья публикации имеет свой синхронизирующий набор, чьи файлы помещаются в подкаталог рабочего каталога распространяемой базы данных.
Следует помнить о том, что каталоги, в которых хранятся файлы репликации, по умолчанию не охраняются. Разработчики Microsoft рекомендуют применять дискреционный контроль доступа в разделяемую область универсальной конвенции имен (UNC), которую распространитель использует для хранения файлов снимков данных (по умолчанию <диск> $ имя пути <компьютер><диск>$Mssql7Repldata). Эта разделяемая область UNC является административной, или скрытой. Создайте явную неадминистративную область по указанному пути. Если сервер распространителя работает под Windows 9x, то папка снимков по умолчанию использует <диск> без разделяемой области и путь <диск>:Mssql7Repldata. Для создания на сервере Windows 9x подписки с пассивной рассылкой (при такой рассылке подписчики сами обращаются за данными по указанному адресу) необходимо сделать папку разделяемой, т. е., разрешить доступ к ней как издателю, так и подписчикам. Агентам репликации нужны соответствующие разрешения на запись и чтение файлов в каталоге во время процесса репликации. Если папка со снимками разделяется некорректно или присвоены неправильные права на каталог, то репликации не произойдет. В Windows 9x агент SQL Server и агенты репликации с точки зрения безопасности имеют полномочия пользователя, входящего в Windows. На платформе NT установки по умолчанию позволяют агентам репликации выступать от лица сервисов SQL Server Agent. Однако можно создать такую конфигурацию агентов, что они будут входить в систему под отдельными идентификаторами. В примере с нашими клиентами для обеспечения правильной динамической фильтрации необходимо выполнить конфигурацию агента слияния (Merge Agent) так, чтобы он входил в систему с бюджетом удаленного пользователя, если разъездные агенты работают с переносными компьютерами на платформе NT.
Для слияния публикаций используется система приоритетов, применяемая для разрешения конфликтов между подписчиками при модификации данных. Если два или более подписчиков пытаются одновременно изменить данные, то преимущество получает подписчик с наивысшим приоритетом, и он может внести изменения. Можно назначить приоритеты индивидуально каждому подписчику или управлять ими у издателя. Очевидно, что если все будут пытаться одновременно изменить одни и те же данные, то предлагаемое разрешение конфликтов может сбить с толку. Как в любой распределенной системе, чем яснее организовано владение данными, тем лучше. Хотя репликация слиянием рассчитана на обработку конфликтов, ситуация, когда многие пользователи постоянно обновляют большие наборы данных, быстро может стать неуправляемой. Поэтому во избежание конфликтов мы советуем публиковать только необходимый минимум и поддерживать четкое разграничение принадлежности данных.