Поделиться через

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

  • Статья

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

Настройка репликации

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

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

Заблокированы ли таблицы во время создания моментального снимка?

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

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

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

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

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

Когда доступна подписка? Когда можно использовать базу данных подписки?

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

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

  • Моментальный снимок применяется агентом распространителя или агентом слияния. Просмотреть состояние применения моментального снимка можно на странице Агент распространителя или Агент слияния монитора репликации.

Что происходит, если выполнение агента моментальных снимков не завершено в момент запуска агента распространителя или агента слияния?

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

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

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

Необходимо ли создавать скрипты конфигурации репликации?

Да. Создание сценариев конфигурации репликации является ключевой частью любого плана восстановления в аварийных ситуациях для топологии репликации. Дополнительные сведения о создании сценариев см. в разделе 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.

Шифруются ли данные при репликации?

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

Как реплицировать данные через Интернет?

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

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

Возобновляется ли репликация при разрыве соединения?

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

Работает ли репликация по соединениям с малой полосой пропускания? Используется ли сжатие?

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

Имена входа и принадлежность объектов

Осуществляется ли репликация имен входа и паролей?

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

Что такое схемы и как они реплицируются?

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

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

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

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

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

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

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

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

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

Как можно настроить предоставление прав в базе данных подписки для соответствия предоставлению прав в базе данных публикации?

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

Что происходит с разрешениями, предоставленными в базе данных подписки при повторной инициализации подписки?

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

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

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

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

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

Обслуживание базы данных

Почему нельзя запускать операцию TRUNCATE TABLE на публикуемой таблице?

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

Каков эффект выполнения команды массовой вставки в реплицированной базе данных?

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

Есть ли факторы, которые необходимо принимать во внимание в отношении репликации при резервном копировании и восстановлении?

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

Влияет ли репликация на размер журнала транзакций?

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

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

Как воссоздать индексы или таблицы в реплицируемых базах данных?

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

Как добавить или изменить индексы в базах данных публикации или подписки?

Индексы можно добавлять на издателе или подписчиках без особых предосторожностей в отношении репликации (не следует забывать, что индексы влияют на производительность). 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) и Просмотр сведений и выполнение задач с помощью монитора репликации.

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

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

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

Работает ли репликация совместно с кластеризацией?

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

См. также:

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