Тема 8
Репликация данных.
Цель: Познакомится с понятием назначение репликации. Изучить механизмы
репликации данных.
Вопросы лекции:
1.
Репликация данных
2.
Понятие
репликации данных
3.
Механизмы репликации
4.
Модели репликации
5.
Репликация транзакций
6.
Репликация хранимых процедур
1. Многие организации создают распределенные базы данных.
Основная база данных располагается в центральном офисе, куда стекается вся
информация со множества региональных филиалов. Часто эти филиалы географически
удалены, поэтому иногда- нецелесообразно или просто невозможно поддерживать
постоянное соединение- с центральным
сервером. Тем не менее,
пользователи должны постоянно иметь возможность, вводить и изменять информацию
в таблицах базы данных.
Механизмы репликации предоставляют мощные возможности
для распространения данных и выполнения хранимых процедур по всему предприятию.
Репликация позволяет делать копии данных, тиражировать эти копии на другие
серверы и автоматически синхронизировать изменения, внесенные в данные на
удаленных серверах, так что все копии данных на всех серверах будут находиться
в одинаковом состоянии. Использование репликации может значительно снизить
расходы во синхронизации данных между центральным сервером и региональным
представительством компании
Методы копирования данных можно разделить на две
группы. В первом случае необходимо периодически копировать данные из базы
данных и рассылать сделанные копии в региональные филиалы. В свою очередь,
каждый филиал может вносить изменения в свою копию данных. Затем все произведенные
изменения отправляются в центральный офис, там синхронизируются и снова
рассылаются по филиалам. Преимущество такого подхода - относительно низкие
затраты на пересылку данных, выполняемую либо с помощью электронной почты, либо
с помощью экспресс-почты (рассылка дискет или компакт-дисков). Недостатком
является большой промежуток времени, который должен пройти, прежде чем
изменения, сделанные в одном филиале, станут доступны в других филиалах. Этот
метод чаще всего используется при рассылке неизменяемых данных, например
прайс-листов.
Другой вариант предполагает использование постоянных
соединений между филиалами и центральным офисом. Изменения данных, выполняемые
пользователем в одном филиале, мгновенно становятся доступными пользователям-
в- центральном- офисе и других филиалах. Недостатком этого метода является
дороговизна использования выделенных каналов связи.
Репликация SQL Server 7.0 предлагает различные
методы копирования данных, охватывающие практически все возможные ситуации.
2. Как было
сказано ранее, репликация — это копирование данных, расположенных на одном
сервере, на один или несколько других серверов. SQL Server 7.0
поддерживает репликацию данных не только на другие SQL Server 7.0, но и
на серверы предыдущих версий, а также на СУБД сторонних производителей. Однако все имеющиеся возможности могут быть
реализованы только в том случае, если все
участники репликации являются серверами SQL Server 7.0.
Модель репликации SQL Server 7.0
базируется на метафоре «опубликуйте и подпишитесь» (publish and subscribe), введенной в SQL Server
6.0. В терминологии репликации для серверов — участников процесса тиражирования
данных используются термины «издатель» (Publisher), «дистрибьютор» (Distributor) и «подписчик» (Subscriber).
Помимо перечисленных термине» для обозначения
участников процесса тиражирования используются термины
«публикация» (Publication) и. «статья» (Article) для обозначения копируемых данных. Статья представляет собой таблицу или ее часть, выбранную для
тиражирования. Когда выбирается часть таблицы, используется либо вертикальное разделение (using a
vertical filter),
либо горизонтальное разделение
(using a
horizontal filter).
Вертикальное разделение ограничивает количество колонок таблицы, включенных в репликацию. Горизонтальное
разделение накладывает условие на выбираемые для тиражирования строки. Публикация представляет"
собой" набор статей, копируемых как одно целое между
сервером-издателем" и сервером-подписчиком.
Подписчик может подписаться только на всю публикацию. Подписка на отдельную
статью в публикации не поддерживается.
Издатель (publisher)
Издателем называется сервер, который предоставляет расположенные
на нем данные для копирования на другие серверы. Подобно настоящим издателю и
подписчикам для одного издателя может быть сконфигурировано множество
подписчиков. Таким образом, одна копия данных становится доступным множеству
серверов. Издатель может одновременно являться подписчиком по отношению к
другому издателю.
Помимо создания копии данных, издатель отслеживает
вносимые пользователями в локальную базу данных изменения и в зависимости от
конфигурации подготавливает, новую копию. Публикуемые данные могут иметь только
одного издателя, даже если они были впоследствии изменены подписчиком. В
зависимости от используемого метода репликации подписчики могут или не могут
вносить изменения в реплицированные данные. В простейшем случае (Snapshot Replication)
изменять данные может только издатель. При использовании более сложный моделей
репликации изменения могут вносить также и подписчики. Измененные данные
полученные от всех подписчиков, синхронизируются и объединяются с данными
издателя, а затем снова рассылаются всем участникам репликации, включая
издателя. Издатель поддерживает всю информацию о всех сконфигурированных на нем
статьях и публикациях.
Подписчик (subscriber)
Подписчиком называется сервер, копирующий предоставляемые
издателем данные. В качестве подписчика может выступать не только сервер SQL Server
7.0, но и SQL Server предыдущих версий, а также Microsoft Jet 4.0 Database (Microsoft Access), ODBC data source или OLE DB data source. Подписчик может быть
сконфигурирован в качестве' издателя для других подписчиков*. В отличие от
предыдущих- версий SQL Server, разрешавших изменение, данных только на издателе,
механизмы репликации SQL Server 7.0 разрешают, помимо издателя, пносип, изменения в
данные и подписчикам. Механизмы, используемые при изменении данных подписчиком,
иные, чем при выполнении изменений данных издателем.
В SQL Server 7.0 реализовано два различных механизма выполнения
изменений данных подписчиком:
o
использование репликации сведением (Merge Replication);
o
использование подписчиков незамедлительного обновления (Immediate Updating Subscribers).
Существует
два метода обновления вода
1.
Pull subscription (Репликация по запросу). Подписчик периодически подключается к дистрибьютору
и требует у него все изменения, сделанные со времени последнего подключения.
При наличии большого количества подписчиков использование репликации по запросу
позволяет снизить нагрузку на дистрибьютора. Кроме того, для мобильных
пользователей также рекомендуется использовать репликацию по запросу. В этом
случае они могут начать процесс репликации немедленно после подключения к сети,
а не дожидаться, пока дистрибъютер скопирует им данные. Использование
репликации по запросу позволяет
упростить процесс рассылки данных через
глобальные сети, например через Интернет. При этом подписчик инициирует начало
репликации в наиболее удобное для него время.
2.
Push subscription (Принудительная репликация). Дистрибьютор сам устанавливает соединение с
подписчиками и копирует им все необходимые данные. Использование этого метода
репликации рекомендуется для серверов, с которыми постоянно установлено
соединение. Изменения могут копироваться постоянно, немедленно после того, как
они произошли, или периодически на основе установленного расписания.
Администратор может централизованно управлять расписанием выполнения обновлений
на всех подписчиках.
Дистрибьютор
(distributor)
Дистрибьютором называется сервер, поддерживающий базу данных
распределения. Этот сервер исполняет роль посредника между издателем и
подписчиком. Дистрибьютор копирует себе все публикации, подготовленные
издателем, я тиражирует
скорость выполнения операций тиражирования данных за
счет снижения сетевого трафика.
В качестве дистрибьютора можно использовать как
выделенный сервер, так и сервер, сконфигурированный в качестве издателя или
подписчика. Конкретные функции, выполняемые дистрибьютором, зависят от
используемого метода репликации,
3. Механизмы репликации в SQL Server 7.0 реализованы в виде специализированных агентов,
запускаемых в зависимости от выполняемых ими функций на подписчике, издателе
или дистрибьюторе. Эти агенты устанавливают соединения с серверами и выполняют
копирование данных и отображение произведенных операций в системных таблицах и
специальных колонках пользовательских таблиц. В процессе репликации могут
принимать участие два или более агентов из следующего списка: Snapshot Agent; Log Reader Agent;
Distribution
Agents Merge Agent.
Агенты репликации работают как часть службы SQL Server Agent Поэтому для успешного выполнения копирования данных
следует убедиться, что служба SQLServerAgent
запущена Рекомендуется установить автоматический запуск этой службы при запуске
операционной системы
Snapshot Agent
Snapshot Agent подготавливает структуру данных и файлы, содержащие
выбранные для репликации данные. Генерируемый этим агентом файл данных
называется моментальным снимком Snapshot. Независимо от используемого метода репликации
необходимо выполнить первоначальную синхронизацию баз данных на дистрибьюторе,
откуда он затем копируется всем сконфигурированным подписчикам.
Snapshot Agent
постоянно используется при репликации моментальных снимков . При выборе других
методов он используется только для первоначальной синхронизации. Для каждой
публикации используется свой собственный Snapshot Agent, запускаемый на дистрибьюторе и подключающийся к
издателю для создания моментального снимка.
Log Reader Agent
Этот агент используется при репликации транзакций. Он
запускается на дистрибьюторе и подключается к издателю. Log Reader Agent копирует помеченные для репликации транзакции в базу
дистрибьютора, откуда транзакции копируются всем подписчикам. Каждая публикация
имеет своего агента Log Reader Agent, который
подключается к издателю и копирует из журнала те транзакции, которые были
сделаны после последней операции копирования.
Distribution Agent
Distribution Agent устанавливает соединение с подписчиком и копирует ему расположенные на
дистрибьюторе данные подготовленные Snapshot Agent и Log Reader Agent . Если же
поддержка подписчиков незамедлительного обновления не сконфигурирована,
используется общий Distribution Agent. При
использовании репликации по запросу (pull subscription) Distribution Agent запускается на
подписчике. Если же используется принудительная репликация (pull subscription), то агент запускается на дистрибьюторе.
Merge Agent
Применяется при репликации сведением (merge replication). Он отслеживает изменения, сделанные на подписчике
со времени копирования снимка с издателя. Сделанные на всех подписчиках и
издателе изменения собираются агентом, объединяются и затем тиражируются между
всеми участниками репликации. Кроме того, Merge Agent отслеживает конфликты изменений, возникающие при
изменении одной строки несколькими подписчиками. Такие конфликты, решаются с
помощью шкалы приоритетов, установленной для каждого подписчика.
Данные при использовании репликации и сведением могут
перемещаться в обоих направлениях (сначала от подписчика к издателю, а затем
обратно) или однонаправлено (только от подписчика к издателю). Каждая
публикация репликации сведением имеет свой собственный Merge Agent, который
устанавливает соединение как с издателем, так одновременно со всеми
подписчиками. После синхронизации всех копий данных Merge Agent тиражирует обновленную копию всем участникам
репликации – издателю и всем подписчикам. При использовании принудительной
репликации сведением Merge Agent запускается на издателе. При конфигурировании
репликации сведением по запросу Merge Agent запускается на подписчике.
4. SQL сервер
поддерживает несколько видов репликации:
o
Snapshot Replication репликация моментальных
снимков;
o
Transactional Replication- репликация транзакций;
o
Merge Replication-
репликация сведением.
Репликация моментальных снимков.
Это самый простой вид репликации. Моментальный снимок
представляет собой полную копию данных, выбранных для репликации. При
использовании репликации моментальных снимков полная копия тиражируемых данных
рассылается всем подписчикам Этот тип
репликации характеризуется малой загрузкой процессора, так как нет
необходимости в анализе таблиц для отбора новых или измененных данных.
Недостатком является значительная загрузка сети при работе с большими базами
данных. При внесении даже небольшого количества изменений будут передаваться
все данные в репликацию.
Репликация моментальных снимков
гарантирует согласованность данных между издателем и подписчиком. Так как этот тип репликации требует
наличия мощного канала для передачи данных, Snapshot Replication часто используется для копирования редко обновляемых
данных, «свежесть» которых не актуальна. Если
данные на издателе не обновляются, то после выполнения репликации подписчики
могут полностью отсоединиться от
сети и работать самостоятельно.
Рисунок 1. Дистрибьютор. Репликация моментальных
снимков.
Как показано на рисунке 1, репликация моментальных
снимков выполняется двумя агентами — Snapshot Agent и Distribution Agent.
Каждый раз, когда запускается Snapshot Agent, он подготавливает файл данных моментального снимка (snapshot File), который впоследствии будет копироваться
подписчикам. Эти действия выполняются в несколько шагов:
Snapshot Agent запускается на дистрибьюторе и устанавливает
соединение с издателем. Затем агент устанавливает коллективную блокировку (share-lock) на все
таблицы, для которых определены статьи публикации.
Блокировка гарантирует, что скопированные данные будут последовательны, то есть
пользователь не сможет удалить уже
скопированную агентом строку, а затем снова вставить ее в конец таблицы. Это
могло бы вызвать нарушение целостности данных. В то же время пользователи не
смогут вносить изменения в
заблокированные таблицы.
Snapshot Agent
подключается с издателя к дистрибьютору и записывает копию структуры (схемы)
каждой статьи в файл sch на
дистрибьюторе. Файл сохраняется в подкаталоге того каталога, в котором
расположена база данных Distribution.
Если статья на издателе была индексирована, агент создает скрипт для создания
индекса и сохраняет его в файле idx на дистрибьюторе.
Агент делает копию данных из
публикуемой издателем таблицы и сохраняет ее в файл на дистрибьюторе.Как и файлы схемы, файлы
моментальных снимков копируются в подкаталог каталога базы данных Distribution.
Для создания моментальных снимков используется технология массивного
копирования. Файлы синхронизированы для
конкретной статьи, то есть количество колонок, их тип, размер и другие свойства в файле моментального снимка
соответствуют данным в файле схемы.
Snapshot Agent
добавляет строки в таблицы Msrepl commands
и Msrepl
transactions базы данных распределения Distribution. В таблице Msrepl commands сохраняется информация о местонахождении файлов .sch и Ьср, а также всех скриптов, сохраненных в файлах .idx, которые должны быть выполнены на подписчике перед
началом копирования данных. В таблице Msrepltransactions описываются задания синхронизации
подписчиков.
Агент снимает блокировку с таблиц
издателя и записывает информацию о проделанных действиях в журнал событий (log history file).
После того как агент Snapshot Agent завершит свою работу, на дистрибьюторе
будет находиться вся информация, необходимая да* создания на подписчиках копий статей издателя. Перед Distribution Agent стоит задача доставить подписчикам данные,
подготовленные Snapshot Agent Это выполняется в
несколько шагов:
Distribution Agent устанавливает соединение с сервера, на котором он запущен, с
дистрибьютором. Если используется репликация
по запросу, то агент запускается на подписчике. Если же используется принудительная
репликация, то агент запускается на дистрибьюторе.
Агент просматривает базу данных Distribution и анализирует содержимое таблиц Msrepl commands и Msrepltransactions.
Если агент обнаруживает новые записи в таблицах, он считывает информацию о
расположении файлов схемы, моментального снимка и скриптов.
Агент выполняет содержащийся в
файл схемы скрипт для создания на подписчике таблицы с нужной структурой. Затем агент начинает
копирование данных из файла моментального снимка в созданные таблицы. При этом используются механизмы
массированного копирования.
Когда в сети имеется множество
подписчиков, использование репликации по запросу может снизить нагрузку на дистрибьютора и тем самым повысить
производительность. Distribution Agent в таком случае запускается на подписчике. Если для периодического
выполнения репликации моментальных снимков установлено расписание, то
используется дата и время репликации, заданные на подписчике. Если же используется
принудительная репликация, то значения времени и даты берутся с дистрибьютора.
Безотлагательное
обновление
Самая простая схема репликации моментальных снимков
имеет однонаправленное действие — от издателя к подписчику. Все изменения
должны выполняться на издателе, а затем копироваться подписчикам. В SQL Server 7.0 была введена новая технология — подписчики незамедлительного обновления. Это
позволило расширить возможности репликации
моментальных снимков, разрешив подписчикам изменять данные. Использование подписчиков незамедлительного
обновления обеспечивает скрытую согласованность транзакций, выполняемых одним из подписчиков, между всеми участниками
репликации. Когда подписчик изменяет
локальные данные, вносимые им изменения немедленно отображаются на издателе и
затем копируются всем остальным подписчикам. Для этого используется двухфазный протокол изменений (two-phase commit protocol — 2РС), управляемый координатором
распределенных транзакций (Microsoft Distributed Transactional Coordinator — MS DTC). Когда
подписчик пытается изменить данные, с помощью протокола 2РС создается распределенная транзакция, в которой
данные одновременно изменяются на подписчике и издателе. Если по каким-то причинам данные на издателе не
могут быть изменены, вся транзакция отменяется и данные на подписчике остаются неизмененными. Если
изменения с использованием протокола 2РС были успешно выполнены, измененные
данные распространяются с помощью дистрибьютора всем остальным подписчикам по
установленному расписанию или
по требованию. Подписчик, который выполнял изменения, может успешно работать, не дожидаясь, пока новью данные будут
ему скопированы. Целостность данных в этом случае не нарушается.
5. Репликация транзакции (Transactional Replication) может быть использована для копирования объектов
двух различных типов-: таблиц ил» хранимых процедур. Etc» таблица или ее часть может быть включена в публикацию как статья. Кроме того, в эту же или
другую публикацию в качестве, статьи может быть, также-включена одна или
несколько хранимых процедур.
Репликация транзакций использует
журнал транзакций базы данных, из которого собирается информация о выполняемых в выбранной для публикации
таблице командах UPDATE, INSERT, DELETE и других изменениях. Выбранные транзакции копируются
в базу данных дистрибьютора с сохранением информации о последовательности их выполнения. Затем эти транзакции
рассылаются подписчикам и применяются на них в том же порядке, в котором
они происходили на издателе.
Сделанные на издателе изменения
передаются подписчикам постоянно или с определенными интервалами. Обычно изменения
отображаются на всех участниках репликации в реальном времени или с задержкой в несколько секунд. При выполнении
репликации транзакций исключаются конфликты обновления, так как все изменения
выполняются на издателе.
Репликацию транзакций рекомендуется использовать в
локальных сетях. Серверы SQL Server 7.0
могут постоянно поддерживать
соединение друг с другой, к изменения будут отображаться на все
серверы практически мгновенно. Кроме
того, репликация транзакций часто используется в-больших базах данных с небольшим количеством изменений. Репликации подписчик, могут располагаться на
разных материках, и репликация
моментальных снимков потребовала бы неоправданно больших затрат. При
использовании репликации транзакций
подписчик может периодически (например, два раза в сутки) связываться с дистрибьютором и забирать у него выполненные на издателе
транзакции. При таком подходе резко снижается объем передаваемых данных
и, как следствие, повышается производительность репликации.
При использовании репликации транзакции задействованы
три агента:
o
Snapshot Agent;
o
Log Reader Agents
o
Distribution Agent.
Перед тем как транзакции начнут применяться на
подписчике, необходимо выполнить первоначальную синхронизацию данных издателя и
подписчика. Snapshot Agent выполняет
копирование всех данных, находящихся в созданных статьях. При этом используются
механизмы, обеспечивающие выполнение репликации моментальных снимков. После
того как схема таблицы будет применена на подписчике , можно копировать
моментальный снимок. Таким образом, когда копирование завершится, будет создана
стартовая точка для применения транзакций. Таблицы подписчика будут иметь
структуру, аналогичную структуре таблиц
издателя.
Если подписчик уже имеет таблицы с правильной
структурой и данные уже были синхронизированы, при создании репликации
транзакций можно указать, что выполнение первоначальной синхронизации не нужно,
тогда Snapshot
Agent не будет запускаться. Тем не менее,
примененение транзакций начинается
только после того, как сервер убедится, что структура и содержание таблиц подписчика
соответствует структуре и содержанию таблиц издателя.
Если база данных издателя слишком большая, то для
копирования моментального снимка базы данных подписчику можно использовать
ручную синхронизацию. Например, если размер базы данных составляет примерно 40
Гбайт, то быстрее и дешевле будет сделать архив базы данных на нескольких
компакт дисках или магнитных лентах и отправить их постой или с
экспресс-курьером. В таком случае запуск Snapshot Agent не требуется. Сервер начинает копирование транзакций
незамедлительно, как только убедится в соответствии данных на подписчике и
издателе.
После того как первоначальная синхронизация выполнена,
начинается копирование транзакций. Log Reader Agent запускает на дистрибьюторе и
устанавливает соединение с издателем. Когда таблица участвует в репликации, все
выполняемые в ней транзакции специальным образом маркируются для ускорения
поиска нужных записей в журнале транзакций. Агент анализирует журнал транзакций
и выбирает из него все команды INSERT, UPDATE, DELETE И другие
модификации данных, которые изменяли определенные для публикации таблицы. Агент
считывает только завершенные транзакции и сохраняет их в таблице MSrepl_transactions и
применяет их на подписчиках в том же порядке, в котором они происходили на
издателе. Тем самым гарантируется, что все подписчики будут иметь одинаковые
копии данных. Действия, выполняемые Distribution Agent при репликации транзакций, практически ничем не
отличаются от действий, выполняемых этим агентом при репликации моментальных
снимков.
Безотлагательное обновление
Наиболее простая форма репликации транзакций
предлагает однонаправленное выполнение изменений – изменения сделанные на
издателе, тиражируются всем подписчикам. Сами подписчики в этом случае не могут
изменять данные.
В репликации сервер реализован протокол 2PC, с помощью которого пользователи, работающие с
серверами-подписчиками, могут обновлять и изменять локальные данные. Приложение
успешно работавшее с базой данных, размещенной на сервере-издателе, может в
этом случае безо всяких изменений устойчиво
работать с базой данных подписчика.
Если при создании публикации для
нее была разрешена поддержка подписчиков незамедлительного обновления (Immediate-update Subscribers), то в таблицах на подписчике создаются специальные триггеры (рис. 2). Кроме того, в
публикуемых таблицах как издателя, так и подписчиков автоматически добавляется
колонка с типом данных timestamp.
Каждый раз при изменении строки в таблице значение в этой колонке изменяется.
Когда пользователь пытается изменить данные на подписчике, триггеры UPDATE, DELETE и INSERT перехватывают инициируемые пользователем транзакции и
передают их издателю с помощью протокола 2 PC, управляемого координатором распределенных транзакций
(MSDTG>.
Рисунок 2. Подписчики незамедлительного обновления в
репликации транзакций
Триггер создает распределенную
транзакцию и одновременно пытается обновить данные на издателе и подписчике. Он сравнивает значения колонок timestamp издателя и подписчика для изменяемой строки. Если значения совпадают, значит, данные в издателе не
были изменены со времени последней репликации и подписчик может их
изменять. Для колонки timestamp
устанавливается новое значение, так что другие подписчики незамедлительного обновления не смогут изменить данные до тех
пор, пока измененные данные не будут им реплицированы.
Изменение как локальных данных,
так и данных на издателе выполняется как одна распределенная транзакция. Поэтому если по каким-то причинам внести
изменения в данные на издателе невозможно, то изменить
локальные данные тоже будет невозможно. Этим гарантируется целостность данных.
Если издатель недоступен, подписчик не сможет изменить локальные данные.
Если изменения на подписчике
были выполнены успешно, это означает, что данные на издателе также были изменены. Log Reader Agent обнаруживает сделанные изменения и сохраняет их в
базе распределения. Затем Distribution Agent
тиражирует транзакции всем подписчикам. Подписчик, инициировавший изменения, уже имеет обновленные данные, поэтому считается,
что данные на него уже были реплицированы и повторное копирование не выполняется.
Для избежания повторного
копирования в тело транзакции вставляются специальные метки, которые информируют Distribution Agent о ненужности копирования этой транзакции конкретному
подписчику. Этот подписчик может продолжать
работать сразу же после того, как сделал изменения. Спустя непродолжительное
время все участники репликации будут иметь одинаковые копий-данных.
Требования безотлагательного обновления
Таблицы, участвующие в разрешенной
для выполнения незамедлительного обновления публикации, должны иметь колонку типа timestamp. Если используется вертикальная фильтрация, то
колонка limestamp должна быть включена
в статью.
Когда пользователь вставляет строку в таблицу, команда
INSERT должна содержать список колонок, чтобы распределенная транзакция могла быть безболезненно
выполнена как на издателе, так и на подписчике. Это особенно важно при использовании вертикальной
фильтрации, так как таблицы на издателе и подписчике в этом случае могут
иметь различное количество колонок.
Если на основе одной таблицы
создано несколько статей, включенных в разрешенную для безотлагательного обновления публикацию, то
создание подписчиков незамедлительного обновления будет невозможно. Триггеры работают только с одной колонкой timestamp, поэтому невозможно отслеживать сделанные изменения для каждой статьи.
Если на основе одной таблицы было
создано несколько статей, включенных в разные публикации, и необходимо подписаться на все
публикации с отображением их в одну базу данных подписчика, то можно сконфигурировать только одного подписчика
незамедлительного обновления.
Пользователи не должны напрямую обновлять колонки identity и timestamp.
Значения для этих полей генерируются издателем. Также подписчики не могут обновлять
данные в колонках text и image, так как к этим колонкам нельзя обращаться из
триггера.
6. Помимо копирования данных, механизмы репликации SQL Server 7.0 разрешают выполнять между несколькими серверами копирование
хранимых процедур. Можно включить в публикацию в качестве статьи одну
или несколько хранимых процедур. Если публикация включена в репликацию
моментальных снимков, то выполненные
хранимой процедурой изменения будут копироваться всем подписчикам. Если же
хранимая процедура включена как статья в репликацию транзакции, то SQL Server реплицирует только сам процесс выполнения процедуры,
а не все измененные ею данные. Такой способ изменения данных особенно полезен при
выполнении большого количества изменений в таблице, производимых по определенному
алгоритму. Этот алгоритм может быть
реализован в хранимой процедуре, которая будет включена в репликацию. Такой
подход позволяет существенно
уменьшить сетевой трафик даже по сравнению с репликацией транзакций, не говоря уже
о репликации моментальных снимков. Репликация хранимых процедур осуществляется
двумя методами:
Procedure execution (Обычное выполнение процедуры). При запуске хранимой
процедуры на издателе подписчику передастся лишь указание запустить эту же процедуру. В этом подходе не
гарантируется соответствие данных на
издателе и подписчике. Хранимая процедура может включать несколько транзакций, любая из которых может быть выполнена
на издателе, но по каким-то причинам не выполнена на подписчике. Хотя другие описанные в хранимой
процедуре транзакции будут выполнены и часть данных успешно изменена,
другая часть данных все же останется неизмененной.
Scrializablc
procedure execution (Упорядоченное
выполнение процедуры). Этот способ репликации хранимых процедур копирует от
издателя к подписчику последовательность команд модификации данных (data manipulation
language — OML), выполненных в теле хранимых процедур. Такой способ
репликации возможен только в том случае,
если хранимая процедура выполняется внутри упорядоченной транзакции (serializable transaction). Этот метод гарантирует соответствие данных на
подписчике и издателях после выполнения
хранимой процедуры. По умолчанию
созданный на издателе код хранимой процедуры копируется всем подписчикам. Тем
не менее, на подписчике можно создать
одноименную хранимую процедуру, отличную от хранимой процедуры издателя. Это
бывает полезно в тех случаях, когда на издателе и подписчике необходимо
реализовать разные алгоритмы.
Всякий раз, когда выполняется
включенная в репликацию хранимая процедура, подписчикам передаются параметры ее запуска, а также
команда запустить одноименную хранимую процедуру на локальном сервере. Даже если пользователь запускает
процедуру, изменяющую несколько связанных таблиц, подписчикам передается только команда запуска. В процессе выполнения
хранимой процедуры на издателе SQL Server
временно прекращает помечать изменяемые процедурой данные. Таким образом,
операции вставки, удаления я изменения
данных не будут переданы стандартными средствами репликации. Если же хранимая
процедура не включена в репликацию, то все выполняемые в ней команды INSERT, UPDATE и DELETE будут маркировать транзакции
для репликации. Все маркированные транзакции будут переданы средствами
репликации транзакций.
При использовании репликации
хранимых процедур следует внимательно относиться к накладываемым ограничениям
на фильтрацию строк. Если данные из таблицы реплицируются не полностью, то
таблицы на издателе
и подписчике будут различаться. Выполнение хранимой процедуры на подписчике в
этом случае может
привести к совершенно другим результатам, чем на издателе. Кроме того, следует
избегать использования
в хранимой процедуре данных, расположенных в не реплицируемой таблице.
Например, если тиражируемая
хранимая процедура обновляет данные в реплицируемой таблице, основываясь на
данных, полученных в
результате запроса к не реплицируемой таблице, выполнение этой процедуры на
подписчике вызовет
проблемы.
Для гарантии, что данные на
подписчике и издателе находятся в одном и том же состоянии, рекомендуется тиражировать в транзакции серию
одиночных команд, а не просто команду на выполнение хранимой процедуры. Тем не менее, если
пользователь четко представляет структуру данных, их взаимосвязь и имеет
достаточную квалификацию и опыт, лучшим вариантом все же будет использование
репликации команд на запуск.
Литература:
1 Е. Мамаев
«Microsoft
SQL Server 2000», БХВ-Петербург, 2004г.
Контрольные вопросы:
1 Что такое репликация данных?
2 Какие механизмы репликации
существуют?
3 Для чего предназначена программа Merge Agent?
4 Что такое Snapshot Replication?
5 Что такое Transactional Replication?
6 Что такое Transactional Stored Procedure?
7 Что такое Merge Replication?