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

Реализация репликации

При проведении репликации важно отслеживать все аспекты процесса, начиная с изменений, вносимых в публикацию, и кончая проверкой реплицированных изменений в базе данных подписчика. Удобнее всего проводить мониторинг репликации с помощью специально предназначенных для этого средств сервера, однако можно также пользоваться системными хранимыми процедурами и содержимым системных таблиц.
Программа SQL Server Replication Monitor является составной частью программы SQL Server Enterprise Manager и доступна только на сервере-дистрибуторе. Она предназначена для просмотра состояния агентов репликации и поиска причин возможных неполадок репликации.
В программе SQL Server Replication Monitor можно выполнять следующие действия:
- просматривать список издателей, публикаций и подписок;
- просматривать список агентов репликации, включенных в расписание;
- отображать текущие данные о работе агента репликации и на их основе получать сводку об обработанных транзакциях, операторах, операциях вставки и обновлениях;
- устанавливать профили и свойства агентов репликации;
- задавать и отслеживать оповещения, связанные с событиями репликации;
- просматривать истории агентов репликации.

В процессе управления репликацией необходимо рассмотреть ряд важных вопросов сопровождения, включая управление выделенным пространством и контроль стратегий создания резервных копий.
Управление пространством включает следующие задачи:
- Отслеживание размера базы данных distribution, направленное на то, чтобы всегда иметь достаточно места для хранения заданий репликации: определите срок хранения истории репликации и реплицируемых транзакций; установите свойства дистрибутора, контролирующие срок хранения.
- Контроль работы вспомогательных агентов.

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

Агент	Описание
Agent history clean up: distribution	Удаляет записи истории агентов репликации из базы данных distribution.
Distribution clean up: distribution	Удаляет реплицированные транзакции из базы данных distribution.
Expired subscription clean up	Выявляет и удаляет из публикуемых баз данных неактивные подписки.
Reinitialize subscriptions having data validation failures	Заново инициализирует все подписки, которые не действовали из-за нарушения достоверности данных.
Replication Agents Checkup	Выявляет агентов репликации, не производящих активной журнализации истории работы.

Убедитесь, что стратегии создания резервных копий баз данных и журналов транзакций действуют; это позволит поддерживать надлежащий размер журнала транзакций. Весьма важно иметь резервную копию базы данных distribution, так как если она будет потеряна, придется заново создавать все публикации и подписки. С планированием и реализацией стратегий создания резервных копий связаны следующие задачи.
- Отслеживайте все проблемы, связанные с базой данных distribution, которые могут отразиться на работе издателя. Например, если в базе данных distribution не остается свободного места, то из журнала транзакций издателя невозможно удалить транзакции, ожидающие публикации.
- Подготовьте планы регенерации данных и повторной синхронизации на случай сбоя.
- Подготовьте стратегию действий в случае сбоя издателя, дистрибутора или подписчика.

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

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

Для наблюдения за производительностью репликации можно использовать программы Enterprise Manager, Performance Monitor и системные хранимые процедуры. С их помощью можно получать сведения о доставленных и не доставленных транзакциях, а также о темпах доставки, в том числе о задержках.
Для получения данных о процессе репликации используются счетчики репликации, которые представляют в графическом виде те или иные характеристики процесса. С помощью программы Performance Monitor можно получать сведения по следующим счетчикам:
SQLServer:Replication Agents - Число агентов репликации, работающих в данный момент.
SQLServer:Replication Dist - Интервал времени в миллисекундах, прошедший от момента доставки транзакций в дистрибутор до их применения к базе данных подписчика. Также показывает число команд или транзакций, доставляемых подписчику в течение секунды.
SQLServer:Replication Logreader - Интервал времени в миллисекундах, прошедший от момента применения транзакций к базе данных издателя до момента их доставки дистрибутору. Также показывает число команд или транзакций, доставляемых дистрибутору в течение секунды.
SQLServer:Replication Marge - Число строк, объединяемых в секунду при слиянии от подписчика к издателю или от издателя к подписчику. Также показывает число конфликтов, возникающих в течение секунды в процессе слияния.
SQLServer:Replication Snapshot - Число команд или транзакций, доставляемых дистрибутору в течение секунды.

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

Тим информации	Хранимые процедуры
О серверах	sp_helpserver
	sp_helpremotelogin
О базах данных	sp_helpdb
	sp_helpdistributor
	sp_helppublication
	sp_helpsubscription
	sp_helpsubscriberinfo
Об операциях репликации	sp_replcmds
	sp_repltrans
	sp_replcounters

В таблицах истории содержатся данные обо всех агентах репликации. Истории репликации следует периодически просматривать, чтобы выявлять задачи, выполнившиеся неудачно, и определять причины сбоев. Тексты сообщений содержат обозначение проблемной области, например, неполадки подключений, недостаточный уровень разрешений доступа, ошибки переполнения журнала.
С помощью программы Replication Monitor можно просматривать данные о ходе репликации, относящиеся к выбранному агенту в некоторой публикации. Например, отображается сводка данных о сеансах агента, охватывающая промежуток времени от начала выполнения программы агента до прекращения.
История агента также включает несколько предварительно определенных запросов к истории сеансов, в частности, запросы следующих видов:
- по всем сеансам;
- по сеансам, проходившим в заданный интервал времени, например, за последние 24 часа, за последние два дня или за последнюю неделю;
- по сеансам с ошибками

В таблицах историй, содержащихся в базе данных distribution, отслеживается выполнение заданий репликации, относящихся ко всем агентам репликации. Речь идет о следующих таблицах историй (по одной для каждого агента): MSsnapshot_history; Mslogreader_history; Msdistribution_history; Msmerge_history.

К числу многих трудностей, которые могут возникать в процессе репликации, относятся проблемы подключений и безопасности. Прежде чем анализировать возникшие неполадки, необходимо определить, какие серверы ими затронуты, изучив для этого порядок выполнения операций агентами репликации. При устранении неполадок особое внимание следует обратить на доступность каждого из этих серверов и баз данных, участвующих в схеме репликации.
Для поиска причин неполадок, связанных с репликацией, можно использовать несколько журналов ошибок: SQL Server Error Log (журнал ошибок сервера), SQL Server Agent Error Log (журнал о шибок агента сервера) и SQL Server Event Viewer (программа просмотра журнала событий системы Windows NT). Кроме них, можно также использовать программу SQL Server Profiler.
Агенты репликации работают в контексте пользователя, определяемом службой SQLServerAgent. Если возникают неполадки со службой MSSQLServer или SQLServerAgent, проверьте, соблюдены ли следующие условия:
- Службы MSSQLServer и SQLServerAgent запущены.
- Для службы SQLServerAgent правильно настроены учетная запись и пароль. Обычно все участники процесса репликации пользуются одной и той же учетной записью службы SQLServerAgent.
- В средах с несколькими доменами заданы учетные записи служб, определяющие доверительные отношения между доменами.

По умолчанию средства репликации сервера используют учетную запись пользователя домена системы Windows NT, назначаемую службе SQL Server Agent. Если возникают неполадки подключения, проверьте работу подключения следующим образом:
- В случае принудительной подписки. Подключитесь к дистрибутору с той же учетной записью NT, которую использует на этом сервере служба SQLServerAgent. Откройте в дистрибуторе программу Query Analyzer, выберите режим Windows NT Authentication Mode (режим проверки подлинности средствами NT) и установите соединение с подписчиком.
- В случае подписки по запросу. Подключитесь к подписчику с той же учетной записью NT, которую использует на этом сервере служба SQL Server Agent. Откройте на сервере-подписчике программу Query Analyzer, выберите режим Windows NT Authentication Mode и установите соединение с дистрибутором.

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

Сервер предоставляет возможность реплицировать данные подписчикам других типов, используя интерфейс ODBC (открытый интерфейс подключения к базам данных) и OLE DB (связывание и внедрение объектов для баз данных). Кроме того. можно реплицировать данные из источников других типов. Здесь и далее под базами данных других типов понимаются источники данных, отличные от сервера Microsoft SQL Server 7.0.

Сервер поддерживает репликацию в базы данных других типов, действующих в среде системы Windows NT или Microsoft Windows 95/98. Кроме того, можно проводить репликацию на другие платформы, при условии, что имеется соответствующий драйвер ODBC или поставщик OLE DB и необходимое программное обеспечение средств связи.
К числу типов баз данных, поддерживаемых средствами репликации сервера, относятся следующие:
- базы данных Microsoft Access;
- базы данных СУБД Oracle;
- другие базы данных, удовлетворяющие требованиям, которые предъявляются к подписчику ODBC сервера MS SQL Server.

В комплект сервера входят драйверы ODBC для баз данных типов Oracle, Access и DRDA (Distributed Relational Database Architecture - распределенная архитектура реляционных баз данных; протокол фирмы IBM). Драйверы для баз данных ODBC других типов должны удовлетворять требованиям, предъявляемым средствами репликации сервера к подписчикам ODBC общего вида и должны:
- разрешать обновления;
- соответствовать стандарту ODBC Level 1;
- поддерживать транзакции;
- поддерживать операторы языка описания данных T-SQL;
- работать в 32-разрядном режиме и обеспечивать потокобезопасность (thread-safe).

На компакт-диске сервера имеются драйверы ODBC и поставщики OLE DB для ряда источников данных разных типов. Полный список драйверов ODBC и поставщиков OLE DB см. в справочной системе BOL: задайте поиск темы "Driver Support for Heterogeneous Data Sources" (Поддержка драйверов источников данных в гетерогенной среде).
Публиковать данные в базах данных подписчиков других типов можно с помощью мастеров репликации или программы Enterprise Manager. Между издателем и подписчиком другого типа следует установить принудительную подписку. Подписка по запросу не позволяет обслуживать подписчиков других типов. Перечисленные в следующей таблице ограничения относятся к репликации в серверы-подписчики любых типов, использующие интерфейс ODBC.

Вид ограничения	Пояснение
Типы данных	Типы данных сервера отображаются в наиболее близкие им типы в базе данных назначения
Моментальные снимки	Должны иметь символьный формат программы массового копирования (BCP).
Очистка публикации	Не поддерживается перед синхронизацией.
Пакетная обработка операторов	Не поддерживается для подписчиков ODBC.
Условия конфигурации интерфейса ODBC	Имя DSN (Data Source Name - имя источника данных) базы данных ODBC должно соответствовать соглашениям об именах сервера баз данных MS. Использование идентификатора в кавычках на сервере назначения определяется драйвером ODBC сервера.

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

Системная хранимая процедура	Описание
sp_enumdsn	Сообщает имена источников данных ODBC для сервера, использующего учетную запись пользователя NT.
sp_dsninfo	Возвращает сведения о базах данных ODBC и OLE DB из дистрибутора, связанного с текущим сервером.

В структуре репликации сервера допускается использование продуктов репликации других фирм в качестве издателей. Для совместимости со средой репликации сервера Microsoft SQL Server программа издателя должна быть написана на языке Microsoft Visual Basic. Microsoft С или Microsoft Visual C++ с использованием объектов SQL-DMO (Distributed Management Objects распределенные объекты управления).
После интеграции в среду сервера такой издатель получит доступ ко всем возможностям репликации сервера:
- Программируемые объекты репликации, используемые для администрирования и мониторинга репликации. Эти объекты являются объектами SQL-DMO.
- Интерфейс дистрибутора репликации для хранения реплицируемых транзакций.
- Агент дистрибуции для пересылки транзакций подписчикам.
- Программа Enterprise Manager, позволяющая осуществлять администрирование и мониторинг репликации в графическом режиме.

Прежде чем публиковать информацию в Интернете, необходимо провести некоторую подготовку. Следующие рекомендации относятся и к принудительной подписке, и к подписке по запросу:
- убедитесь, что издатель и дистрибутор находятся по одну сторону от брандмауэра;
- убедитесь, что издатель и дистрибутор связаны между собой прямым соединением, а не только через Интернет;
- включите поддержку протокола TCP/IP на каждом компьютере, на котором работают агент распределения и агент слияния, и на компьютерах, к которым эти агенты подключаются.

В случае подписки по запросу необходимо также обеспечить следующее:
- Убедитесь, что дистрибутор установлен на том же компьютере, что и сервер Microsoft Internet Information Server (IIS).
- В качестве домашнего каталога (home directory) протокола FTP на сервере IIS установите рабочую папку службы дистрибуции. По умолчанию это папка \\имя_компьютера\С$\MSSQL7\Repldata. Проверьте, доступна ли указанная рабочая папка подписчикам.
- Задайте правильный адрес FTP для агента распределения и агента слияния, установленных на сервере подписчика. Адрес можно установить с помощью служебной программы агента распределения репликации \MSSQL7\binn\distrib.exe, запускаемой из командной строки среды дистрибутора.

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

Дополнительные сведения по темам, указанным ниже, можно найти в справочной системе BOL. Проведение репликации слиянием для приложения в базу данных приложения Access - ключ поиска: replicating to Access. Составление сценария топологии репликации - ключ поиска: scripting a replication topology.

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

ВОПРОС
Как определить число транзакций, помеченных к репликации в журнале транзакций и ожидающих считывания агентом дистрибуции?
ОТВЕТ
Воспользуйтесь программой SQL Server Performance Monitor и посмотрите значения счетчиков репликации.
ВОПРОС Что следует проверить в первую очередь, если все ваши публикации перестали доставляться?
ОТВЕТ
Проверьте службу SQLServerAgent и убедитесь, что она работает и правильно настроена. Проверьте также базу данных distribution и журналы службы SQL Server Agent.
ВОПРОС
Вы закончили настройку репликации. В публикуемые данные внесены изменения, но эти изменения не реплицируются подписчику. Как определить, какой из агентов репликации виноват в этом?
ОТВЕТ
Просмотрите истории агентов и проверьте операции каждого агента, чтобы определить, успешно ли они выполнились.