авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 15 | 16 || 18 | 19 |   ...   | 33 |

«Е.Мамаев MS SQL SERVER 2000 Книга посвящена одной из самых мощных и популярных современных систем управления базами данных - Microsoft SQL Server 2000. ...»

-- [ Страница 17 ] --

Преимуществом репликации моментальных снимков является низкая загружен ность процессора. Если для обеспечения работы других типов транзакций по требуется постоянное присутствие в памяти соответствующих агентов, то при работе с репликацией моментальных снимков этого не требуется, т. к. никакой анализ данных не производится. Не нужно постоянно отслеживать изменения, вносимые пользователями в данные. В процессе репликации просто копируются все данные, включенные в публикацию. Но это является и недостатком. Если количество информации в базе данных значительно, то файлы моментальных снимков могут иметь очень большой размер. Загрузка сети будет расти пропор ционально увеличению количества подписчиков. Передача файлов моменталь ных снимков всем подписчикам может занять слишком много времени. Изме нение даже очень небольшой части данных приведет к необходимости доставки подписчикам всех публикуемых данных. Это препятствует частой синхрониза ции подписчиков с издателем, что, в свою очередь, ведет к снижению оператив ности отображения изменений.

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

Лучшим примером систем "только для чтения" являются системы поддержки принятия решений (DSS, Decision Support Systems). Эти системы хранят в основ ном историческую информацию, изменения в которую обычно не вносятся. На пример, базу данных финансовых операций за прошедший год вряд ли придется изменять, и она может быть установлена в режим "только для чтения". Реплика ция сведением является в этом случае лучшим вариантом тиражирования дан ных — достаточно один раз скопировать данные с издателя и репликация мо ментальных снимков будет лучшим решением.

Часть III. Администрирование Кроме того, репликация моментальных снимков может быть использована в базах данных, характеризующихся очень большим количеством изменений.

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

Рассмотрим, какие механизмы применяются для работы репликации момен тальных снимков. На рис. 14.12 приведена схема взаимодействия издателя и подписчика.

Рис. 14.12. Репликация моментальных снимков Как видно, репликация моментальных снимков реализуется всего двумя агента ми — Snapshot Agent и Distribution Agent. Назначение каждого из них было рас смотрено ранее в этой главе. Рассмотрим теперь, что же конкретно делают эти агенты применительно к репликации моментальных снимков.

Роль агента Snapshot Agent сводится к созданию данных, которые будут распро странены подписчикам. Этот агент не работает постоянно, а лишь периодически запускается в соответствии с установленным расписанием. Каждый раз при за пуске он производит выборку информации из базы данных и помещает ее в Глава 14. Репликация данных файлы моментальных снимков (snapshot files). Рассмотрим, какие шаги выполня ются в этом процессе:

1. Агент Snapshot Agent автоматически запускается на дистрибьюторе и устанав ливает соединение с издателем. После этого начинается процесс выборки дан ных. Для всех таблиц, для которых определены статьи, агент устанавливает коллективную или разделяемую блокировку (share-lock). Эта блокировка запре щает пользователям вносить любые изменения в данные таблицы, включая удаление и вставку. Но возможность чтения данных остается. Такой подход га рантирует, что целостность и последовательность копируемых данных не будут нарушены. В противном случае пользователь может удалить уже скопирован ную строку и вставить ее в конец. В итоге агент скопирует две одинаковые строки. При вставке этих данных на подписчике может быть нарушена уни кальность строк, и репликация будет остановлена. Это обеспечивает целост ность копируемых данных. Блокировка гарантирует, что скопированные дан ные будут последовательны, т. е. пользователь не сможет удалить уже скопи рованную агентом строку, а затем снова вставить ее в конец таблицы. Это мог ло бы вызвать нарушение целостности данных. Запрещение изменений данных может вызвать недовольство пользователей, особенно если создание файла мо ментального снимка длится достаточно долго. Поэтому имеет смысл подумать о планировании запуска агента Snapshot Agent в ночное время.

2. На этом шаге агент генерирует файл схемы с расширением SCH для каждой статьи. С помощью этого файла на подписчике можно создать таблицу со структурой, идентичной структуре статьи (но не обязательно таблицы, на ос нове которой создана статья). Кроме того, если исходная таблица статьи имела индексы, и эти индексы входят в статью, то агент также создает сце нарий для организации этого индекса на подписчике и сохраняет его в файл с расширением IDX. Агент с издателя подключается к дистрибьютору и со храняет файлы SCH и IDX в тот же каталог, в котором размещена база дан ных распределения D i s t r i b u t i o n.

3. На третьем шаге Snapshot Agent образует собственно копию публикуемых данных. Как уже говорилось, данные сохраняются в файлы моментальных снимков. Для создания этих файлов применяются механизмы массивного копирования. С помощью утилиты bcp.exe производится создание текстовых файлов исконного или внутреннего (native) формата для каждой статьи. По лученные файлы имеют расширение ВСР и, подобно файлам SCH и IDX, хранятся в одном каталоге с базой данных D i s t r i b u t i o n. Создание файла форматирования для текстовых файлов не выполняется, т. к. используется исконный формат, а файлы SCH гарантируют, что структура таблиц на под писчике будет соответствовать формату файлов ВСР.

С Замечание ) Текстовые файлы сохраняются в исконном формате лишь в том случае, если все участники репликации являются серверами SQL Server 2000. В SQL Server 6.x или любой другой системе текстовые файлы имеют символьный формат. Файлы момен тальных снимков в этом случае будут иметь расширение ТХТ.

600 Часть III. Администрирование 4. После того как сгенерированы все необходимые файлы (SCH, IDX, ВСР или ТХТ), необходимо сохранить всю информацию о проделанной работе. На четвертом шаге агент Snapshot Agent регистрирует в базе данных D i s t r i b u t i o n создание файлов, указывает их имя, дату создания и другую информацию, на основании которой данные затем рассылаются подписчи кам. ДЛЯ Э О О И П Л З Ю С ТГ С О Ь У Т Я ДВе ТаблИЦЫ". Msrepl_commands И Msrepi_transactions. В первой из них указывается количество подготовлен ных файлов, факт их наличия, имена и т. д. В таблице Msrepl_transactions задается время создания копии данных издателя и устанавливается время следующей синхронизации подписчиков.

5. На последнем шаге снимается блокировка со всех таблиц издателя. В журнал репликации (log history file) сохраняется информация о проделанных действи ях. Этот журнал может быть впоследствии использован для анализа ошибок (если таковые были), приведших к прерыванию репликации данных.

На этом работа агента Snapshot Agent заканчивается. В случае успешного вы полнения всех приведенных шагов на дистрибьюторе будет иметься необходи мый набор данных, а в базе данных D i s t r i b u t i o n — вся необходимая для тира жирования данных информация. На этом этапе можно начинать распростра нение данных подписчикам.

С Замечание ~^) Файлы моментальных снимков (ВСР или ТХТ), подготовленные агентом Snapshot Agent, участвуют не только в процессе репликации. Администратор может исполь зовать эти файлы и для других целей. Это замечание касается и других файлов — схемы (SCH) и индексов (IDX).

Копирование данных, подготовленных агентом Snapshot Agent, всем зарегистри рованным подписчикам занимается агент Distribution Agent. Этот агент запущен постоянно и. отслеживая появление обновленных данных на дистрибьюторе, сразу же начинает их распространение подписчикам. Доставка данных осущест вляется в несколько шагов:

1. Первое, что выполняется Distribution Agent — это установление соединения с дистрибьютором. В зависимости от выбранного метода обновления подпис чика, место запуска агента может меняться. Если применяется репликация по запросу (pull replication), то агент запускается на подписчике. Когда же ис пользуется принудительная репликация (push replication), то агент запускается на дистрибьюторе.

(_ Замечание ) Репликация по запросу может заметно снизить нагрузку на дистрибьютора в сети с множеством подписчиков, т. к. агент Distribution Agent в этом случае запускается на подписчике. Но при этом может возникнуть проблема со временем синхронизации серверов. Если устанавливается время подключения подписчика к дистрибьютору, то следует учесть, что информация о времени берется с подписчика. Когда же осу ществляется принудительная репликация, то синхронизация происходит в соответ ствии с часами дистрибьютора.

Глава 14. Репликация данных Ё_ 2. Следующий шаг — анализ базы данных распределения D i s t r i b u t i o n. Агент просматривает таблицы Msrepl_commands И Msrepl_transactions. Если В Н Х И имеются строки, указывающие о поступлении новых данных, то агент выби рает информацию о подготовленных файлах моментальных снимков (ВСР или ТХТ), файлах схемы (SCH) и файлах индексов (IDX).

3. На этом этапе Distribution Agent приступает собственно к копированию дан ных. Сначала он подключается к подписчику и смотрит, имеются ли в базе данных назначения таблицы с нужной структурой. Если таковых нет, то агент создает их на основе информации, полученной из файла SCH. После создания таблиц начинается копирование данных из файлов моментальных снимков (ВСР или ТХТ). С помощью механизма массивного копирования (утилита bcp.exe или команда BULK INSERT) агент закачивает данные в табли цы подписчика. Если необходимо, то дополнительно создаются индексы, оп ределенные в файле IDX.

Мы перечислили основные шаги, исполняемые в процессе репликации момен тальных снимков. Однако есть еще несколько вопросов, на которые нужно об ратить внимание. Ни один из агентов не выполняет удаление файлов SCH, IDX, ВСР и ТХТ. Кроме того, ненужная информация в базе данных D i s t r i b u t i o n также остается. Решение этих проблем возложено на вспомогательные задачи, рассмотренные ранее в этой главе.

Репликация транзакций Более сложным типом репликации является репликация транзакций (Transactional Replication). Репликация транзакций существенно отличается от репликации моментальных снимков. В основе ее работы лежит передача ин формации об изменениях данных. Для этого анализируется журнал транзакций базы данных, в которой создана публикация, и выполняется поиск записей, за трагивающих публикуемые данные.

Из журнала транзакций выбираются все транзакции, в ходе которых были вы полнены команды изменения данных INSERT, DELETE И UPDATE. Полученная ин формация сохраняется в базе распределения D i s t r i b u t i o n на дистрибьюторе.

При этом указывается информация о порядке выполнения транзакций. При вы полнении синхронизации на подписчике применяются все транзакции, храня щиеся в базе данных D i s t r i b u t i o n. Причем в той же последовательности, в ко торой они происходили на издателе.

Как видно, по сети передаются только данные, которые были действительно из менены. Это позволяет резко повысить производительность репликации по срав нению с репликацией моментальных снимков. Кроме того, небольшой объем пе редаваемых данных позволяет очень оперативно отображать на подписчиках все изменения, сделанные на издателе. Обычно репликация транзакций конфигуриру ется таким образом, что изменения отображаются в реальном времени или с ми нимальными задержками (всего несколько секунд).

Часть III. Администрирование Замечание При использовании репликации транзакций исключается появление конфликтов из менений, т. к. все изменения данных выполняются на издателе, а подписчики лишь принимают цепочку изменений. Если транзакция была удачно выполнена на издате ле, то можно с уверенностью ожидать успешного ее выполнения и на подписчике.

Это гарантирует целостность данных.

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

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

Репликация транзакций хорошо зарекомендовала себя в локальных сетях, кото рые обеспечивают постоянное соединение и высокую пропускную способность.

В этом случае изменения могут отображаться практически мгновенно.

На рис. 14.13 приведена схема работы репликации транзакций.

Дистрибьютор.

Рис. 14.13. Репликация транзакций Как видно, при этом используются три следующих агента:

П Snapshot Agent;

Глава 14. Репликация данных П Log Reader Agent;

• Distribution Agent.

Рассмотрим роль каждого из них.

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

Первоначальная синхронизация происходит по схеме работы репликации мо ментальных снимков. Агент Snapshot Agent подключается к издателю и создает набор файлов, используемых в стандартной репликации моментальных сним ков — файлы схемы (SCH), сценарии создания индексов (IDX) и файлы момен тальных снимков (ВСР или ТХТ). Затем эти файлы сохраняются на дистрибью торе. Более подробно работа агента Snapshot Agent при выполнении этих операций рассмотрена в предыдущем разделе.

После того как создание файлов первоначальной синхронизации будет закончено, начинается отслеживание изменений в статьях. Для этого на дистрибьюторе за пускается агент Log Reader Agent. Этот агент и устанавливает соединение с изда телем, просматривает журнал транзакций публикуемой базы данных и выбирает из него все транзакции, в которых было произведено изменение публикуемых дан ных. Таким образом будут найдены все команды INSERT, UPDATE И DELETE, вы полненные на издателе, а также любые другие команды изменения данных.

(~ Замечание ^ Каждая выбираемая транзакция может содержать множество команд, а каждая ко манда может иметь длину до 500 символов Unicode.

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

Кроме того, пометка транзакций позволяет ускорить процесс их поиска агентом Log Reader Agent.

( Замечание ^ В SQL Server 2000 имеется набор системных хранимых процедур, с помощью которых производится управление процессом репликации. С помощью этих хранимых проце дур можно выполнить любые необходимые действия. Например, для получения с из дателя списка транзакций, помеченных для репликации, применяется хранимая про цедура s p _ r e p l c m d s. Чтобы снять отметку с транзакции и тем самым разрешить ее удаление, применяется процедура s p _ r e p i d o n e.

Выбранные для репликации транзакции помещаются в таблицу MSrepltransactions базы данных распределения Distribution. В итоге В Э О ТЙ базе данных содержится цепочка изменений. С их помощью данные, получен ные агентом Snapshot Agent, могут быть приведены в то же состояние, в кото ром они находятся на издателе. Мы подробно рассмотрели процесс получения 604 Часть III. Администрирование данных, которые должны быть реплицированы подписчикам. Рассмотрим те перь процесс получения подписчиками накопленных изменений.

Первое, что нужно сделать на подписчике, это синхронизировать его базу с ба зой издателя. Как уже говорилось, первоначальная синхронизация выполняется по тому же алгоритму, что и репликация моментальных снимков. Этот процесс осуществляется агентом Distribution Agent. Сначала на подписчике создаются таблицы с нужной структурой, в которые затем производится массивная закачка данных из файлов моментальных снимков. В итоге, после того как закончится первоначальная синхронизация, на подписчике будет создана стартовая точка для применения транзакций.

Мы рассмотрели, как происходит автоматическая первоначальная синхронизация.

Однако в случае репликации транзакций при создании публикации можно ука зать, что выполнение автоматической первоначальной синхронизации не нужно.

В этом случае предполагается, что база данных на подписчике согласована с базой данных издателя. Тем не менее, применение транзакций начнется только после того, как SQL Server 2000 убедится, что данные действительно согласова ны и структура таблиц подписчика идентична структуре статей издателя.

Возможность избежать автоматической начальной синхронизации позволяет администратору выполнить первоначальную синхронизацию вручную. Это быва ет полезно при выяснении соответствия баз данных большого объема. Предпо ложим, что вы устанавливаете SQL Server 2000 в филиале компании и этот фи лиал расположен на другом материке. С центральным офисом филиал соеди няется по медленному выделенному каналу. При этом размер базы данных пре вышает 100 Гбайт. Копирование такого объема информации через медленное вы деленное соединение будет самоубийством. Единственный выход из ситуации — копирование центральной базы данных на жесткий диск или другой носитель • информации и доставка его непосредственно в филиал. После того как ручная синхронизация будет выполнена, SQL Server 2000 начнет применение транзак ций, скопированных с издателя.

(ч Замечание Ручная синхронизация связана с определенными трудностями, и поэтому ее реко мендуется выполнять только опытным пользователям. Необходимо гарантировать, что структура таблиц на подписчике и издателе, а также их содержание идентичны.

Применением транзакции на подписчиках также занимается агент Distribution Agent. Место запуска этого агента к тому же зависит от выбранного метода рас пространения изменений. Если выполняется принудительная репликация, агент запускается на дистрибьюторе, а если репликация по запросу — на подписчике.

Distribution Agent подключается к базе данных распределения дистрибьютора и анализирует содержимое таблицы MSrepi t r a n s a c t i o n s. Если он находит в табли це транзакции, еще не отображенные на подписчике, то он применяет их в том же порядке, в котором они произошли на издателе. Это гарантирует согласованность данных между издателем и всеми подписчиками. Принцип работы агента Distribu tion Agent при использовании репликации транзакций практически ничем не от личается от работы в случае репликации моментальных снимков.

Глава 14. Репликация данных Как и для репликации моментальных снимков, в работе репликации транзакций используются несколько вспомогательных заданий, гарантирующих длительную работу дистрибьютора и базы данных распределения.

Репликацияхранимыхпроцедур Лишь иногда пользователи прибегают к непосредственному изменению данных с помощью команд INSERT, UPDATE ИЛИ DELETE. В подавляющем большинстве случа ев изменение данных производится с помощью хранимых процедур, которые реа лизуют бизнес-логику, проверяют достоверность и целостность данных и т. д.

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

Подсистема репликации SQL Server 2000 является мощным и гибким средством распространения изменений данных между различными системами обработки и хранения информации. Но рассматриваемые ранее подходы недостаточно эф фективны при выполнении большого количества однотипных изменений. На пример, если пользователю необходимо поднять на 15% цену всех товаров, он может сделать это единственной командой UPDATE, воздействовав на несколько тысяч строк. Система репликации должна будет отобразить сделанные измене ния на всех подписчиках. Выполнение лишь одной команды способно привести к интенсивному обмену данными.

Важным усовершенствованием механизмов репликации в SQL Server 2000 по сравнению с предыдущими версиями стало появление репликации хранимых про цедур (stored procedure replication). Репликация хранимых процедур позволяет подписчикам копировать не сами исправленные данные, а лишь информацию о том, как эти данные необходимо изменить. В рассмотренном ранее случае при менение репликации хранимых процедур позволит избежать интенсивного обме на данными, ограничившись лишь передачей одной-единственной команды UPDATE. Каждый из подписчиков должен будет применить эту команду к храни мым на нем данным. После выполнения хранимой процедуры данные на под писчике будут находиться в том же состоянии, что и данные на издателе.

Репликация хранимых процедур является своего рода надстройкой над реплика цией моментальных снимков и репликацией транзакций. При создании публика ции администратор может включить в нее одну или более хранимых процедур в качестве обычных статей. При выполнении репликации хранимых процедур в публикациях моментальных снимков сервер будет копировать все изменения дан ных, которые были произведены с помощью хранимой процедуры. Для копирова ния данных в этом случае используются те же алгоритмы, что и при обычной ра боте репликации моментальных снимков. Для таблиц, которые изменяются реплицируемой хранимой процедурой, создаются файлы моментальных снимков (ВСР ИЛИ ТХТ), файлы схемы (SCH) и сценариев создания индексов (IDX), кото рые затем применяются на подписчиках.

Хранимая процедура может быть также включена в публикацию репликации тран закций. В этом случае можно использовать все преимущества, предоставляемые 606 Часть III. Администрирование репликацией хранимых процедур, а подписчикам копируется только информация о том, как должна быть выполнена хранимая процедура. Дублирование самих данных не выполняется. Наибольшую пользу от такого подхода можно получить в системах, характеризуемых большим количеством однотипных изменений, затра гивающих множество строк таблиц. Кроме того, репликация хранимых процедур весьма полезна при изменении множества строк по сложному алгоритму, когда для получения конечного результата необходимо выполнить множество промежу точных действий и дополнительных обработок данных. Применение репликации хранимых процедур дает резкое снижение объема сетевого трафика по сравнению с репликацией транзакций, не говоря уже о репликации моментальных снимков.

В некоторых случаях можно добиться уменьшения объема передаваемых данных в несколько сотен (а иногда и тысяч) раз.

Репликация хранимых процедур в SQL Server 2000 может работать в одном из двух следующих режимов:

П Procedure Execution (Стандартное выполнение хранимой процедуры). В этом случае подписчик получает команду выполнить указанную хранимую проце дуру с конкретным набором входных параметров. При этом контроль за ка чеством выполнения процедуры на подписчике не осуществляется. Это озна чает, что данные на подписчике могут находиться в состоянии, отличном от издателя. Например, если хранимая процедура осуществляет сложную обра ботку данных при помощи множества транзакций, то по каким-то причинам одна или более транзакций могут закончиться неудачно. При этом остальные транзакции будут успешно завершены, и сделанные в них изменения будут зафиксированы. В итоге данные на подписчике окажутся в промежуточном состоянии. Забота о согласованности данных в этом случае перекладывается на программиста, который должен учитывать эту особенность при разработке хранимых процедур, которые предполагается реплицировать.

( Замечание ^) Стандартный метод выполнения хранимых процедур требует внимательного отноше ния к устанавливаемой фильтрации. В случае вертикальной фильтрации хранимая процедура не должна обращаться к столбцам, не включенным в статью. Если задана горизонтальная фильтрация, то не следует использовать вычисления, основанные на агрегировании всех строк таблицы. Раз набор строк на издателе и подписчике будет различаться, то и полученные результаты агрегирования также будут разными.

П Serializable Procedure Execution (Последовательное выполнение хранимой про цедуры). В отличие от предыдущего способа, данный метод работы реплика ции хранимых процедур обеспечивает согласованность данных на издателе и подписчике. Это достигается за счет того, что весь процесс выполнения хра нимой процедуры разбивается на последовательность команд языка модифи кации данных (DML, Data Manipulation Language). Эти команды затем пере даются подписчикам, где они выполняются в той же последовательности, что и на издателе. Такой способ выполнения хранимых процедур возможен толь ко в том случае, если хранимая процедура выполняется внутри упорядоченной транзакции (serializable transaction).

Глава 14. Репликация данных Замечание При выборе метода репликации хранимых процедур следует тщательно взвесить все "за" и "против". Последовательное выполнение хранимых процедур гарантирует идентичность данных на сервере и издателе. Но в этом случае количество переда ваемых по сети данных значительно выше, чем при стандартном выполнении хра нимых процедур. Зато стандартный метод требует предельного внимания и осто рожности, т. к. легко нарушить согласованность данных между подписчиком и издателем. Но наградой является чрезвычайно низкий сетевой трафик и возмож ность реализации произвольной логики обработки данных.

Нетрудно прийти к мысли, что перед тем как станет возможным выполнение реплицируемой хранимой процедуры на подписчике, необходимо ее там соз дать. Процедура создания хранимой процедуры на подписчике происходит ав томатически при первоначальной синхронизации. Агент Snapshot Agent создает специальный скрипт, с помощью которого на подписчике будет создана репли цируемая хранимая процедура. В итоге издатель и все подписчики станут обла дателями идентичных хранимых процедур.

Тем не менее, система репликации SQL Server 2000 позволяет создавать храни мые процедуры на подписчике и вручную. Это бывает полезно, если необходи мо использовать на подписчике логику обработки данных, отличную от логики, применяемой на издателе. Рассмотрим это на примере следующей ситуации.

Из центрального офиса реплицируется хранимая процедура correct_price, ко торая корректирует цену товаров в филиалах в зависимости от Курса валюты, спроса, предложения и некоторых других факторов. Эта процедура воздействует на таблицу goods. Кроме того, процедура c o r r e c t p r i c e удаляет из таблицы p r i c e _ i i s t товары, которых нет на складе. Структуры данных в части филиалов соответствуют структуре данных в центральном офисе, но в некоторых филиа лах имеется еще несколько таблиц, данные в которых зависят от цен товаров, хранящихся в таблице goods. Кроме того, строки таблицы p r i c e _ i i s t являются внешними ключами других таблиц. Наиболее простым вариантом было бы на писание дополнительных триггеров и хранимых процедур, которые бы выпол няли дополнительную обработку данных. Но все эти операции могут быть реа лизованы в теле хранимой процедуры correct_price.

С Замечание При создании реплицируемых хранимых процедур не рекомендуется, чтобы проце дура обращалась к внешним структурам данных, не включенных в репликацию. Если вы не уверены в качестве процедуры, то лучше прибегнуть к последовательному выполнению. Тем не менее, если пользователь четко представляет структуру дан ных, их взаимосвязь и имеет достаточные квалификацию и опыт, лучшим вариантом все же будет репликация с помощью стандартного запуска хранимых процедур.

Как уже понятно, SQL Server 2000 не проверяет идентичность хранимых проце дур на издателе и подписчике. При репликации подписчик получает только имя хранимой процедуры и параметры ее запуска. Поэтому процедуры на издателе и подписчике могут отличаться и выполнять абсолютно разные действия. Когда 608 Часть III. Администрирование на издателе работает хранимая процедура, включенная в публикацию, то выпол няемые в ней транзакции не помечаются для репликации. Это позволяет избе жать копирования данных, которые должны быть изменены с помошью храни мой процедуры, и добиться целостности данных.

( Замечание ) При выполнении хранимой процедуры, не включенной в публикацию, все входящие в нее транзакции помечаются для репликации (только если процедура изменяет данные в таблицах, включенных в публикацию). Проделанные изменения затем ре плицируются обычными средствами.

Репликация сведением В одном из следующих разделов будет рассмотрена одна из технологий репли кации, позволяющих изменять данные на подписчиках, — подписчики незамед лительного обновления (Immediate Updating Subscribers). Эта технология позволя ет издателю быстро отображать изменения, сделанные на одном подписчике, всем другим подписчикам. Однако недостатком этой технологии является необ ходимость наличия постоянного соединения между подписчиком и издателем.

Если связь между ними рвется, то внести изменения на подписчике нельзя.

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

Для решения указанных проблем в SQL Server 7.0 был создан новый тип репли кации — репликация сведением (merge replication), которая позволяет подписчи кам вносить изменения в данные без необходимости постоянного соединения с издателем. Каждый из подписчиков работает автономно и изменяет данные, как хочет. Изменения данных могут накапливаться, а не копироваться сразу же.

Множество подписчиков способны беспрепятственно изменять одновременно одни и те же данные, что невозможно при использовании подписчиков неза медлительного обновления. Специальный агент отслеживает изменения, сде ланные на каждом из подписчиков и при соединении с дистрибьютором объе диняет эти изменения с исправлениями, внесенными на издателе и на других подписчиках. Затем агент копирует подписчику изменения, выполненные дру гими участниками репликации.

Рассмотрим, как же SQL Server 2000 реализует все эти возможности. На рис. 14.14 приведена схема работы репликации сведением. ;

При репликации сведением в SQL Server 2000 работают два агента:

• Snapshot Agent — выполняет подготовку файлов моментальных снимков и других файлов, необходимых для первоначальной синхронизации подписчи ков с издателем., г, П Merge Agent — объединяет изменения, сделанные на всех участниках репли кации, в единую структуру, а также распространяет выполненные изменения подписчикам и издателю.

Глава 14. Репликация данных Рис. 14.14. Репликация сведением Репликация сведением является самым сложным типом репликации SQL Server 2000. Трудность состоит в отслеживании автономных изменений, сделан ных каждым участником репликации, и их объединение в единую копию. Мо дификация данных выполняется автономно, поэтому не избежать конфликтов изменения. Конфликты изменения происходят, когда два или более участников репликации исправляют у себя одни и те же данные. Механизмы репликации должны решить, какое из изменений должно быть оставлено, а какие — поте ряны. Для решения описанных задач при создании публикации репликации сведением в структуре таблиц выполняют несколько важных трансформаций:

• SQL Server 2000 должен иметь возможность уникально идентифицировать каж дую строку таблицы, чтобы сопоставлять изменения, сделанные на каждом участнике репликации. Идентификатор не должен изменяться с течением вре мени, поэтому в качестве него применяются глобальные уникальные иденти фикаторы (GUID, Global Unique Identifier). Значения GUID хранятся в колон ках специального типа данных — uniqueidentifier, который разработан для хранения глобальных идентификаторов и больше никак не используется. Веро ятность генерирования двух одинаковых значений GUID практически равна нулю. Применяемые алгоритмы гарантируют полную уникальность значений (даже в пределах планеты). При создании публикации репликации сведением SQL Server 2000 ищет в таблице, включенной в публикацию, колонку с типом данных uniqueidentif i e r и установленным свойством ROWGurDCOL. Если такая колонка уже существует, то она будет использована автоматически. В против ном случае будет создана колонка с именем ROWGUID, удовлетворяющая всем указанным требованиям. Кроме того^.эта колонка автоматически индексирует ся для ускорения операций поиска.

610 Часть III. Администрирование Замечание Идентификация строк в репликации сведением по колонке timestamp недопустима, т. к. для этой колонки при каждом изменении строки будет генерироваться новое значение. Тогда как значения в колонке u n i q u e i d e n t i f i e r генерируются при соз дании строки и не меняются с течением времени.

О Каждый из участников репликации должен самостоятельно отслеживать из менения, которые вносятся им в реплицированные данные. Для этого в каж дой таблице, включенной в репликацию, создаются специальные триггеры (triggers), которые автоматически вызываются при каждом выполнении ко манд INSERT, UPDATE, DELETE и сохраняют все выполняемые изменения в специальных таблицах. Триггеры могут отслеживать изменения как на уровне всей строки, так и на уровне отдельной колонки.

(~ Замечание ^ Самая важная часть репликации сведением — отслеживание изменений — стала возможной благодаря тому, что SQL Server 2000 поддерживает одновременно мно жество триггеров каждого типа. В предыдущих версиях SQL Server был реализован единственный триггер на каждую операцию (вставки, изменения или удаления).

Триггеры репликации SQL Server 2000 успешно работают вместе с пользователь скими триггерами.

О Изменения данных, отслеживаемые триггерами репликации, должны быть где-то сохранены. Для этого в базе данных, сконфигурированной для репли кации, создается набор специальных системных таблиц, в которые сохраня ется вся информация о работе репликации сведением.

Замечание Например, таблицы Msmerge_contents и Msmerge_tombstone содержат инфор мацию обо всех выполненных в реплицируемых таблицах командах INSERT, UPDATE и DELETE. Каждая вспомогательная системная таблица имеет колонку ROWGUID, с помощью которой осуществляется связывание пользовательских дан ных со вспомогательной информацией.

После внесения всех необходимых изменений в БД можно приступать к репли кации данных. Как и репликация транзакций, репликация сведением требует выполнения первоначальной синхронизации данных на издателе и подписчиках.

Шаги, выполняемые при первоначальной синхронизации репликации сведени ем, ничем не отличаются от аналогичных шагов в случае репликации транзак ций. Основной этап — подготовка файлов моментальных снимков (ВСР или ТХТ), файлов схемы (SCH) и скриптов (IDX) — выполняется агентом Snapshot Agent, который запускается на дистрибьюторе и подключается к издателю.

(~~ Замечание ^ Более детально процесс первоначальной синхронизации был рассмотрен при опи сании репликации т|*нзакций ранее в этой главе.

Глава 14. Репликация данных При первом подключении подписчика к дистрибьютору агент Merge Agent при меняет подготовленные файлы и выполняет первоначальную синхронизацию.

Сразу после этого агент может применить на подписчике изменения, сделанные на издателе или других подписчиках.

( Замечание ) Агент Merge Agent запускается на дистрибьюторе, если используется принудитель ная репликация (push replication), и на подписчике, если сконфигурирована реплика ция по запросу (pull replication).

Первоначальная синхронизация также может быть выполнена вручную. Для этого следует создать резервную копию базы данных на издателе, затем эту ко пию доставить подписчику и там ее восстановить. Такой подход часто приме няют при работе с большими базами данных, синхронизация которых по кана лам связи займет очень много времени. Скопировав данные и записав их на диск CD-ROM или DVD и отправив его курьерской почтой, можно сэкономить и время, и деньги.

Замечание Выполняя первоначальную синхронизацию вручную, администратор должен позабо титься, чтобы в каждой реплицируемой таблице имелась колонка u m q u e i d e n t i f i e r с установленным свойством ROWGUIDCOL. Кроме того, необходимо обеспечить наличие всех необходимых триггеров и системных таблиц. Лучше всего создание резервной копии данных выполнять сразу же после того, как будет создана реплика ция сведением. В этом случае можно гарантировать, что в базе данных будут иметься системные таблицы, а структура пользовательских таблиц окажется соот ветствующим образом измененной. Но администратор все же должен будет вручную перенести триггеры.

После успешного завершения первоначальной синхронизации подписчики мо гут отключиться от дистрибьютора и начать изменение данных. Триггеры будут автоматически сохранять информацию о внесенных исправлениях в таблицы поддержки репликации на каждом из подписчиков и издателе. Данные об изме нениях во всех реплицируемых таблицах хранятся в таблице Msmergecontents.

Для связи с самими данными предназначен столбец ROWGUID, В котором хранит ся уникальный идентификатор исходной строки. Таблица, к которой принадле жит строка, идентифицируется по колонке TABLENICK. В колонке GENERATION указывается номер сеанса, в котором было произведено изменение. Таким обра зом, в таблице Msmergecontents хранится информация обо всех изменениях в реплицируемых таблицах, сделанных пользователями. Любая модифицирован ная в базе данных строка отображается в единственную строку таблицы Msmergecontents. При многократном изменении одной и той же строки в таб лице Msmerge_contents сохраняется только последнее значение.

Изменения, производимые пользователями в таблицах, не будут отображены на других участников репликации до тех пор, пока не будет выполнено сведение 612 Часть III. Администрирование (merge) данных. Выполняя сведение, Merge Agent подключается к дистрибьюто ру и сохраняет в базе данных распределения D i s t r i b u t i o n информацию об из менениях на локальном сервере. Новая информация сливается с информацией об изменениях, полученной от других участников репликации. Если не возни кают конфликты изменений (любая строка данных изменялась только на одном участнике репликации), то Merge Agent забирает информацию об изменениях, проделанных на других участниках репликации, и применяет их на локальном сервере. На этом процесс сведения заканчивается.

Но часто одни и те же данные бывают модифицированы на нескольких серве рах. В этом случае агент Merge Agent должен разрешить конфликт сведения и определить, изменения какого сервера должны "победить" и будут применены на всех участниках репликации. Для решения этой задачи применяются специаль ные алгоритмы, в основе которых лежит шкала приоритетов. Для каждого, сер вера устанавливается определенный приоритет по 100-балльной шкале. Чем выше приоритет сервера, тем больше вероятность, что его изменения победят.

Наибольший приоритет имеет издатель.

( Замечание ) Помимо шкалы приоритетов, при разрешении конфликтов сведения предназначен номер сеанса (колонка GENERATION) И счетчик изменений в строке (колонки LINEAGE и COLVI). Номер сеанса увеличивается при каждом сведении данных.

По окончании сведения на дистрибьюторе для каждой строки будет установлено единственное значение, которое должно быть скопировано всем участникам репликации. Если при разрешении конфликта изменений локальный сервер "проиграл", то агент Merge Agent сразу же в текущем сеансе обновит данные на нем. Кроме того, будут применены и изменения, сделанные на других участни ках репликации и уже отображенные в базе данных дистрибьютора.

) ( Замечание Система репликации SQL Server 2000 построена таким образом, что, пользователи могут определять свои собственные правила разрешения конфликтов, отличные от стандартных. Это можно сделать при помощи либо специальных хранимых проце дур, либо интерфейса СОМ.

Рассмотренный механизм разрешения конфликтов был единственным, предла гаемым пользователям в SQL Server 7.0. В SQL Server 2000 также активно ис пользуется описанный механизм разрешения конфликтов — он предлагается по умолчанию. Однако помимо этого стандартного механизма в распоряжении, пользователей также имеется набор дополнительных механизмов, которые рас ширяют возможности расширения конфликтов обновления. Можно сказать, что это пользовательские механизмы разрешения конфликтов, разработанные про граммистами Microsoft и поставляемыми в составе SQL Server 2000. Перечислим эти механизмы:,.

-• П Глава 14. Репликация данных • О Microsoft SQL Server Additive Conflict Resolver используется для столбов с числовыми типами данных. При обнаружении конфликта суммируются зна чения, предлагаемые подписчиком, и представленные на дистрибьюторе;

• Microsoft SQL Server Averaging Conflict Resolver также применяется для чи словых типов данных. Результатом разрешения конфликта будет вычисление среднего арифметического для измененных данных;

• Microsoft SQL Server DATETIME (Earlier Wins) Conflict Resolver предназна чен ДЛЯ ТИПОВ ДаННЫХ О дате И Времени (datetime И smalldatetime). Побе дителем будет признано изменение, имеющее более ранее значение даты;

П Microsoft SQL Server DATETIME (Later Wins) Conflict Resolver используется для типов данных о дате и времени (datetime и smalldatetime). Победите лем будет признано изменение, имеющее более позднее значение даты;

О Microsoft SQL Server Maximum Conflict Resolver применяется для числовых типов данных. Победителем считается изменение, имеющее максимальное значение;

П Microsoft SQL Server Merge Text Conflict Resolver используется для символь ных типов данных. Конфликт разрешается путем склеивания значений, предлагаемых обоими участниками конфликта;

• Microsoft SQL Server Minimum Conflict Resolver служит для числовых типов данных. Победителем считается изменение, имеющее минимальное значение;

• Microsoft SQL Server Subscriber Always Wins Conflict Resolver — при исполь зовании этого механизма всегда будет оставляться изменение, предлагаемое подписчиком. Изменения, выполненные издателем или ранее другими под писчиками и отраженные на дистрибьюторе, будут потеряны.

Как видно, основная часть дополнительных механизмов разрешения конфлик тов работает лишь со столбцами определенных типов данных. При этом встает естественный вопрос о том, как же станет разрешаться конфликт изменения других столбцов. Ответ прост. Для разрешения конфликтов изменения других строк будет использоваться стандартный механизм, основанный на приоритете участников репликации.

) ( Замечание Необходимо отметить, что при создании публикации можно будет выбрать либо стандартный механизм разрешения конфликтов, либо один из вспомогательных.

Нельзя сконфигурировать два или более механизмов, которые бы работали с раз ными типами данных.

Как и в случае с репликацией транзакций и репликацией моментальных сним ков, для репликации сведением разработаны специальные задачи, которые ос вобождают ресурсы серверов от ненужных данных:

П Subscription cleanup at the Publisher;

О History cleanup at the Distributor.

614 Часть III. Администрирование Обновление подписчиков До SQL Server 7.0 репликация допускала изменение данных только со стороны издателя. Подписчики могли только принять изменения, выполненные на изда теле. Эта ситуация в полной мере соответствует реальным издателю и подпис чику. То есть издатель выпускает какую-то книгу, журнал и т. д., а подписчик может только читать ее или перепечатать заново (стать издателем и опублико вать реплицированные данные).

Однако пользователей не долго устраивала такая ситуация. Очень скоро они выдвинули новое требование — разрешить выполнять изменения опубликован ных данных и со стороны подписчика. Эта заявка была удовлетворена в SQL Server 7.0. В этой версии SQL Server появились две технологии, разрешающие изменение данных со стороны подписчиков:

О репликация сведением (Merge Replication);

• подписчики незамедлительного обновления (Immediately-Updating Subscribers).

Возможность изменения данных заставляет по-другому взглянуть на отношения издателя и подписчика. Сравнивать их с реальными издателем и подписчиком в этом случае не приходится. Скорее, можно сопоставить их со множеством ре дакторов, вносящих поправки в одни и те же данные.

В предыдущем разделе была рассмотрена репликация сведением, которая позво ляет подписчикам изменять данные, реплицированные с издателя. Неоспори мым достоинством этой технологии является возможность выполнения моди фикаций подписчиками и в том случае, когда между подписчиком и издателем отсутствует постоянное соединение. Строго говоря, репликация сведением как раз и разрабатывалась в расчете на то, что подписчик и издатель (точнее дист рибьютор) будут соединяться лишь изредка и обмениваться изменениями, вы полненными с момента последней синхронизации. Однако обратной стороной медали является наличие конфликтов изменения, возникающих при подобном подходе к внесению исправлений. Механизм, реализующий разрешение кон фликтов, является достаточно тяжелым и требует довольно много системных ресурсов. При этом становится невозможным использование преимуществ реп ликации моментальных снимков или репликации транзакций. В некоторых же случаях более рациональным с точки зрения нагрузки на каналы связи является использование репликации моментальных снимков или репликации транзакций.

Помимо репликации сведением в SQL Server 7.0 была также введена и техно логия незамедлительного обновления подписчиков, которая также позволяет выполнять изменения публикуемых данных со стороны подписчика, однако ис пользует принципиально иной подход к выполнению этих изменений. Необхо димо отметить, что последняя технология не является самостоятельным типом репликации, а является своего рода надстройкой над репликацией моменталь ных снимков и репликацией транзакций. То есть во время применения подпис-, чиков незамедлительного обновления пользователи могут использовать все пре имущества, предоставляемые этими типами репликации. Подробно технология подписчиков незамедлительного обновления будет рассмотрена в следующем разделе. Сейчас же скажем, что изменение выполняется не только на подписчи Глава 14. Репликация данных ке, но и одновременно на издателе. Работа с этой технологией позволяет полно стью избежать возникновения конфликтов изменения данных, однако требует постоянного соединения между подписчиком и издателем. Если соединение отсутствует, то выполнить изменение не удастся.

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

При работе с SQL Server 2000 пользователи могут избежать подобных неприят ных решений. В SQL Server 2000 имеется возможность выполнения изменений со стороны подписчика при работе с репликацией транзакций или моменталь ных снимков и при отсутствии постоянного соединения. Эта возможность реа лизуется технологией отложенного обновления (Queue Updating), при работе с которой не предпринимается попытки отобразить осуществляемые подписчиком изменения на издателе. Взамен информация о выполненных изменениях накап ливается в так называемой очереди (queue). При этом не требуется наличия по стоянного соединения, т. к. очередь представляет своего рода буфер, в который последовательно заносятся выполненные изменения. При установлении соеди нения данные отправляются на дистрибьютор, где они и обрабатываются. Как и при работе с репликацией сведением, отложенная обработка изменений неиз бежно приводит к возникновению конфликтов изменений. Однако при их раз решении в технологии отложенного обновления существуют иные подходы, чем в репликации сведением.

До сих пор мы рассматривали технологии подписчиков незамедлительного об новления и отложенного обновления по отдельности. Однако они могут приме няться и вместе, что позволяет добиться более высокой функциональности. При одновременном использовании обеих технологий приоритет при изменении данных отдается технологии подписчиков незамедлительного обновления. Од нако, если выполнить изменение с помощью этой технологии не удается вслед ствие отсутствия соединения с издателем, то на помощь приходит вторая ука занная технология, с помощью которой и выполняется изменение.


( Замечание ^ Изменения, вносимые с помощью технологии подписчиков незамедлительного об новления, отражаются и на работе технологии отложенного обновления. Это реали зуется путем автоматического изменения на издателе значений в столбце ROWGUIDCOL. Подробно роль этого столбца в технологии отложенного обновления будет рассмотрена в разд. "Отложенное обновление" далее в этой главе.

Безотлагательное обновление В рассмотренной в одном из предыдущих разделов этой главы схеме реплика ции моментальных снимков не предусмотрена возможность отображения изме нений, сделанных на подписчиках, другим участникам репликации. Как и в 616 Часть III. Администрирование, случае с репликацией моментальных снимков, простейшая схема репликации транзакций допускает внесение изменений только на издателе. Даже если на одном из подписчиков и выполнено изменение, оно будет доступно лишь ло кально, причем оно будет потеряно, как только выполнится очередная синхро низация подписчика с издателем. Если нужно донести изменения до всех участ ников репликации, то изменение данных необходимо выполнять на издателе.

Но это не всегда возможно.

Разрешить внесение изменений и на подписчиках можно, если при создании публикации разрешить поддержку подписчиков незамедлительного обновления (immediate updating subscribers). Как уже было сказано, эта технология появилась в SQL Server 7.0 и значительно расширила возможности репликации момен тальных снимков, позволив вносить изменения не только на издателе, но и на подписчиках.

( Замечание ) Поддержка подписчиков незамедлительного обновления устанавливается во время создания публикации. После того как публикация создана, нельзя разрешить или удалить поддержку подписчиков незамедлительного обновления. Рассмотрим, как реализована возможность изменения данных на подписчике.

( Замечание ) Поддержка подписчиков незамедлительного обновления действует только для сер веров SQL Server 2000 и SQL Server 7.0.

Фундаментом работы технологии безотлагательного обновления является двух фазный протокол подтверждения изменений (2РС, two-phase commit protocol), гарантирующий согласованность данных, изменяемых в теле одной транзакции на разных серверах. Протокол 2РС используется координатором распределен ных транзакций (MSDTC, Microsoft Distributed Transactional Coordinator) для фиксирования распределенных транзакций (distributed transactions).

Смысл технологии безотлагательного обновления состоит в том, что при измене нии данных на подписчике одновременйо должно быть выполнено изменение соответствующих данных на издателе. Если посмотреть с другой стороны, то, как и в стандартной схеме репликации моментальных снимков, изменение сначала осуществляется на издателе, а затем тиражируется подписчикам. Только подпис чик, модифицирующий данные, получит обновленную информацию сразу же. Ос тальные подписчики получат измененные данные при следующей синхронизации.

Когда пользователь пытается изменить данные на подписчике, то SQL Server 2000 автоматически мачинает выполнение распределенной транзакции. В теле этой транзакции сервер пытается изменить данные как на подписчике, так и на издателе. Сначала выполняется сравнение соответствующих строк, и при их совпадении начинается изменение данных. В противном случае выполнение изменений прерывается. Такой подход позволяет избежать многократного ис правления разными подписчиками одних и тех же данных. Если подписчик не Глава 14. Репликация данных получил обновленные данные и пытается изменить их, то это ему не удастся, т. к. изменяемые строки у него и издателя будут различаться.

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

Данные с издателя затем будут реплицированы всем другим подписчикам. Под писчик, инициировавший изменение данных, может сразу же работать с новой информацией, не дожидаясь следующей синхронизации. Целостность данных при этом гарантируется автоматически.

Рассмотрим детально принципы функционирования технологии незамедлитель ного обновления. На рис. 14.15 приведена схема обмена данными между издате лем, дистрибьютором и подписчиками незамедлительного обновления.

Рис. 14.15. Подписчики незамедлительного обновления в репликации транзакций При создании публикации с поддержкой подписчиков незамедлительного об новления в таблицах, для которых созданы статьи, SQL Server 2000 автоматиче ски вносит некоторые изменения. В таблицу добавляется колонка с типом дан ных tiniestamp. Каждый раз, когда пользователи изменяют данные в таблице с этой колонкой, сервер автоматически генерирует для нее новое значение. Ко лонка timestamp включается в статью и тем самым создается и на подписчике.

618 Часть III. Администрирование Замечание Дословно timestamp переводится как "временной штамп". Но в действительности значения, хранимые в колонке timestamp, никакого отношения к времени не имеют.

Значения в этой колонке монотонно возрастают и уникальны в пределах базы данных.

То есть в одной базе данных нет двух одинаковых значений timestamp, т. е. гаранти ровано, что вставляемое значение ранее не использовалось.

Кроме того, на подписчике в реплицированных таблицах создаются специаль ные триггеры (triggers), которые перехватывают все попытки пользователя изме нить данные в публикуемых таблицах, отслеживая выполнение команд INSERT, UPDATE и DELETE. Всякий раз, когда пользователь пытается изменить данные в таблице, триггер перехватывает эту попытку и начинает распределенную тран закцию. Вся обработка распределенной транзакции делается прозрачно для триггера координатором распределенных транзакций (MSDTC), который приме няет в своей работе протокол 2РС.

Замечание Если в теле одной транзакции необходимо выполнить изменение множества строк, то такая попытка будет успешна только, если соответствующие строки издателя и подписчика полностью совпадают. При несовпадении даже одной строки вся тран закция откатывается. В этом случае одну большую транзакцию можно разбить на множество маленьких.

Начав выполнение распределенной транзакции, триггер пытается изменить дан ные и на издателе, и на подписчике. Для отслеживания изменений триггер ищет на издателе строку, которая имеет в колонке timestamp то же значение, что и в изменяемой строке на подписчике. Если такая строка не найдена, значит на издателе в исходную строку были внесены изменения и для колонки timestamp этой строки сгенерировано новое значение. В этом случае триггер откатывает распределенную транзакцию, и попытка изменения данных на подписчике за канчивается неудачей. Такой подход позволяет избежать возможных нарушений целостности данных.

Если на издателе имеется строка с нужным значением timestamp, то триггер пытается выполнить изменение данных на издателе. Исправление, допустимое на подписчике, может не пройти на издателе. Причина этого, возможно, заклю чена в том, что другой подписчик ранее выполнил некоторые изменения на из дателе и эти изменения несовместимы с изменениями, которые пытается сде лать триггер. При внесении изменений на издателе осуществляется проверка соответствия новых данных всем установленным ограничениям целостности (constraints) и правилам (rules). Если вносимые триггером изменения недопусти мы, то попытка изменения откатывается.

Если же изменения на издателе прошли успешно, то триггер выполняет изме нение данных и на подписчике. Это предпоследняя стадия технологии незамед лительного обновления. При этом для колонки timestamp модифицируемой строки на издателе генерируется новое значение. То же значение устанавливает ся и на подписчике.

Глава 14. Репликация данных С Замечание j Этот момент очень важен. На подписчике в строке для колонки timestamp не гене рируется новое значение, а копируется с издателя. Это гарантирует, что данный подписчик будет иметь возможность в будущем снова внести изменения в строку, не дожидаясь очередной синхронизации.

На последнем этапе происходит фиксирование распределенной транзакции, в теле которой выполнялось изменение данных. На низком уровне распределенная тран закция представляет набор обычных транзакций, исполняемых в отдельной базе данных. Управление локальными транзакциями и их согласование возлагаются на координатора распределенных транзакций (MSDTC), который и инициирует ло кальные транзакции. Наиболее важная часть функционирования распределенных транзакций заключается в фиксировании локальных транзакций. Этот этап явля ется и самым слабым местом. Предположим, координатор распределенных тран закций отправил команды завершить все локальные транзакции, и буквально сра зу после этого происходит сбой. В итоге одна часть локальных транзакций будет зафиксирована, а другая — нет. Итог может быть печален.

Для решения описанной проблемы используется специальный двухфазный прото кол подтверждения изменений (2РС). Этот протокол гарантирует, что либо все ло кальные транзакции будут зафиксированы, либо для всех будет выполнен откат.

После того как изменения будут успешно внесены, агент Log Reader Agent об наружит их и скопирует в базу данных распределения D i s t r i b u t i o n, откуда они доставятся всем подписчикам. При этом считается, что подписчик, иницииро вавший изменения, уже синхронизирован, и повторное копирование данных к нему не выполняется. Спустя непродолжительное время все участники реплика ции будут иметь одинаковые данные.

С Замечание ) Если изменение на подписчике выполняется не специально, а лишь как часть рас пределенной транзакции, в теле которой есть команды изменения таблиц в различ ных базах данных, то информация о выполненных распределенных транзакциях может быть потеряна. Репликация транзакций в таком случае потерпит неудачу.


Требования безотлагательного обновления Хотя SQL Server 2000 и скрывает от пользователя механизмы, с помощью кото рых становится возможным изменение данных на подписчиках, тем не менее необходимо следовать некоторым правилам:

О Для каждой таблицы, включенной в публикацию с поддержкой подписчиков незамедлительного обновления, необходимо создать колонку timestamp.

Обычно эта колонка создается автоматически при создании публикации, но она может быть создана и вручную. Кроме того, если в статью ВХОДИТ ТОЛЬКО часть таблицы (используется вертикальная фильтрация), то следует убедить ся, что колонка timestamp также включена в статью.

620 Часть III. Администрирование П При вставке строк в публикуемую таблицу с помощью команды INSERT необ ходимо явно указать список колонок. Это поможет выполнить распределен ную транзакцию как на издателе, так и на подписчике. Особенно важно это в случае вертикальной фильтрации, т. к. количество колонок на издателе и подписчике не совпадает.

• SQL Server 2000 не запрещает размещение одной и той же таблицы в не скольких публикациях с поддержкой подписчиков незамедлительного обнов ления. Тем не менее, SQL Server 2000 позволяет в каждой таблице создавать только одну колонку time stamp. Механизмы технологии незамедлительного обновления не смогут отличить, из какой публикации было сделано измене ние данных. Поэтому в данном случае создание подписчиков незамедлитель ного обновления невозможно.

О Для предыдущего пункта существует исключение. Создание подписчика не замедлительного обновления возможно в том случае, если на основе одной таблицы было создано несколько статей, включенных в разные публикации с поддержкой подписчиков незамедлительного обновления, и необходимо подписаться на все публикации с отображением их в одну базу данных под писчика.

П Пользователи не должны никаким образом изменять значения в колонках timestamp. Кроме того, не допускается изменение колонок IDENTITY. ЭТИ колонки обновляются автоматически сервером. Также подписчики не могут модифицировать данные в колонках с типом данных t e x t и image, посколь ку изменение этих колонок невозможно из триггера.

Следование перечисленным требованиям поможет избежать проблем при ис пользовании репликации с поддержкой подписчиков незамедлительного обнов ления.

Отложенное обновление Как уже было сказано, в SQL Server 2000 имеется две технологии, позволяющие выполнять обновление данных на подписчиках при работе с репликацией мо ментальных снимков и репликацией транзакций. Одна их этих технологий — подписчики незамедлительного обновления, была рассмотрена в двух предыду щих разделах. Напомним, что данная технология допускает выполнение изме нений только в том случае, когда между подписчиком и издателем имеется со единение. Если же подписчик пытается изменить данные, которые уже были изменены другим подписчиком, то эта попытка ему не удастся.

Требование постоянного соединения между издателем и подписчиком является существенным недостатком. Довольно, часто постоянного соединения между подписчиком и издателем не существует. Поэтому приходится отказываться от применения технологии подписчиков незамедлительного обновления и работать с репликацией сведение^ взамен использования репликации транзакций или репликации моментальных снимков. Однако такая ситуация существовала в SQL Server 7.0. При работе с SQL Server 2000 в распоряжении пользователей Глава 14. Репликация данных имеется технология отложенного обновления (Queue Updating), которая, как и технология подписчиков незамедлительного обновления, работает совместно с репликацией моментальных снимков или репликацией транзакций. На рис. 14.16 приведена архитектура технологии отложенного обновления.

Рис. 14.16. Архитектура технологии отложенного обновления Уже по названию технологии можно отметить главную ее особенность — возмож ность применять выполненные на подписчике обновления не сразу же, а с неко торой задержкой. Причем эта задержка может длиться довольно долго. Конечно, в идеальной ситуации выполненные изменения сразу же отображаются на издателе.

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

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

данных, даже если соединение с издателем и отсутствует. Информация о выполненных изменениях записывается в так называемую очередь (queue). Оче 622 Часть III. Администрирование редь представляет собой буфер, который накапливает информацию о всех вы полненных на подписчике изменениях. Однако забота об обработке этих изме нений ложится уже на дистрибьютора. То есть подписчик считает изменение выполненным, как только данные о нем будут сохранены в очереди. Если по каким-то причинам информация о выполненных изменениях не может быть помещена в очередь, то эти изменения не будут зафиксированы. Помещение информации в очередь считается частью транзакции и если эта часть не будет выполнена, то будет осуществлен откат всей транзакции, включая и собственно изменение данных.

Интересным моментом в технологии отложенного обновления является собст венно очередь. Этот механизм позволяет не заботиться о доставке данных на нужный компьютер. Достаточно сохранить информацию в очередь и специаль ные механизмы позаботятся о доставке данных. В обычной ситуации пользова тель должен сам контролировать доставку данных на нужный компьютер. Ко нечно, когда имеется постоянное соединение, то проблем не возникает. Однако, в случае отсутствия постоянного соединения можно довольно долго ожидать его установления. То есть нужно будет постоянно проверять наличие соединения и пытаться сохранить данные. Если говорить о пользовательском приложении, то для них в большинстве случаев подобный подход неприменим. Однако, пробле ма с доставкой данных не пропадает. Специально для ее решения, а также для стандартизации механизмов обмена данных между удаленными компьютерами, были реализованы очереди.

( Замечание ) В общем случае каждая очередь характеризуется своим собственным именем, по которому и выполняется работа с ней. Однако подсистема репликации создает со ответствующую очередь автоматически и не требует явного указания ее свойств, в том числе и имени.

Все сказанное выше относится в основном к очередям, реализуемым специали зированными продуктами. Однако SQL Server 2000 может использовать и очере ди, организованные собственными методами. Рассмотрим же подробно, какие типы очередей существуют для отложенного обновления и каковы особенности этих очередей:

П Microsoft Message Queue. Тип очередей реализуется специальным програм мным обеспечением, т. е. очереди этого типа являются настоящими очередя ми, которые могут быть использованы для доставки самых разнообразных данных — значений переменных, текстовые сообщения, файлы, а также лю бые другие данные, в том числе и данные о выполненных на подписчике из менениях. Чтобы иметь возможность использовать для отложенного обнов ления очереди рассматриваемого типа, необходимо предварительно уста новить либо Microsoft SQL Server 2000 queue, либо Microsoft Message Queuing версии 2.О. Это является серьезным недостатком, т. к. инсталляция дополни тельного программного обеспечения привлечет к увеличению нагрузки на все серверы SQL Server 2000, участвующие в репликации и использующие технологию отложенного обновления. Однако необходимо отметить и оче Глава 14. Репликация данных видное достоинство — очередь является независимой от SQL Server. To есть после выполнения изменений опубликованных данных на подписчике мож но вообще остановить SQL Server 2000, и это не воспрепятствует распростра нению изменений на других участников репликации. При использовании очередей типа Microsoft Message Queue подписчик сохраняет информацию о выполненных модификациях в очередь и механизмы Message Queue достав ляют информацию на дистрибьютор, где они помещаются в соответствую щую очередь, откуда затем и считываются агентом Queue Reader Agent.

О SQL Server. Этот тип очередей представляет собой всего-навсего обычную таблицу SQL Server 2000 с именем MSRepiication_queue, которая создается автоматически при инициализации технологии отложенного обновления. Не сомненным преимуществом очередей данного типа является отсутствие необ ходимости установки дополнительного программного обеспечения, т. е. оче редь этого типа может быть реализована под управлением любой опера ционной системы, на которую разрешена установка SQL Server 2000 — Win dows 98/NT/2000. Считывание данных из созданных на подписчиках таблиц MSReplicationqueue осуществляется агентом Queue Reader Agent, который запускается на дистрибьюторе. Для считывания данных предназначена недо кументированная системная хранимая процедура sp_sqlqmon. Таким обра зом, основная часть нагрузки по считыванию данных о выполненных на подписчиках изменениях ложится на дистрибьютора. Подписчик же должен только сохранить информацию в указанную таблицу. Использование очере дей SQL Server также характеризуется более высокой скоростью выполнения изменений за счет того, что запись информации об изменениях выполняется теми же механизмами, что и собственно осуществленные изменения.

Мы неоднократно упоминали, что информация о выполняемых изменениях со храняется в очереди, однако до сих пор не говорили о механизмах, которые собственно сохраняют эту информацию. Пришло время приподнять завесу. От слеживание и запись информации об изменениях, выполняемых с опубликован ными данными, осуществляется с помощью специальных триггеров, создавае мых автоматически при инициализации технологии отложенного обновления.

Триггеры создаются для каждой операции изменения данных — DELETE, INSERT и UPDATE. Информация о выполняемых изменениях упаковывается специальным образом и помещается в очередь. На этом работа триггера заканчивается. Ника ких действий по дополнительной обработке данных не предпринимается.

( Замечание ) Необходимо отметить, что триггеры поддержки технологии отложенного обновления создаются с ключом NOT FOR REPLICATION, ЧТО позволяет избежать их выполне ния при изменении данных в таблицах подсистемой репликации. Такие изменения, например, постоянно выполняются при использовании репликации транзакций.

Помимо создания на подписчике триггеров для опубликованных таблиц, при инициализации технологии отложенного обновления в публикуемой базе дан ных издателя также выполняются некоторые изменения. В частности, создается 01 9» 11лт 624 Часть III. Администрирование набор системных хранимых процедур, которые будут выполнять изменение опубликованных данных. Эти изменения являются отображением изменений, выполненных на подписчиках. На первый взгляд может показаться, что нет ни чего сложного в применении выполненных на подписчиках изменений, и впол не можно было обойтись обычными командами UPDATE, DELETE И INSERT. Одна ко в этом случае будет невозможно отследить изменения, произведенные другими пользователями.

Хранимые процедуры не просто осуществляют изменения, но также и отслежи вают конфликты обновления и при их обнаружении разрешают их. Для выпол нения изменений используется довольно сложный механизм, который гаранти рует отслеживание конфликтов изменения данных. Поэтому разработчики Microsoft решили реализовать механизмы применения изменений в виде храни мых процедур, а не встраивать их непосредственно в агент Queue Reader Agent.

Это также позволяет легко использовать различные механизмы разрешения конфликтов обновления, в том числе и написанные пользователями. В зависи мости от механизма разрешения конфликтов хранимые процедуры могут подго товить набор так называемых компенсационных команд, которые должны при меняться к конкретному подписчику для приведения его данных в соответствие с данными издателя. Запуск компенсационных команд позволяет на програм мном уровне выполнить отмену изменений, внесенных на подписчике и отме ненных на издателе, как результат разрешения конфликта изменения.

Раз уж начали говорить о конфликтах изменения и их разрешение, то следует рассмотреть их более подробно. Во-первых, прежде чем приступать к решению конфликтов изменения, следует сначала их обнаружить. Для этого предназначе ны столбцы ROWGUIDCOL, которые используются в качестве идентификатора строки таблицы. Столбец ROWGUIDCOL имеет тип данных u n i q u e i d e n t i f i e r. В качестве значения по умолчанию для этого столбца применяется функция NEW (). Таким образом, каждая строка публикуемых данных идентифицируется глобальным уникальным идентификатором (GUID, Global Unique Identifier). Бо лее того, специальный триггер поддержки отложенного обновления меняет зна чение в столбце ROWGUIDCOL каждый раз, когда выполняется изменение данных в таблице. При сохранении информации о выполненных на подписчике изме нениях указывается как старое значение GUID, так и новое.

Когда информация об изменениях принимается на дистрибьюторе агентом Queue Reader Agent, она распаковывается, после чего агент пытается найти в таблице издателя строку со старым значением GUID. Если такая строка найде на, то это означает, что хранящиеся на издателе данные не были изменены, т. е.

конфликта изменений нет. Когда же строка отсутствует, это означает, что дан ные на подписчике были изменены со времени последней синхронизации под писчика. То есть возникает конфликт изменения данных. В этом случае агент ;

Queue Reader Agent должен разрешить конфликт.

У внимательного читателя уже наверняка возник вопрос, а как же выполняется идентификация нужной строки данных на подписчике, если происходит кон фликт изменения. Действительно, если значение GU1D было изменено, то как найти нужную строку? Разгадка кроется в том, что для идентификации строк ис Глава 14. Репликация данных пользуется не значение GUID, а первичный ключ. Значение первичного ключа измененной строки упаковывается на издателе вместе со значением GUID и соб ственно измененными данными и отсылается дистрибьютору. При обнаружении конфликта агент Queue Reader Agent находит нужную строку и либо выполняет ее изменение на издателе, либо генерирует набор компенсационных команд для подписчика. В обоих случаях строка идентифицируется по первичному ключу.

Остается только рассмотреть, как же выполняется разрешение конфликтов об новления в технологии отложенного обновления. Как и в репликации сведени ем, при разрешении конфликта имеется победитель (winner) и проигравший (loser). Кто именно (издатель или подписчик) будет победителем и проиграв шим, зависит от используемого метода разрешения конфликтов. В распоряже нии пользователей имеется три стандартных метода разрешения конфликтов:

П Reinitialize Subscriber. Метод предполагает выполнение повторной инициали зации подписчика при обнаружении конфликта изменения. То есть если данные на подписчике были модифицированы, то изменения подписчика в любом случае отвергаются. Для него будет подготовлен новый моментальный снимок, который и применится на подписчике. До тех пор, пока подписчик не будет синхронизирован, сгенерированные им изменения на издателе не вступят в силу. Как и при выполнении первоначальной синхронизации, применение моментального снимка выполняется агентом Distributor Agent.

П Publisher wins. При использовании этого метода победителем всегда является издатель. Конечно, если данные на издателе еще не исправлялись, то изме нения подписчика применяются. Когда же другой подписчик попытается из менить те же данные, то агент Queue Reader Agent оставляет изменения, вы полненные первым подписчиком, и генерирует для второго подписчика набор компенсационных команд, с помощью которых осуществляется откат выполненных на подписчике изменений.

П Subscriber wins. В этом случае победителем всегда является подписчик. След ствием данного подхода является потеря изменений, выполненных всеми подписчиками ранее текущего изменения. То есть будет доступно только са мое последнее изменение. Синхронизация других подписчиков выполняется стандартными средствами. При использовании репликации моментальных снимков это будет полный набор данных, тогда как для репликации транзак ций — набор транзакций, выполняющий соответствующие изменения в таб лицах подписчика.

На этом рассмотрение технологии отложенного обновления можно считать оконченным.

Выбор топологии репликации Для работы системы репликации администратор должен сконфигурировать из дателя, дистрибьютора и одного или более подписчиков. Как уже говорилось, SQL Server 2000 Не ставит жёстких рамок на размещение каждого из участников репликации. Администратор может использовать отдельные серверы для каж 626 Часть III. Администрирование дого из участников репликации или сконфигурировать их все на одном единст венном сервере.

В этом разделе будут рассмотрены различные топологии репликации. Топология определяет, где должен запускаться каждый из участников репликации. Допус тимы следующие модели:

О Репликация "один-ко-многим". Это наиболее часто используемая топология, предполагающая наличие единственного издателя и одного или более под писчиков. Наиболее часто эта модель топологии реализуется в системах, имеющих четко выраженную иерархическую зависимость. Схема топологии "один-ко-многим" представляет собой звезду. В центре располагается изда тель, а на периферии — подписчики. Дистрибьютор в этом случае работает, либо на отдельном сервере, либо на издателе.

О Репликация "многие-к-одному". Топология встречается гораздо реже. Она ха рактеризуется множеством издателей и единственным подписчиком и часто применяется в системах поддержки принятия решений (DSS, Decision Support Systems). Данные из множества филиалов, работающих самостоя тельно, сливаются в центральную систему, где они анализируются и хранят ся. Обратная связь с филиалами не обязательна, т. к. в системах поддержки принятия решений данные предназначены в основном только для чтения.

• Репликация "многие-ко-многим". В этом случае каждый из издателей имеет множество подписчиков, причем каждый из подписчиков реплицирует дан ные со множества издателей. Топология "многие-ко-многим" может быть применена в организациях со множеством центральных серверов, каждый из которых выполняет свою собственную роль. В филиалах имеется масса под писчиков, выполняющих одинаковые задачи и нуждающихся в связи со все ми центральными серверами.

Все возможные варианты топологии не ограничиваются приведенными моделями.

SQL Server 2000 позволяет создавать сложные разветвленные системы со сложной топологией системы репликации. Например, в центральном офисе могут сущест вовать несколько серверов, обменивающихся данными друг с другом. В филиалах сконфигурирован основной сервер, который реплицирует данные с одного из центральных серверов. Этот сервер затем публикует полученные данные в своем регионе. При этом могут комбинироваться различные типы репликации.

Важную роль в создании системы репликации играет выбор места размещения дистрибьютора, который может работать на отдельном сервере, на издателе или на одном из подписчиков.

Управление издателем и дистрибьютором Все задачи, связанные с практической работой с издателем, подписчиком и ди стрибьютором, а также создание публикации и подписки на нее, можно обозна чить как администрирование репликации. Традиционно выполнение админист ративных задач в SQL Server 2000 может осуществляться тремя способами:

Глава 14. Репликация данных О системные хранимые процедуры поддержки репликации;

....,,,.

П возможности графического интерфейса Enterprise Manager;

• набор мастеров работы с репликацией.



Pages:     | 1 |   ...   | 15 | 16 || 18 | 19 |   ...   | 33 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.