SQL Server 2000 предлагает пользователям и администраторам множество различных средств обмена данными между самыми разнообразными системами с постоянным физическим соединением друг с другом или без него. В SQL Server 2000 имеется мощное средство обмена данными - репликация. Механизмы репликации данных представляют серверам SQL Server 2000 мощный фундамент для создания распределенных систем хранения информация с использование ODBC или OLE DB. Автоматическая синхронизация изменений (при постоянном физическом соединении или без него), сделанных на одном сервере, со всеми другими серверами делает возможным создание на основе SQL Server 2000 больших распределенных систем хранения информации, удовлетворяющих самым высоким современным требованиям.
Система репликации SQL Server 2000 основывается на технологии Replication Distribution Interface. Эта технология позволяет включать в репликацию данных не только серверы SQL Server 2000, SQL Server 7.0 или SQL Server 6.x, но и другие системы хранения и обработки данных, например, Microsoft Access, Oracle, dBase, Paradox. С помощью подсистемы репликации администратор может создать распределенные гетерогенные системы масштаба предприятия.
Репликация - это совокупность механизмов SQL Server 2000, обеспечивающих отображение изменений данных, сделанных на одном сервере, на другие серверы. Подсистема репликаций организована в виде специализированных агентов, выполняемых на сервере, как самостоятельный процесс. Эти агенты подключаются к серверам - участникам репликации и выполняют создание копий данных и тиражирование их между другими серверами. В зависимости от используемого типа репликаций и функции сервера набор агентов на конкретном SQL Server 2000 может сильно различаться.
Начало активного применения репликации данных было положено появлением версии SQL Server 6.0. Модель репликации базируется на метафоре "опубликуй и подпишись" - Publish and Subscribe, введенных в том же SQL Server 6.0. Терминология репликаций использует понятие издатель - Publisher, дистрибьютор - Distributor, подписчик - Subscription.
Термин издатель употребляется для обозначения серверов, которые представляют информацию из своих баз данных другим серверам. Дистрибьютор - промежуточный сервер, принимающий данные от издателя и распространяющий их подписчикам. Подписчик- это сервер, копирующий информацию, предоставляемую издателем. Введение промежуточного звена в процессе репликации позволяет снять нагрузку с основных серверов, публикующих информацию. Кроме того, в некоторых случаях - это позволяет повысить производительность за счет снижения сетевого трафика и использования выделенного сервера. Помимо уже упомянутых терминов при обсуждении репликации используется еще несколько:
публикация - представляет собой набор статей. Подписчик может подписаться только целиком на публикацию . Одна публикация способна включать статьи, принадлежащие одной базе данных. Чтобы представить данные из нескольких баз данных придется создать отдельную публикацию в каждой из них.
статья - статьей называется минимальный набор данных, рассматриваемый системой репликации как одно целое. Статья представляет собой таблицу или какую-то ее часть. Если необходимо выполнить тиражирование не всей таблицы, а только ее фрагмента, то необходимо использовать фильтрацию:
- использование вертикального разделения, при которой в статью не включается одна или более колонок исходной таблицы;
- использование горизонтального разделения, когда на строки, включаемые в статью, накладывается одно или более условий с помощью конструкции where (рисунок 1).
Рисунок 1 - Горизонтальная и вертикальная фильтрация.
Издателем в терминологии системы репликации SQL Server 2000 называется сервер, который предоставляет (публикует) расположенную на нем информацию другим серверам. Администратор конфигурирует на издателе публикацию, включающую одну или более статей. Для публикации устанавливается список пользователей, имеющих право копировать ее себе. На каждую публикацию могут подписаться один или более подписчиков, т.е. данные издателя могут быть отображены на множество других серверов - подписчиков. В свою очередь любой из серверов - подписчиков являться издателем для других серверов. Такой подход позволяет создавать сложные разветвленные информационные системы, наиболее оптимальным образом использующие сетевые соединения (рисунок 2).
Рисунок 2 - Схема распространения публикаций.
В функции издателя входит не только создание публикации, содержащей мгновенную копию информации базы данных, но, возможно, в зависимости от типа репликации, и постоянное отслеживание изменений, вносимых в данные пользователями. Периодически издатель может подготавливать либо новую полную копию публикуемых данных, либо только внесенные изменения.
В некоторых типах репликации подписчики в свою очередь также могут вносить изменения в полученные от издателя данные. Простейший тип репликаций - репликация моментальных снимков. При этом изменение в данные могут вноситься только на издателе. Более сложные типы репликации допускают модификацию данных и на подписчиках. При этом система репликации автоматически отражает изменения, сделанные на издателе или на одном из подписчиков на все серверы - участки репликации.
Подписчиком называется сервер, который принимает данные от издателя. Этот сервер подписывается на одну или более публикаций и единожды или периодически копирует опубликованные данные. Один подписчик может получить данные от множества издателей. Если учесть, что подписчик может выступать и в качестве издателя, то такой подход позволяет создавать сложные разветвленные системы распространения информации.
Важным моментом является то, что данные могут изменится не только на издателе, но и на подписчике. Эта возможность появилась еще в SQL Server 7.0 и стала более функциональной в SQL Server 2000. Процесс изменения данных на подписчике не так прост, как кажется на первый взгляд. Если данные изменяются только на издателе, ситуация достаточно проста. Подписчики не могут вносить изменения, они должны лишь принимать изменения, сделанные на издателе. Изменение данных только на одном севере исключает возможность исключает возможность возникновения конфликтов изменений. Если же изменения в данные разрешено вносить и на подписчиках, то появление конфликтов изменения данных неизбежно. Предположим, что два пользователя пытаются одновременно исправить одну и тоже строку таблицы, причем значения, устанавливаемые пользователем различны. SQL Server 2000 должен каким-то образом решить этот конфликт, так как существование двух различных состояний для одних и тех же данных крайне нежелательно .Для решения подобных конфликтов в SQL Server 2000 существует три различных метода:
1. Репликация сведением - это самый сложный тип репликации. В этом случае допускается нахождение одних и тех же данных в нескольких различных состояний. То есть каждый из серверов - участников репликации может иметь свое собственное значение для одной и той же строки. Для решения этой проблемы используется система приоритетов, в соответствии с которой решается, данные какого из сервера должны быть тиражированы на все другие серверы.
2. Подписчики незамедлительного обновления - эта технология позволяет избежать появления различных состояний для одних и тех же данных. Перед тем, как на подписчике будут выполнены изменения, исправленные данные сравниваются с исходными данными на издателе. Если значения на подписчике и издателе совпадают, то изменения разрешаются. Причем изменение данных выполняется сразу и на подписчике и на издателе.
3. Отложенное обновление - эта технология, как и репликация сведением, допускает наличие на различных серверах нескольких состояний одних и тех же данных, однако, в конце концов, все изменения объединяются и из них остается только одно. Выбор этого изменения осуществляется в соответствии с правилами, установленными при создании соответствующей публикации.
Весь смысл репликации в том, что данные на подписчике должны являться копией данных издателя. Ни администратор, ни пользователи не должны прилагать усилия для распространения этих изменений. Вся работа по синхронизации данных ложится на SQL Server 2000. Возникает вопрос, каким образом издатель и подписчик договариваются о времени распространения изменений? В SQL Server 2000 существует два различных метода обновления информации на подписчиках.
1.Принудительная репликация - в этом случае подписчик играет пассивную роль, он лишь ждет, когда дистрибьютор скопирует ему новую порции данных. Вся работа по обновлению данных ложится на сервер дистрибьютор, который сам должен установить соединение и выполнить все необходимые операции. Этот метод хорошо подходит для систем, в которых подписчик и дистрибьютор имеют постоянное соединение. Изменения данных могут быть распространены сразу же после того, как они были внесены. Процесс распространения данных может быть непрерывным. Интервалы обновления подписчика устанавливаются на дистрибьюторе, и администратор может централизовано управлять скоростью распространения изменений.
2.Репликация по запросу - этот метод обновления предполагает, что вся работа по обновлению данных ложится на сервер-подписчик, который через определенные интервалы подключается к дистрибьютору и копирует с него новую порцию данных. Дистрибьютор подготавливает для каждого подписчика набор данных, отображающий все изменения, сделанные на издателе со времени последнего подключения этого подписчика. Репликация по запросу активно применяется мобильными пользователями и на серверах, не имеющих постоянного соединения с дистрибьютором. Такой метод репликации позволяет выполнять синхронизацию данных не только через определенные интервалы, но и в удобное для пользователя время. Мобильные пользователи могут всего на несколько минут подключится к дистрибьютору и затребовать у него изменения. Кроме того, репликация по запросу позволяет разгрузить сервер - дистрибьютор. При работе в системе, в которой сконфигурировано большое количество мобильных пользователей, можно добиться заметного повышения производительности системы репликации.
Дистрибьютором называется сервер, являющийся промежуточным звеном между издателем и подписчиком. Роль дистрибьютора сводится к сбору всей информации, которая должна быть скопирована подписчиком от издателя. Применение дистрибьютора в системе репликаций позволяет гибко управлять загрузкой серверов. В качестве дистрибьютора может быть сконфигурирован как отдельный сервер, так и сервер, являющийся издателем или подписчиком. Если объем копируемой информации не значителен, то дистрибьютор можно установить на издателе. При повышении объема тиражируемой информации, использование отдельного компьютера для работы дистрибьютора может повысить производительность всего процесса репликации в системе.
Дистрибьютор поддерживает специальную базу данных распределения, в которой хранится информация обо всех подписчиках и издателях. Это база данных Distribution. Для каждого издателя в ней хранится информация о сконфигурированных на нем публикации, их типе и параметрах статей в каждой публикации. Для подписчиков хранится список статей, на которых он подписан, информация о расписании обновления, времени последней синхронизации и другие сведения. Кроме того, в базу данных распределения при репликации сведением стекается информация обо всех, производимых на подписчиках и издателях, изменениях. Специальный агент затем анализирует эту информацию и выполняет сведение множества данных в один блок.
Правильное применение дистрибьютора может существенно снизить сетевой трафик и затраты времени на синхронизацию серверов. Предположим, что организация имеет множество филиалов, удаленных на значительное расстояние. В некоторых крупных городах имеется по несколько филиалов. В центральном офисе располагается база данных, информация из которой должна быть скопирована на сервере филиала. Все серверы SQL Server 2000 связаны в единую сеть с помощью дорогих, но медленных наземных коммуникаций. Для распространения данных служит система репликаций. При выборе места размещения дистрибьютора сначала приходит решение установить его в центральном офисе. Действительно, в этом случае можно обойтись единственным дистрибьютором, который будет обслуживать всех подписчиков. Но следует обратить внимание, что серверы связаны посредством медленных наземных соединений. При таком подходе неизбежна многократная передача информация в города, имеющих несколько филиалов. Лучшим решением будет установка дистрибьютора в городе с нескольким подписчиками. В этом случае достаточно единожды скопировать данные из центрального офиса, а затем распространить их между всеми подписчиками в городе по недорогим и быстрым каналам местной связи. На ряду с финансовой выгодой такой подход может повысить скорость распространения изменений на все серверы информационной системы.
Система репликаций SQL Server 2000 реализована в виде специализированных агентов, выполняемых как самостоятельные процессы в контексте SQL Server 2000. В зависимости от типа репликаций, функции агента могут изменяться вплоть до перемещения места запуска SQL Server 2000. Агенты репликации анализируют изменения, сделанные на подписчиках и издателях, подготавливают пакеты данных, копируют их подписчикам, решают конфликты изменений и т.д. Каждый из агентов репликаций выполняет определенную роль. В процессе репликации участвует как минимум два агента.
Приведем список агентов подсистемы репликаций SQL Server 2000:
- Snapshot Agent;
- Log Reader Agent;
- Queue Reader Agent;
- Distribution Agent;
- Merge Agent.
Каждый из указанных агентов реализован как утилита командной строки. В пределах одного компьютера для всех инсталляций SQL Server 2000 предназначен общий набор агентов.
Основное предназначение агента Snapshot Agent заключается в создании файлов моментальных снимков. Моментальные снимки представляют собой полную копию данных, выбранных для публикации, в конкретный момент времени. Моментальные снимки используются в каждом типе репликации.
Независимо от типа репликации необходимо выполнить первоначальную синхронизацию подписчика и издателя. Подписчик должен быть приведен в тоже состояние, что и издатель. Для этого агент Snapshot Agent создает файл моментального снимка. Кроме того, если на подписчике нет структур данных (таблиц), в которые должна копироваться информация с издателя, то нужно предварительно создать ее. Это тоже выполняется автоматически. Snapshot Agent генерирует файл сценария, с помощью которого на подписчике можно выполнить создание таблицы с необходимой структурой.
Файлы моментальных снимков и файлы сценариев сохраняются на дистрибьюторе и оттуда копируются подписчикам. На этом работа Snapshot Agent может закончиться. Однако в случае репликации моментальных снимков агент Snapshot Agent используется постоянно.
Агент Log Reader Agent является основой репликации транзакций, запускается на дистрибьюторе и подключается к издателю. Затем он сканирует публикуемые таблицы и отслеживает строки, которые были изменены со времени последнего подключения. Эти строки отмечаются как обработанные и копируются в базу данных распределения Distribution. Из базы Distribution информация затем распространяется всем подписчикам.
В SQL Server 2000 появилась новая технология, позволяющая выполнять изменение данных на подписчиках - отложенное изменение. Работа этой технологии базируется на помещении выполненных на подписчике изменений в специальную очередь. Информация в эту очередь отправляется всем серверам - подписчикам каждый раз, когда работающий на них пользователи вносят изменения в опубликованные данные.
Сделанные на подписчиках изменения должны быть отображены на издателе и других подписчиках. То есть необходимо забрать у каждого подписчика информацию об изменениях , обработать ее и сделать доступной всем другим участникам репликаций. Эти функции и выполняет агент Queue Reader Agent.
Агент Queue Reader Agent всегда запускается на дистрибьюторе. Причеа для подписчиков и издателей используется одна и та же копия агента. Основной задачей агента является считывание из очереди информации об изменениях опубликованных данных, которые предоставляют подписчики. Помимо считывания информации ,агент также выполняет применение полученных изменений на издателе и разрешение конфликтов обновления, возникающих при изменении одних и тех же данных более чем одним сервером - участником репликации.
Назначение агента Distribution Agent состоит в распространении изменений, собранных агентами Snapshot Agent и Log Reader Agent. Агент Distribution Agent подключается к подписчику и копирует ему данные из моментальных снимков или базы данных Distribution.
Агент Merge Agent применяется исключительно при работе с репликацией сведением. Это самый сложный тип репликации, появившийся в SQL Server 7.0. Репликация сведениями позволяет изменять данные не только издателю ,но и подписчику. Причем изменении вносятся таким образом, что не нужно постоянное соединение между издателем и подписчиком. Это выгодно отличает репликацию сведением от подписчиков незамедлительного обновления, для которых наличие соединения подписчика с издателем является обязательным.
Роль агента Merge Agent заключается в отслеживании изменений, сделанных на подписчиках в реплицированных с издателя данных. После того как подписчики получают моментальный снимок данных издателя, и будет выполнена первоначальная синхронизация, подписчики могут отключиться от дистрибьютора и вносить изменения автономно. Все выполняемые изменения автоматически фиксируются Merge Agent. При следующем подключении к дистрибьютору агент копирует ему все измененные данные. Таким образом, остальные подписчики и сам издатель могут получить измененные данные.
В SQL Server 2000 применяются три следующих базовых типа репликации:
- Snapshot Replication - репликация моментальных снимков;
- Transactional Replication -репликация транзакций;
- Merge Replication - репликация сведением.
Между перечисленными типами существует довольно значительная разница. Кроме того, базовые возможности некоторых типов репликации могут быть расширены, если разрешить выполнение изменений данных на подписчиках. При использовании указанных типов репликации в "чистом" виде изменение данных на подписчиках будет разрешено только при помощи репликации сведением. Однако при работе с репликацией моментальных снимков и репликации транзакций также допускается выполнение изменений со стороны подписчиков. Для реализации этой возможности необходимо использовать дополнительные технологии:
- Immediately-Update Subscribers - подписчики незамедлительного обновления;
- Queue Updating - отложенное обновление.
Чтобы решить, какой тип репликации необходим в том или ином случае, нужно четко предоставлять, какие возможности предоставляет каждый из них.
Самым простым типом репликации является репликация моментальных снимков. Свое название этот тип репликации получил за метод, которым данные распространяются подписчикам. Для тиражирования данных используются так называемые моментальные снимки.
Моментальный снимок представляет собой полную копию данных издателя, которые выбраны для репликации. Для каждой статьи производится выборка данных из исходной таблицы с учетом вертикальной и горизонтальной фильтрации. По завершении выборки для всех статей публикации полученная информация сохраняется в специальный файл - файл моментных снимков, который представляет собой копию реплицируемых данных издателя в конкретный момент времени -моментальный снимок.
Преимуществом репликации моментальных снимков является низкая загруженность процессора. Если для обеспечения работы других типов транзакций потребуется постоянное присутствие в памяти соответствующих агентов, то при работе с репликацией моментальных снимков этого не требуется, так как никакой анализ данных не происходит. Не нужно постоянно отслеживать изменения, вносимые пользователями в данные. В процессе репликации просто копируются все данные, включенные в публикацию. Но это является и недостатком. Если количество информации в базе данных значительно, то файлы моментальных снимков могут иметь очень большой размер. Загрузка сети будет расти пропорционально увеличению количества подписчиков. Передача файлов моментальных снимков всех подписчиков может занять слишком много времени. Изменение даже очень небольшой части данных приведет к необходимости доставки подписчикам всех публикуемых данных. Это препятствует частой синхронизации подписчиков с издателем, что, в свою очередь, ведет к снижению оперативности отображения изменений.
Достоинством репликации моментальных снимков является гарантия согласованности данных на издателе и подписчиках. Можно с уверенностью сказать, что данные на подписчике являются копией данных издателя. Высокая требовательность к каналу передачи данных ограничивает область применения репликации моментальных снимков. Ее обычно применяют в системах, в которых изменения вносятся очень редко или вообще не вносятся, а также в системах, оперативность отображения изменений в которой не играет большой роли, и поэтому допустима редкая синхронизация данных.
Лучшим примером системы "только для чтения" являются системы поддержки принятия решений. Эти системы хранят в основном историческую информацию, изменения в которую обычно не вносятся. Репликация сведением в этом случае является в этом случае лучшим вариантом тиражирования данных.
Более сложным типом репликации является репликация транзакций.. Репликация транзакций существенно отличается от репликации моментальных снимков. В основе ее работы лежит передача информации об изменениях данных. Для этого анализируется журнал транзакций базы данных, в которой создана публикация, и выполняется поиск записи, затрагивающих публикуемые данные.
Из журнала транзакций выбираются все транзакции, в ходе которых были выполнены команды изменения данных INSERT, DELETE, UPDATE. Полученная информация сохраняется в базе распределения Distribution на дистрибьюторе. При этом указывается информация о порядке выполнения транзакций. При выполнении синхронизации на подписчике применяются все транзакции, хранящиеся в базе данных Distribution. Причем в той же последовательности, в которой они происходили на издателе.
Как видно, по сети передаются только данные, которые были действительно изменены. Это позволяет резко повысить производительность репликации по сравнению с репликацией моментальных снимков. Кроме того, небольшой объем передаваемых данных позволяет очень оперативно отображать на подписчиках все изменения, сделанные на издателе. Обычно репликация транзакцией конфигурируется таким образом, что изменения отображаются в реальном времени или с минимальными задержкам(всего несколько секунд).
Естественно, для оперативного отображения изменений необходимо наличие постоянного соединения между издателем, подписчиком и дистрибьютором. Тем не менее, репликация транзакций может быть использован и для подписчиков, не имеющих постоянного соединения. Такие подписчики могут лишь периодически подключаться к дистрибьютору, например, раз в неделю, и обновлять свои базы. Конечно, в этом случае можно применять и репликацию Моментальных снимков, однако если база данных достаточно большая, а количество изменений не велико, то репликация транзакций обеспечит более экономную эксплуатацию каналов связи.
Репликация транзакцией хорошо зарекомендовала себя в локальных сетях, которые обеспечивают постоянное соединение и высокую пропускную способность. В этом случае изображения могут отображаться практически мгновенно.
Важным усовершенствованием механизмов репликаций в SQL Server 2000 по сравнению с предыдущими версиями стало появление репликации хранимых процедур. Репликация хранимых процедур позволяет подписчикам копировать не сами исправленные данные, а лишь информацию о том, как эти данные необходимо изменить. В рассмотренном ранне случае применение репликации хранимых процедур позволит избежать интенсивного обмена данными, ограничившись лишь передачи одной единственной команды UPDATE. Каждый из подписчиков должен будет применить эту команду к хранимым на нем данных. После выполнения хранимой процедура, данные на подписчике будут находится в том же состоянии, что и данные на издателе.
Репликация хранимых процедур является своего рода надстройкой над репликацией моментальных снимков и репликации транзакций. При создании публикации администратор может включить в нее одну или более хранимых процедур в качестве обычных статей. При выполнении репликации хранимых процедур в публикациях моментальных снимков сервер буде копировать все изменения данных, которые были произведены с помощью хранимой процедуры. Для копирования данных в этом случае используются те же алгоритмы, что и при обычной работе репликаций моментальных снимков. Для таблиц, которые изменяются реплицируемой хранимой процедурой, создаются файлы, моментальных снимков, файлы схемы и сценариев создания индексов, которые затем применяются на подписчиках.
Еще одним типом репликации является репликация сведением. Данный тип репликации позволяет подписчикам вносить изменения в данные без необходимости постоянного соединения с издателем. Каждый из подписчиков работает автономно и изменяет данные как хочет. Изменения данных могут накапливаться, а не копироваться сразу. Множество подписчиков способны беспрепятственно изменять одновременно одни и те же данные, что невозможно при использовании подписчиков незамедлительного обновления. Специальный агент отслеживает изменения, сделанные на каждом из подписчиков и при соединении с дистрибьютором объединяет эти изменения, выполненные другими участниками репликации. Репликация сведением является самым сложным типом репликации. Трудность состоит в отслеживании автономных изменений, сделанных каждым участником репликации, и их объединение в главную копию. Модификация данных выполняется автономно, поэтому не избежать конфликтов изменения. Механизмы репликации должны решить, какое из изменений должно быть оставлено, а какие - потеряны.