Объединение данных с нескольких узлов (сервер)

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

• Данные о материальных запасах могут быть «накоплены» или объединены с ряда серверов локальных оптовых баз для передачи на центральный сервер главного управления корпорации.
• Данные самостоятельных подразделений предприятия могут быть отправлены на центральный сервер.
• Сведения об обработке заказов распределенных отделений могут быть объединены.

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

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

Пример компании Adventure Works Cycles

Adventure Works Cycles — это вымышленная производственная компания, которая используется для демонстрации концепций баз данных и сценариев работы с ними. Дополнительные сведения см. в разделе Примеры и образцы баз данных.

У компании Adventure Works Cycles имеется ряд региональных офисов продаж на территории США. Эти офисы используют репликацию в двух случаях:

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

Общие рекомендации для этого сценария

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

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

Типы репликации, доступные для использования в этом сценарии

Microsoft SQL Server использует терминологию издательской отрасли для описания компонентов системы репликации. Компоненты включают издатель, подписчики, публикации, статьи и подписки.

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

Дополнительные сведения о компоненте системы см. в разделе Обзор модели публикации репликации.

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

По своей конструкции репликации транзакций удовлетворяют главным требованиям этого сценария:

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

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

Шаги реализации этого сценария

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

• Настройка распространителя
• Публикация данных и объектов базы данных
• Подписка на публикации
• Инициализация подписки

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

• Мониторинг репликации
• Стратегии резервного копирования и восстановления из копии репликации моментальных снимков и репликации транзакций
• Диагностика при репликации
• Удаление репликации

См. также

Другие ресурсы

Репликация данных в серверной среде

Справка и поддержка

Получение помощи по SQL Server 2005