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

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

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

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

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

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

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

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

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

• Моментальный снимок применяется агентом распространителя или агентом слияния. Просмотреть состояние применения моментального снимка можно на странице Агент распространителя или Агент слияния монитора репликации. См. дополнительные сведения о просмотре сведений и выполнении задач с помощью монитора репликации.

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

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

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

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

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

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

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

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

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

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

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

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

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

Сведения об установке параметров схемы, которые управляют репликацией ограничений, см. в разделе Specify Schema Options.

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

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

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

При наличии нескольких публикаций на распространителе можно настроить несколько баз данных распространителя для гарантии того, что данные, проходящие через каждую базу данных распространителя, идут из одной публикации. Используйте диалоговое окно "Свойства распространителя" или sp_adddistributiondb (Transact-SQL) для добавления базы данных распространителя. Дополнительные сведения о доступе к этому диалоговому окну см. в статье View and Modify Distributor and Publisher Properties (Просмотр и изменение свойств издателя и распространителя).

Эта информация доступна через SQL Server Management Studio и ряд хранимых процедур репликации. Дополнительные сведения см. в статье Distributor and Publisher Information Script.

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

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

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

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

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

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

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

Нет, репликация работает только при использовании фактического имени сервера. Начиная с SQL Server Management Studio (SSMS) 18.0, репликацию можно настроить с помощью фактического имени сервера и номера порта.

Нет. Вы можете создать пакет SSIS для передачи имен входа и паролей от издателя любому числу подписчиков.

Начиная с Microsoft SQL Server 2005 (9.x), схема имеет два значения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • В диалоговом окне "Свойства статьи — статья>" в разделе "Целевой объект" <выберите значение "Сохранить существующий объект без изменений", "Удалить данные". Если в статье есть фильтр строк, удалите только данные, соответствующие фильтру. или усечь все данные в существующем объекте для параметра Action, если имя используется. Дополнительные сведения о доступе к этому диалоговому окну см. в статье Просмотр и изменение свойств публикации.

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

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

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

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

Кроме этого, если в базе данных публикации или распространителя установлен параметр «sync with backup», то журнал транзакций не усекается до тех пор, пока не будет осуществлено резервное копирование всех транзакций. Если журнал транзакций становится слишком большим и этот параметр установлен, то необходимо рассмотреть сокращение интервалов резервного копирования журнала транзакций. Дополнительные сведения об архивации и восстановлении баз данных, участвующих в репликации транзакций, см. в статье Strategies for Backing Up and Restoring Snapshot and Transactional Replication (Стратегии архивации и восстановления из копии репликации моментальных снимков и репликации транзакций).

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

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

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

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

SQL Server поддерживает широкий спектр изменений схемы в опубликованных объектах, включая добавление и удаление столбцов. Например, выполните ALTER TABLE … DROP COLUMN на издателе, и эта инструкция будет реплицирована на подписчиках, а затем выполнена для удаления столбца. Подписчики, работающие с версиями SQL Server до SQL Server 2005 (9.x), поддерживают добавление и удаление столбцов с помощью хранимых процедур 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) и просмотр сведений и выполнение задач с помощью монитора репликации.

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

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

Мы рекомендуем обратиться к стороннему поставщику, чтобы получить поддержку. Как правило, если проблема изолирована поставщиком, чтобы быть основной проблемой репликации, которая поставляется с SQL Server, то служба поддержки Майкрософт участвует в дальнейшем.

См. также

Вопросы и ответы об администрировании репликации
Best Practices for Replication Administration