чиками. Применение данного варианта позволяет передавать данные только в одну систему на дальнем конце канала связи, после чего подписчик/издатель распространяет данные по другим подписчикам.

Издатель/подписчик

Это - еще один вариант организации работы системы репликации, в котором отдельные экземпляры СУБД SQL Server действуют и в качестве издателей, и в качестве подписчиков (рис. 20.12). При этом в каждой базе данных подписчика хранится собственное множество данных, за которое он отвечает. Такая модель может использоваться, если между собой связаны две базы данных, изменения в данных могут происходить в обеих базах данных, и требуется обеспечить постоянную синхронизацию обеих баз данных путем взаимной передачи обновлений. Отличие этой модели от модели публикующего подписчика состоит в том, что в каждой базе данньгх подписчика могут осуществляться собственные изменения в данных, а не только передаваться обновления, полученные из другой базы данных.

Рги:. 20.12. Модель решикации с шдателем/подпгссчиком

Несколько издателей/несколько подписчиков

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

Самопубликация

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

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

Издатель/ подписчик

Издатель/ подписчик

Издатель/ подписчик

Рис. 20.13. Модель репликации с несколькими издателями/несколькими подписчиками

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

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

Репликация относится к одной из тех областей деятельности разработчика, в которых господствуют взгляды, что не ьгжно слишком много думать и достаточно лишь применить суш;ествуюш;ие средства . Тем не менее именно в этой области можно столкнуться с наибольшими затруднениями, попьггавшись применить столь легкомысленный подход. Следует учитывать, что в ходе реализации системы репликации СУБД SQL Server может автоматически ввести некоторые изменения в схему, поэтому разработчик обязан заранее обдумать вопрос о том, какие столбцы и прочие объекты будут введены средствами СУБД SQL Server в базу данных в процессе развертывания системы репликации. В противном случае результаты могут оказаться непредсказуемыми.

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

Объем данных, подлежащих репликации.

Тип репликации.

Модель репликации.

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

Учет требований к обработке данных в ходе репликации

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

Столбец С типом данных timestamp

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