Вопросы, часто задаваемые администраторам репликации

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

Продолжительность времени блокировки зависит от используемого типа репликации:

• Для публикаций слиянием агент моментальных снимков не осуществляет никаких блокировок.

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

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

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

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

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

• Моментальный снимок применяется агентом распространителя или агентом слияния. Просмотреть состояние применения моментального снимка можно на странице Агент распространителя или Агент слияния монитора репликации. Дополнительные сведения см. в разделе Как просмотреть сведения и выполнить задачи для агентов, связанных с подпиской (монитор репликации).

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

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

• Если агент распространителя или агент слияния настроен на запуск по расписанию или по требованию, и при запуске агента моментальный снимок недоступен, то агент завершит работу, выдав сообщение о том, что моментальный снимок еще не доступен. Для применения моментального снимка агент необходимо запустить вновь после завершения работы агента моментальных снимков. Дополнительные сведения о запуске агентов см. в разделе Как синхронизировать принудительную подписку (среда SQL Server Management Studio), Как синхронизировать подписку по запросу (среда SQL Server Management Studio) и Основные понятия об исполняемых объектах агента репликации.

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

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

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

• Репликация слиянием добавляет к каждой таблице столбец rowguid, если только таблица уже не содержит столбец данных типа uniqueidentifier с установленным свойством ROWGUIDCOL (в этом случае используется этот столбец). Если таблица удалена из публикации, столбец rowguid удаляется; если существующий столбец был использован для слежения, столбец не удаляется.

• Если публикация транзакций поддерживает подписки, обновляемые посредством очередей, то репликация добавляет к каждой таблице столбец msrepl_tran_version. Если таблица удаляется из публикации, то столбец msrepl_tran_version не удаляется.

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

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

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

• По умолчанию ограничения с первичными ключами, индексы и проверочные ограничения реплицируются на подписчиках.

• Параметр NOT FOR REPLICATION по умолчанию задается для ограничений внешнего ключа и проверочных ограничений. Ограничения используются для пользовательских операций, но не для операций агентов. Дополнительные сведения см. в разделе Управление ограничениями, идентификаторами и триггерами с помощью параметра «NOT FOR REPLICATION».

Сведения об установке параметров схемы, которые контролируют, реплицируются ли ограничения, см. в разделах Как указать параметры схемы (среда SQL Server Management Studio) и Как задать параметры схемы (программирование репликации на языке Transact-SQL).

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

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

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

При наличии нескольких публикаций на распространителе можно настроить несколько баз данных распространителя для гарантии того, что данные, проходящие через каждую базу данных распространителя, идут из одной публикации. Для добавления базы данных распространителя нужно использовать диалоговое окно Свойства распространителя или sp_adddistributiondb (Transact-SQL). Дополнительные сведения о доступе к этому диалоговому окну см. в разделе Как просмотреть и изменить свойства распространителя (среда SQL Server Management Studio).

Эти сведения можно получить в среде Среда SQL Server Management Studio и через вызов некоторых хранимых процедур репликации. Дополнительные сведения см. в разделах Свойства репликации и Скрипт вывода сведений о распространителе и издателе.

Нет. При репликации данные, которых хранятся в базе данных или передаются по сети, не шифруются. Дополнительные сведения см. в подразделе «Шифрование» раздела Обзор безопасности (репликация).

Репликация данных через Интернет:

• Виртуальная частная сеть. Дополнительные сведения см. в разделе Публикация данных через Интернет с помощью виртуальных частных сетей.

• Параметр веб-синхронизации для репликации слиянием. Дополнительные сведения см. в разделе Веб-синхронизация для репликации слиянием.

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

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

Да, репликация работает по соединениям с малой полосой пропускания. Для соединений по TCP/IP-протоколу используется сжатие, предоставляемое протоколом, но дополнительное сжатие отсутствует. Для соединений веб-синхронизации по HTTPS-протоколу используется сжатие, предоставляемое протоколом, и дополнительное сжатие XML-файлов, используемых для репликации изменений. Дополнительные сведения о репликации по соединениям с малой полосой пропускания см. в разделе Медленная сеть — источник проблем.

Нет. Можно создать пакет DTS для передачи имен входа и паролей с издателя на одного или нескольких подписчиков. Дополнительные сведения см. в разделе Проектирование и разработка пакетов (службы Integration Services).

Начиная с Microsoft SQL Server 2005, термин схема имеет два значения.

• Определение объекта, например инструкция CREATE TABLE. По умолчанию репликация копирует определения всех реплицируемых объектов на подписчик.

• Пространство имен, в котором создается объект: <База данных>.<Схема>.<Объект>. Схемы определяются с использованием инструкции CREATE SCHEMA. Дополнительные сведения о схемах см. в разделе Схемы (компонент Database Engine).

• Репликации свойственно следующее поведение по умолчанию в мастере создания публикаций, касающееся схем и принадлежности объектов:

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

• Для статей в публикациях слиянием с уровнем совместимости менее 90: по умолчанию, владелец не указывается и устанавливается как dbo в процессе создания объекта на подписчике.

• Для статей в публикациях Oracle: по умолчанию, владелец устанавливается как dbo.

• Для статей в публикациях, в которых используются моментальные снимки в символьном режиме (которые используются для подписчиков, отличных от подписчиков SQL Server и подписчиков SQL Server Compact 3.5 с пакетом обновления 2 (SP2)): по умолчанию, владелец не указывается. Владельцем по умолчанию является владелец, связанный с учетной записью, используемой агентом распространителя или агентом слияния для подключения к подписчику.

Владельца объекта можно сменить в диалоговом окне Свойства статьи — <Article> и с помощью следующих хранимых процедур: sp_addarticle, sp_addmergearticle, sp_changearticle и sp_changemergearticle. Дополнительные сведения см. в разделах Как просмотреть и изменить свойства публикации и статьи (среда SQL Server Management Studio), Как определить статью (программирование репликации на языке Transact-SQL) и Как просмотреть и изменить свойства статьи (программирование репликации на языке Transact-SQL).

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

• Непосредственно выполнить инструкции GRANT в базе данных подписки.

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

• Хранимая процедура sp_addscriptexec используется для запуска инструкций.

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

• Повторное предоставление разрешений после повторной инициализации с использованием методик, описанных в предыдущем разделе.

• Задание того, что при повторной инициализации подписки объекты не должны удаляться. Перед повторной инициализацией либо:

  • Выполните хранимую процедуру sp_changearticle или sp_changemergearticle. Задайте значение «pre_creation_command» (хранимая процедура sp_changearticle) или значение «pre_creation_command» (хранимая процедура sp_changemergearticle) для параметра @property и значение «none», «delete» или «truncate» для параметра @value.

  • В диалоговом окне Свойства статьи — <статья> в разделе Целевой объект выберите значение Не изменять существующий объект, Удалить данные. Если у статьи есть фильтр строк, удалить только данные, соответствующие фильтру. либо Выполнить усечение всех данных в существующем объекте для параметра Действие, если имя уже используется. Дополнительные сведения о доступе к этому диалоговому окну см. в разделе Как просмотреть и изменить свойства публикации и статьи (среда SQL Server Management Studio).

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

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

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

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

Кроме этого, если в базе данных публикации или распространителя установлен параметр «sync with backup», то журнал транзакций не усекается до тех пор, пока не будет осуществлено резервное копирование всех транзакций. Если журнал транзакций становится слишком большим и этот параметр установлен, то необходимо рассмотреть сокращение интервалов резервного копирования журнала транзакций. Дополнительные сведения о резервном копировании и восстановлении баз данных, участвующих в репликации транзакций, см. в разделе Стратегии резервного копирования и восстановления из копии репликации моментальных снимков и репликации транзакций.

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

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

В предыдущих версиях SQL Server, предшествующих SQL Server 2005, перемещение или переименование файлов баз данных требовало отсоединения и повторного присоединения базы данных. Поскольку реплицируемую базу данных отсоединить нельзя, необходимо было вначале удалить репликацию из этих баз данных. Начиная с версии SQL Server 2005, можно перемещать или переименовывать файлы без отсоединения и повторного присоединения базы данных, не влияя при этом на репликацию. Дополнительные сведения о перемещении и переименовании файлов см. в разделе ALTER DATABASE (Transact-SQL).

Вначале удалите статью из публикации с помощью хранимых процедур sp_droparticle, sp_dropmergearticle или в диалоговом окне Свойства публикации — <Публикация>, а затем удалите ее из базы данных с помощью инструкции DROP <Object>. После добавления подписок невозможно удалить статьи из моментального снимка или публикаций транзакций; вначале следует удалить подписки. Дополнительные сведения см. в разделе Добавление и удаление статей в существующих публикациях.

SQL Server поддерживает разнообразные изменения схем для публикуемых объектов, включая добавление и удаление столбцов. Например, при выполнении инструкции ALTER TABLE … DROP COLUMN на издателе эта инструкция будет реплицирована на подписчиках, а затем выполнена для удаления столбца. Подписчики, использующие версии SQL Server, предшествующие SQL Server 2005, поддерживают добавление и удаление столбцов с помощью хранимых процедур sp_repladdcolumn и sp_repldropcolumn. Дополнительные сведения см. в разделе Внесение изменений схем в базы данных публикаций.

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

Для добавления таблицы (или другого объекта) к базе данных публикации или подписки не обязательно останавливать операции в ней. Добавьте таблицу в публикацию в диалоговом окне Свойства публикации — <Публикация> или с помощью хранимых процедур sp_addarticle и sp_addmergearticle. Дополнительные сведения см. в разделе Добавление и удаление статей в существующих публикациях.

Удалите таблицу из публикации с помощью хранимых процедур sp_droparticle, sp_dropmergearticle или в диалоговом окне Свойства публикации — <Публикация>. После добавления подписок невозможно удалить статьи из моментального снимка или публикаций транзакций; вначале следует удалить подписки. Дополнительные сведения см. в разделе Добавление и удаление статей в существующих публикациях.

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

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

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

Для репликации транзакций используйте хранимые процедуры или вкладку Нераспределенные команды в мониторе репликации. Дополнительные сведения см. в разделах Как просмотреть реплицированные команды и другую информацию в базе данных распространителя (программирование репликации на языке Transact-SQL) и Как просмотреть сведения и выполнить задачи для агентов, связанных с подпиской (монитор репликации).

Для репликации слиянием используйте хранимую процедуру sp_showpendingchanges. Дополнительные сведения см. в разделе sp_showpendingchanges (Transact-SQL).

Используйте хранимую процедуру sp_replmonitorsubscriptionpendingcmds или вкладку Нераспределенные команды в мониторе репликации. Сведения, выводимые хранимой процедурой или вкладкой:

• Количество команд в базе данных распространителя, которые не были доставлены выбранному подписчику. Команда состоит из одной инструкции языка обработки данных (DML) или одной инструкции языка определения данных (DDL) Transact-SQL.

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

Дополнительные сведения см. в разделах sp_replmonitorsubscriptionpendingcmds (Transact-SQL) и Как просмотреть сведения и выполнить задачи для агентов, связанных с подпиской (монитор репликации).

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

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