AS SELECT COMPANY, SUM(AMOUNT)

FROM CUSTOMERSeREMOTE, ORDERS@REMOTE WHERE CUST = CUST NUM GROUP BY COMPANY

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

Двунаправленная репликация

в простейшем случае (см. рис. 22.3) таблица связана с каждой своей репликой сфогим соотношением главная/подчиненная Центральная (главная) таблица содержит реальные данные Это всегда самая последняя информация, и она должна обновляться приложениями только в главной таблице. Копии периодически обновляются в пакетном режиме самой СУБД. В промежутках между обновлениями их информация может оказаться несколько устаревшей, но если база данных сконфигурирована таким образом, значит, это приемлемая плата за преимущество использования локальных копий данных. Приложениям не разрешается обновлять данные, содержащиеся в копиях реплицированной таблицы. В случае подобной попытки СУБД генерирует ошибку.

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

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

в портативных компьютерах торговых менеджеров При этом все менеджеры должны иметь возможность вводить в свои реплики информацию о новых клиентах или изменять данные о старых клиентах Для всех этих (и многих других) типов приложений наиболее эффективной является схема, при которой все реплики допускают модификацию своего содержимого (рис 22 4)

Центральный сервер

СУБД

База данных на портативном ПК

Добавление/ обновление/ выборка

Добавление/ обновление/ > выборка

CUSTOMERS

Добавление/ обновление/ выборка

Рис. 22.4. Скема двунаправленной репликации

В связи с поддержкой реплицированных таблиц, все копии которых должны принимать изменения, возникает целый ряд проблем, связанных с целостностью данных Что произойдет, если одна и та же строка таблицы будет обновлена в нескольких репликах? Когда СУБД будет синхронизировать эти реплики, какой из двух вариантов строки она должна будет принять? Может быть, следует отклонить оба изменения или попробовать их объединить? А что если из одной реплики строка будет удалена, а в другой модифицирована?

В СУБД, под11ерживающих двунаправленную репликацию, все эти вопросы решаются путем определения набора правил для разрешения конфликтов, и эти правила автоматически используются подсистемой репликации Например, правило может говорить о том, что в случае конфликта между обновлением в центральной базе данных и базе данных на портативном компьютере всегда побеждает обновление в центральной таблице Или же правило может устанавливать приоритет самого последнего обновления В дополнение ко встроенным правилам, определяемым самой СУБД, подсистема репликации может поддерживать возможность разрешения конфликтов с помощью пользовательских подпрофамм (например, хранимых процедур). Такая подпрограмма может решить, какая реплика победит , а какая про-Ифаег , учитывая особенности конкретных операций над данными

Затраты на репликацию

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

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

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

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

Типичные схемы репликации

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