Планирование репликации
Настройка системы безопасности сети
Подготовка серверов
Установка дистрибутора
Установка издателя
Установка подписчика
Процесс публикации
Вопросы для повторения

Планирование репликации

Разработка структуры репликации аналогична конструированию базы данных: сначала необходимо планировать логическую структуру, а затем физическую реализацию. При этом необходимо ответить на следующие вопросы:
Какие данные будут публиковаться? В среде распределенных данных серверам подписки, как правило, необходимо держать у себя лишь какую-то часть содержимого базы данных. Если реплицировать только требуемые данные, то можно сократить размеры используемого дискового пространства, время обработки и объем сетевых операций ввода-вывода.
Подумайте о том, как лучше группировать статьи. Будут ли данные публиковаться подмножествами, например, по группам, по узлам, по регионам? В модели с центральным подписчиком и несколькими издателями (Central Subscriber/Multiple Publisher) каждый узел должен публиковать все свои таблицы, а центральный узел должен подписаться на каждую публикацию. Для распространения данных необходимо пойти одним из двух путей:
 - создать одну публикацию с глобальными данными, на которую подпишутся все узлы, и по одной публикации для каждого подписчика с данными, выделяемыми именно для этого подписчика;
 - создать одну публикацию для каждого подписчика, включающую и глобальные данные, и выделенные данные.
Кто получает данные? Какие серверы будут подписываться на данные? Какими характеристиками обладают серверы назначения? Известны ли они или отключены? Если узлы предполагается наделить возможностями обновления, нужно подумать о том, как разрешать конфликты.
Как часто данные следует синхронизировать? Как будет проводиться синхронизация - по расписанию или по запросу?
Если используемое приложение допускает задержку данных, можно составить расписание так, чтобы обновление выполнялось редко.
Каковы характеристики сети? Рассмотрите следующие аспекты:
 - Доступны ли сетевые узлы всегда или только в определенные интервалы времени? Если узлы доступны не всегда, можно воспользоваться методом репликации с большей задержкой.
 - Быстро ли работает сеть? Если быстродействие низкое, возможно, имеет смысл уменьшить объем передаваемых по сети данных путем фильтрации. При наличии медленного канала связи можно установить отдельный сервер дистрибуции.
 - Какова пропускная способность сети? Если пропускная способность невелика, подумайте об использовании удаленных дистрибуторов. Определите, в какое время дня наблюдается наиболее высокий уровень активности. Это особенно важно в случае синхронизации автономных подписчиков в периоды пиковых нагрузок. Учитывайте это при составлении расписания.
 - Насколько надежно работает сеть? Если сбои в сети нередки, было бы неблагоразумно использовать план репликации, включающий распределенные транзакции.
Какой должна быть топология репликации? Какой тип репликации предполагается использовать? Кто инициирует процесс репликации? Сколько будет подписчиков? Каковы требования к выделяемому пространству?
Планируя физическую реализацию логической структуры, необходимо решить ряд вопросов.
Какой должна быть топология репликации? Какую топологию репликации планируется реализовать? Распределение ролей серверов определяет физическую структуру репликации:
 - Выберите модель репликации.
 - Определите, какой дистрибутор будет использоваться - локальный или удаленный.
 - Oпределите, будет ли база данных distribution открыта для совместного пользования. Если несколько издателей работают с одним дистрибутором, будет ли у каждого из них своя собственная база данных distribution на своем сервере? Или они будут пользоваться общей базой данных distribution?
Какой тип репликации предполагается использовать? Можно выбрать репликацию моментальных снимков (snapshot replication), репликацию транзакций (transactional replication) или репликацию слиянием merge replication).
Кто инициирует процесс репликации? В случае принудительной подписки (push subscription) используются ресурсы дистрибутора, а в случае подписки по запросу (pull subscription) -ресурсы подписчика.
Сколько будет подписчиков? Если правильно оценить число подписчиков, это поможет определить нагрузку на сервер распределения. Каковы требования к выделяемому пространству? Размеры журналов транзакций всех баз данных, участвующих в репликации, а также размеры базы данных distribution и рабочей папки дистрибутора зависят от следующих факторов:
 - числа публикаций и статей;
 - частоты выполнения репликации;
 - величины задержки при репликации;
 - типа репликации.
Данные назначения должны быть описаны с определенными характеристиками, поскольку некоторые характеристики не могут быть реплицированы или изменяются при репликации. При определении данных необходимо рассмотреть следующие вопросы:
Использование при репликации некоторых типов данных, перечисленных в следующей таблице, имеет специфические последствия.

Тип данных	Эффект
Timestamp	Указывает хронологический порядок операций сервера, выполнявшихся над строкой. Это значение реплицируется в базу данных подписчика как значение типа binary. Данные типа Timestamp не имеют никакогоотношения к полям даты/времени.
uniqueidentifer	Идентификатор GUID (Global Unique Identifier- глобально уникальный идентификатор). Применяется при репликации слиянием, когда объединяются строки с разных серверов. Используется вместе с функциейNEWID, генерирующей идентификационный номер. Тип данных реплицируется, ункция - нет.
Определяемый пользователем	Данный тип реплицируется только в том случае, если онсуществует в базе данных подписчика.

Замечание: Чтобы результаты запросов в отношении данных, реплицируемых с одного сервера на
другой, были согласованы, рекомендуется на каждом сервере, участвующем в репликации, использовать один и тот же набор символов и порядок сортировки. Это условие не обязательное, но оно гарантирует единообразную обработку запросов для всех серверов.
Использование свойства IDENTITY Значение столбца, для которого установлено свойство IDENTITY, реплицируется, но само свойство не реплицируется. В начальном моментальном снимке столбцы, обладающие свойством IDENTITY, по умолчанию преобразуются в базе данных подписчика в столбцы целочисленных значений. Это преобразование осуществляется таким образом, чтобы значения у подписчика совпадали со значениями у издателя.
Чтобы выполнить разбиение данных в каждом узле, можно на сервере подписчика снова создать столбец со свойством IDENTITY. При этом необходимо сделать следующее:
 - использовать соответствующие начальные значения и ограничения CHECK во избежание конфликтов;
 - используя тип данных uniqueidentifer и функцию NEWID, сгенерировать уникальный ключ.
Использование параметра NOT FOR REPLICATION: Данный параметр позволяет во время репликации при добавлении данных на сервер подписчика отменить некоторые характеристики, например, свойство IDENTITY, ограничение CHECK и триггеры. Если же данные добавляются пользователями, то при использовании этого параметра указанные характеристики сохранят свой смысл. Данный параметр весьма полезен в модели с несколькими издателями и несколькими подписчиками (multiple publisher/multiple subscriber).

Настройка системы безопасности сети

Прежде чем приступать к реализации плана репликации, следует проверить, соблюдены ли некоторые важные требования.
Установка доверительных отношений между доменами: Если серверы, участвующие в репликации, принадлежат разным доменам системы Windows NT необходимо установить доверительные отношения между этими доменами. Подробнее об установке доверительных отношений см. справочную систему операционной системы Windows NT.
Проверка учетной записи домена Windows NT для службы SQL Server Agent: По умолчанию репликация использует учетную запись пользователя домена системы Windows NT, назначенную службе SQL Server Agent:
 - Рекомендуется использовать одну и ту же учетную запись пользователя домена службы SQL Server Agent для всех серверов, участвующих в транзакции.
 - Проверьте, обладает ли учетная запись пользователя домена системы Windows NT для службы SQL Server Agent административными полномочиями. Для этого учетная запись должна быть членом локальной группы Administrators системы Windows NT.
Вместо учетной записи системы Windows NT можно также использовать учетную запись подключения SQL сервера.
Замечание: В качестве учетной записи системы Windows NT для службы SQL Server Agent нельзя использовать учетную запись Local System (локальная система) или учетную запись локального пользователя, поскольку ни та, ни другая не обеспечивает доступа к сети.

Подготовка серверов

Для подготовки серверов можно воспользоваться услугами мастера Configure Publishing and Distribution Wizard (мастер настройки средств публикации и дистрибуции) в программе Enterprise Manager. Установка сервера дистрибутора и сервера издателя осуществляется в ходе одного процесса. После того как они установлены, можно определять публикации и подписываться на них.
Замечание: Все серверы, участвующие в репликации, должны быть зарегистрированы в программе Enterprise Manager.

Установка дистрибутора

Установка дистрибутора должна предшествовать установке обслуживаемых им издателей. Для создания дистрибутора необходимы права системного администратора. После того как дистрибутор установлен, можно просматривать свойства локального или удаленного дистрибутора.
Настройка базы данных distribution: База данных distribution принадлежит типу баз данных промежуточного хранения (store-and-forward) и предназначена для хранения транзакций, ожидающих распределения по подписчикам; она устанавливается автоматически вместе с дистрибутором.
Вы можете также сделать следующее:
 - задать существующий удаленный сервер дистрибуции или создать новую базу данных distribution на сервере, установленном в качестве дистрибутора;
 - определить одну или несколько баз данных distribution, каждая из которых поддерживает одну или несколько публикаций.
Проверка доступности рабочей папки службы дистрибуции: Убедитесь, что рабочая папка службы дистрибуции доступна для агентов репликации, которые должны ею пользоваться. Понадобится ли она агенту - это зависит от типа репликации и режима использования удаленного дистрибутора. Рабочая папка (\имя_компьютера\C$\MSSQL7\ReplData) службы дистрибуции устанавливается по умолчанию на серверах, работающих под управлением NT.
Замечание: Если дистрибутор установлен на компьютере, работающем под управлением системы Windows 95/98, то для доступа к значениям по умолчанию рабочая папка должна быть явно предоставлена для совместного пользования под именем C$. Эта папка доступна только учетным записям пользователей домена, имеющим административные разрешения, и должна быть доступна учетной записи, используемой агентами репликации.
Обеспечение достаточного объема памяти: Необходимо также убедиться, что для сервера дистрибутора отведено нужное количество памяти. Дистрибутор не должен испытывать недостатка в ресурсах; исходить при их выделении следует из предполагаемого объема данных и числа подписчиков.
Меры предосторожности при удалении дистрибутора: Удавление дистрибутора осуществляется с помощью мастера Uninstall Publishing and Distribution Wizard (мастер удаления средств публикации и дистрибуции). В результате удаления дистрибутора происходит следующее:
 - с сервера дистрибуции удаляются все базы данных distribution;
 - все издатели, пользовавшиеся данным дистрибутором, отключаются, и все публикации на этих серверах удаляются;
 - удаляются все подписки на упомянутые публикации (но данные, полученные подписчиками по подписке, не удаляются).
Настройка дистрибутора: После того как база данных distribution установлена, можно проводить её настройку, задавать свойства и изменять.
Установка свойств базы данных distribution: С помощью мастера настройки средств публикации и распределения можно задать для каждой базы данных distribution следующие свойства:
 - имя базы данных и спецификации файлов;
 - параметры срока хранения данных протокола;
 - параметры срока хранения записей о транзакциях.
Обеспечение достаточного объема пространства: Убедитесь, что в рабочей папке службы дистрибуции и в базе данных distribution достаточно свободного места:
 - В случае репликации моментальных снимков и репликации слиянием данные хранятся в рабочей папке службы дистрибуции, в базе данных distribution отслеживается только состояние.
 - В случае репликации транзакций в базе данных distribution необходимо хранить реплики для всех издателей и подписчиков. Поскольку в базе данных distribution содержатся все транзакции, ожидающие дистрибуции, размер этой базы данных имеет ключевое значение.
Какой бы ни использовался тип репликации, при определении размера базы данных distribution необходимо учесть следующее:
 - Общее число публикуемых таблиц.
 - Число столбцов и объем данных типов text и image в статье.
 - Размер статей.
 - Максимальное время хранения транзакций и протокола.
Дистрибутор хранит сведения о транзакциях до тех пор, пока они не будут применены ко всем базам данных подписчиков. Некоторые подписчики могут пребывать в автономном режиме. В случае репликации транзакций следует принять во внимание ряд дополнительных факторов:
 - число операторов INSERT и UPDATE, поскольку каждый из них содержит данные;
 - примерное число транзакций в секунду;
 - средний размер транзакции.
Удаление базы данных distribution: Базу данных distribution можно удалить без отключения дистрибутора: для этого нужно предварительно отключить всех издателей, использующих эту базу данных distribution.

Установка издателя

Установив базу данных distribution, можно назначать серверы, ответственные за публикацию. Кроме этого, необходимо разрешить публикацию в базах данных. Установка параметров издателя включает следующие действия:
 - Задайте базы данных, которые будут публиковать свое содержимое.
 - Задайте серверы, которым будет разрешено использовать данный сервер-издатель в качестве своего удаленного сервера дистрибутора.
 - Включите подписчиков и установите параметры дистрибуции: задайте максимальное число фиксируемых транзакций на один пакет для подписчика; в случае репликации транзакций составьте расписание дистрибуции таким образом, чтобы транзакции реплицировались в непрерывном режиме или планировались на определенное время (по умолчанию устанавливается непрерывная репликация).
 - Убедитесь, что на сервере-издателе достаточно места для журнала транзакций, чтобы в него можно было помещать транзакции, когда недоступен дистрибутор. Журнал транзакций издателя нельзя очищать до тех пор, пока не будут распределены все ожидающие транзакции.
Если используется удаленный дистрибутор, убедитесь, что работающий на нем агент создания моментальных снимков имеет во время репликации доступ к издателю, а также к рабочей папке службы дистрибуции. Проще всего использовать одну и ту же учетную запись пользователя домена службы SQL Server Agent и для издателя, и для дистрибутора.
Замечание: Соблюдайте осторожность при изменении базы данных distribution, используемой каким-либо издателем, так как для этого придется отключить издателя, удалить все публикации и подписки, а затем установить тот же сервер публикации в качестве нового издателя с другой базой данных distribution.

Установка подписчика

При установке подписчика рассматриваются следующие вопросы: Подготовка подписки: Чтобы на сервере можно было подписываться, сделайте следующее:
 - Выберите серверы публикации, которые будут реплицироваться на данный сервер.
 - Выберите базы данных назначения для реплицируемых публикаций. Если базы данных назначения не существует, ее нужно создать.
 - Проверьте, действительна ли ваша учетная запись для доступа к дистрибутору и его рабочей папке.
Если вы получаете подписку по запросу с удаленного дистрибутора, убедитесь, что агент дистрибуции или агент слияния, работающий на сервере-подписчике, имеет доступ к рабочей папке службы дистрибуции.
Изменение свойств подписчика: После того, как подписчики подготовлены к приему публикации, может потребоваться изменить свойства какого-либо подписчика. Изменять разрешено следующие свойства:
 - Описание подписчика.
 - Режим безопасности.
 - Расписание по умолчанию (непрерывное распределение или согласно установленному расписанию).
Замечание: Изменение последнего свойства не влияет на расписания существующих подписок.
Отключение подписчика: Отключить подписчика можно на сервере-издателе. Будут автоматически отменены подписки на все публикации. Однако удалять базу данных подписчика или какие-либо ее объекты вправе только администратор сервера-подписчика.

Процесс публикации

Перед проведением подписки необходимо обязательно выполнить начальную синхронизацию.
Создание публикаций: Подготовив все необходимые серверы, можно приступать к созданию публикаций. Программа Enterprise Manager поддерживает несколько способов создания публикаций: использование мастеров репликации, использование команд меню и использование дерева консоли в программе Enterprise Manager. В каждой пользовательской базе данных издателя можно создать одну или несколько публикаций. Если базы данных назначения не существует, ее необходимо создать.
Использование мастеров: В процессе публикации можно пользоваться услугами следующих мастеров репликации:
 - Create Publication Wizard (мастер создания публикации).
 - Disable Publishing and Distribution Wizard (мастер отключения средств публикации и дистрибуции).
Определение публикации: Можно определить публикацию, содержащую одну или несколько статей. При создании публикации можно задать следующие ее свойства:
 - тип публикации - публикация моментальных снимков, публикация транзакций или публикация слиянием;
 - требования к моментальным снимкам, например, как планировать работу агента создания моментальных снимков и следует ли хранить моментальный снимок публикации на сервере-дистрибуторе;
 - таблицы или хранимые процедуры, которые предполагается публиковать;
 - следует ли разрешить анонимную подписку, обновление подписчиков или подписку по запросу;
 - публикации, имеющие общего агента. По умолчанию каждая публикация пользуется услугами своего собственного агента.
Замечание: Чтобы сохранить ссылочную целостность между публикуемыми таблицами, необходимо все таблицы, участвующие в каком-либо отношении, включить в одну публикацию. Это гарантирует одновременное применение транзакций ко всем таблицам и поддержание целостности.
Создание фильтров: Можно определить статью, представляющую подмножество данных некоторой таблицы; для этого используются фильтры и сценарии, определяющие, какие столбцы или строки должны включаться в статью. Можно определить вертикальное подмножество данных, горизонтальное или некую комбинацию этих видов:
 - Чтобы создать вертикальный фильтр, выберите только те столбцы, которые следует реплицировать.
Замечание: При вертикальной фильтрации данных реплицируемые столбцы должны содержать первичный ключ, за исключением случаев, когда выбрана репликация моментальных снимков.
 - Чтобы создать горизонтальный фильтр, используйте предложение WHERE для ограничения набора реплицируемых строк.
Ограничения на процесс публикации: На публикации сервера накладываются следующие ограничения:
 - Публикации не могут охватывать несколько баз данных; каждая публикация должна содержать статьи только из одной базы данных.
 - Нельзя реплицировать системные базы данных model, tempdb, msdb, master и distribution.
 - В таблице должен быть определен первичный ключ для идентификации строки и обеспечения сущностной целостности, за исключением случаев репликации моментальных снимков.
Ограниченная поддержка нерегистрируемых операций: Предусмотрена ограниченная поддержка операций, не регистрируемых в журнале транзакций, над данными типов text, ntext и image, как описано в следующей таблице.

Тип репликации	Обработка изменений
Репликация моментальных снимков	Изменения выявляются и реплицируются
Репликация транзакций	Агент чтения журнала транзакций не отслеживает изменений
Репликация слиянием	Системные триггеры не отслеживают изменений

Однозначная идентификация в репликации слиянием: Важным условием репликации слиянием является обеспечение однозначной идентификации строк. Необходимо использовать столбец типа данных uniqueidintifier со свойством ROWGUIDCOL. Когда сервер обнаружит столбец с таким свойством, он автоматически будет использовать этот столбец в качестве идентификатора строки для реплицируемой таблицы. Если сервер не обнаружит подобного столбца, он добавит в базовую таблицу столбец со свойством ROWGUIDCOL.
Начальная синхронизация: Для того чтобы новый подписчик мог получить публикацию, обычно бывает нужно, чтобы исходные таблицы и таблицы назначения содержали одну и ту же схему и одинаковые данные. С этой целью выполняется процесс синхронизации, называемый начальным моментальным снимком, и делает это издатель. По умолчанию все статьи публикации подвергаются начальной синхронизации как единое логическое целое. Это позволяет сохранить отношения целостности, унаследованные из таблиц, на основе которых созданы статьи. Агент создания моментальных снимков выполняет следующие действия:
 - Создает различные сценарии в зависимости от типа репликации. Эти сценарии содержат:
 - определения схемы;
 - файл вывода программы массового копирования с реплицируемыми данными;
 - определения индекса;
 - дополнительные файлы сценариев для репликации слиянием.
 - Сохраняет файлы в рабочей папке службы распределения.
 - Записывает сведения о состоянии заданий синхронизации в базу данных distribution.
Замечание: Процесс синхронизации использует служебную программу BCP либо в собственном формате сервера, либо в символьном формате. Символьный формат следует задавать в том случае, если на каких-либо серверах, входящих в сеть репликации, не установлен сервер.
Частота выполнения синхронизации: Для новых подписчиков (и только для них) можно составить расписание создания файлов начальной синхронизации. После проведения начальной синхронизации подписчик не нуждается в повторной синхронизации, если только не возникли какие-либо неполадки.
Замечание: Начальную синхронизацию можно отменить. Это делается, например, в случае, если вы проводите синхронизацию другими средствами или хотите, чтобы схема у издателя немного отличалась от схемы подписчика. Тем не менее, если начальная синхронизация отменена, ее необходимо выполнить вручную. Для этого может понадобиться, например, добавить столбцы timestamp и uniqueidentifier, в зависимости от используемого типа репликации.
Процесс подписки: После проведения начальной синхронизации можно выбрать характеристики подписки и указать, как часто следует обновлять данные у подписчика, используя данные издателя.
Подготовка принудительной подписки и подписки по запросу: Чтобы задать подписку, следует определить используемый ею метод репликации и указать вид подписки - принудительная или по запросу. Для каждого типа репликации можно использовать подписку любого из двух видов. Проводить подписку помогают два мастера: Push Subscription Wizard (мастер принудительной подписки) и Pull Subscription Wizard (мастер подписки по запросу).
Создание подписки: Для создания принудительной подписки или подписки по запросу необходимо сделать следующее:
 - создать или выбрать публикацию;
 - для каждого подписчика задать существующую базу данных подписки или создать новую;
 - выбрать один из методов синхронизации.
Принудительная подписка: Принудительная подписка определяется издателем. Принудительная подписка используется в среде с централизованным администрированием и устанавливается на сервере-издателе. Выбранный вид подписки определяет режим работы агентов, используемых для управления репликацией. В случае репликации моментальных снимков и репликации транзакций используется агент дистрибуции, работающий в распределителе, а в случае репликации слиянием - агент слияния, работающий на сервере-распределителе.
Подписка по запросу: Подписка по запросу определяется на каждом сервере-подписчике. В случае подписки по запросу подписчики сами определяют, когда следует подписываться, и таким образом берут на себя часть обязанностей администратора. Данный вид подписки также используется, если допускаются анонимные подписчики. В случае репликации моментальных снимков и репликации транзакций на сервере-подписчике работает агент распределения, а в случае репликации слиянием - агент слияния.
Использование параметра Immediate Updating Subscribers: Если при создании публикации выбрать параметр Immediate Updating Subscribers (Немедленное обновление подписчиков), то подписчик сможет обновлять копию своих локальных данных, при условии, что эти изменения можно немедленно передать издателю с помощью распределенной транзакции. Затем издатель рассылает изменения всем остальным подписчикам. Данный параметр не действует в случае репликации слиянием.
Обнаружение конфликтов: Если подписчикам разрешается обновлять содержимое публикации, повышается вероятность увеличения числа конфликтов обновления. В обновляемые таблицы необходимо включить
столбец timestamp. Когда пользователь попытается обновить строку в базе данных подписчика,
сервера с помощью столбца timestamp определит, зафиксированы ли издателем какие-либо изменения в этой строке. Использование данного параметра дает ряд преимуществ:
 - исключается вероятность конфликтов обновления;
 - поддерживается целостность транзакций;
 - расширяется автономия всех узлов.
Данный параметр рекомендуется использовать для сводных документов, таких как прейскуранты или списки заказчиков, частота обновления которых достаточно мала, а также для данных, подвергающихся логическому разбиению.
На использование данного параметра накладывается ряд ограничений. Ограничения на обновление типов данных Подписчику, запрещается:
 - обновлять значения типов timestamp, identity, text и image;
 - вставлять данные в таблицу, содержащую столбец типа timestamp или identity, за исключением случаев, когда у таблицы есть уникальный индекс.
Ограничения на обновление идентификации строки Подписчик не вправе обновлять уникальный индекс или первичный ключ, так как они используются для идентификации строки.
Замечание: Если вы отменили подписку и хотите вносить изменения в таблицу в узле подписчика, необходимо вручную удалить триггеры, установленные для реплицируемой таблицы базы данных подписчика.
Вопросы производительности: Чтобы добиться хорошей производительности при выполнении репликации, примите во внимание следующие рекомендации.
 - Используйте удаленного дистрибутора, чтобы снять часть нагрузки с издателя. Это целесообразно, если между дистрибутором и подписчиком действует медленный канал связи.
 - Старайтесь использовать подписки по запросу, чтобы уменьшить рабочую нагрузку на распределитель. Это имеет смысл делать, когда у вас много подписчиков.
 - Публикуйте только подмножества данных, чтобы подписчики получали лишь ту часть данных, которая им действительно нужна.
 - Используйте параметр Immediate Updating Subscribers (Немедленное обновление подписчиков). Этот параметр обеспечивает целостность транзакций. Однако его следует использовать только при надежном сетевом соединении.
 - Обеспечьте нужные показатели скорости работы и доступности сети, поскольку репликация может увеличивать нагрузку в сети.
Чтобы успешно планировать и настраивать процесс репликации, придерживайтесь следующих рекомендаций:
 - используйте одну и ту же учетную запись пользователя домена NT для всех служб сервера баз данных;
 - используйте первичные ключи в таблицах для поддержания сущностной целостности;
 - сведите к минимуму вероятность конфликтов обновления, ограничив возможности подписчика обновлением лишь определенного подмножества данных;
 - осуществляйте разбиение или фильтрацию данных, чтобы ограничить сетевой трафик и уменьшить размер базы данных.

Вопросы для повторения

ВОПРОС
Вы пытаетесь наладить репликацию между двумя серверами. Оба сервера на первый взгляд установлены корректно, однако репликация не действует. В чем могут быть неполадки? Как их исправить?
ОТВЕТ
Сначала убедитесь, что сетевое соединение между серверами работает нормально. Затем проверьте учетную запись, используемую сервером SQL Server для репликации (по умолчанию это учетная запись службы SQL Server Agent). Убедитесь, что данная учетная запись имеет доступ к другому серверу.
ВОПРОС
Когда устанавливается сервер дистрибуции, что следует учитывать при определении необходимого размера базы данных distribution?
ОТВЕТ
Число издателей, публикаций и подписчиков; объем данных, которые будут изменяться; частота изменений данных; используемый тип репликации; величина задержки; есть ли анонимные подписчики.
ВОПРОС
Ваша компания решила взять на вооружение средства репликации сервера SQL Server. На сервере публикации работает приложение, использующее значительное число ресурсов, и на нем невозможно организовать какие-либо работы по управлению репликацией. Предполагается, что подписчиков будет много. Некоторые из подписчиков время от времени будут переходить в автономный режим; всем подписчикам должно быть предоставлено разрешение обновления данных. Какая модель и какой метод репликации наиболее подойдут в данных условиях? Почему?
ОТВЕТ
Один издатель с удаленным дистрибутором (на отдельном компьютере), обслуживающий подписчиков с разрешением доступа только для чтения и подписчиков с параметром Immediate Updating Subscribers (Немедленное обновление подпичиков). Для подписчиков, пребывающих в автономном режиме, разрешите подписку с доступом только для чтения или репликацию слиянием. Для подключенных подписчиков установите параметр Immediate Updating Subscribers.