Возможности, предоставляемые внутренними средствами контроля репликаций в SQL Server 7.0
Настройку и проведение репликаций в SQL Server нельзя отнести к числу самых приятных занятий. Мне бы хотелось рассказать о некоторых стратегиях, способных облегчить проведение проверки достоверности данных подписчиков. Речь пойдет о том, как можно использовать встроенные в SQL Server 7.0 средства подтверждения правильности выполнения репликации для того, чтобы гарантировать синхронность данных издателя и подписчиков. Надеюсь, предлагаемая статья поможет читателям научиться обнаруживать проблемы до того, как они перерастут в серьезные неприятности для всего производственного окружения.
Хотя средства проверки достоверности данных репликаций являются одним из самых полезных новшеств SQL Server 7.0, мало кто из администраторов знает об их существовании. Более того, в книгах серии SQL Server Books Online (BOL) не объясняется толком, как эти средства работают. Весь процесс проверки репликации включает следующие шаги: сначала подсчитывается число строк и контрольная сумма таблицы издателя, затем аналогичные величины вычисляются для таблиц подписчиков, и на основании сравнения делается вывод о совпадении (синхронности) их данных. В процессе проверки считается контрольная сумма всей таблицы, но при этом игнорируются столбцы с текстами и образами. Для экономии времени можно обойтись только подсчетом числа строк, без вычисления контрольной суммы. Процесс проверки достоверности в SQL Server 7.0 протекает в скрытом режиме, т. е. он не прерывает транзакции издателя и не приостанавливает течение репликации. (Исключение составляет только проверка двунаправленной репликации методом транзакций, которая будет рассмотрена ниже.) Процесс проверки достоверности данных несколько различается для разных способов осуществления репликаций (методом транзакций и методом слияния), поэтому оба варианта будут рассматриваться отдельно.
Проверки для публикаций методом транзакций
Для публикации, выполняемой с помощью транзакций, процесс проверки начинается с вызова sp_publication_validation. Эту процедуру можно запускать вручную, а можно составить задание для автоматического запуска по расписанию. Для каждой статьи в публикации процедура sp_publication_validation вызывает процедуру sp_article_validation. Если вы намереваетесь проверить только одну статью в большой публикации, то лучше запустить для нее непосредственно вручную процедуру sp_article_validation, чем вызывать sp_publication_validation.
 |
| ЭКРАН 1. Просмотр хронологических записей агента распространения. |
Для просмотра результатов проверки достоверности понадобится запустить агентов распространения и программу чтения журнала, а также заглянуть в журнал истории агентов распространения. На Экране 1 показано сообщение о нарушении синхронизации в таком журнале. Заметим, что при запуске sp_publication_validation из окна запросов на экране появится сообщение о том, что для таблицы сгенерировано значение числа строк, равное 3. Не стоит обращать на него внимания. Это побочный продукт механизма проверки достоверности, который создается в процессе исполнения процедуры sp_table_validation у издателя. Это сообщение не показывает, успешно или неуспешно закончилась проверка достоверности у подписчика.
Вот как протекает процесс: процедура sp_article_validation вызывает процедуру sp_table_validation, которая вычисляет число строк и контрольную сумму опубликованной таблицы. Затем процедура sp_article_validation вставляет вызов sp_table_validation непосредственно в журнал транзакций издателя. Процесс передает значения числа строк и контрольной суммы как параметры в вызов sp_table_validation, записанный в журнал транзакций. Обычный механизм репликации методом транзакций отсылает вызов sp_table_validation подписчикам и проверяет данные подписчика в той точке, где они должны совпадать с данными издателя. На этом шаге процедура проверки исполняется в новом режиме.
Процедура sp_table_validation генерирует системное сообщение, в котором говорится об успешном или неуспешном завершении проверки данных у подписчика. Агент распространения читает системное сообщение, формируемое в ходе работы sp_table_validation. Если проверка прошла успешно, агент распространения формирует системное сообщение 20575, а если неуспешно, то системное сообщение 20574. Агент распространения записывает сообщение о положительном или отрицательном исходе проверки в хронологический журнал агента распространения. Замечу, что агент распространения продолжает отсылать транзакции репликации подписчику, даже если проверка показала, что синхронизация данных этого подписчика нарушена.
Проверки для публикаций методом слияния
 |
| ЭКРАН 2. Просмотр параметров команды проверки для агента слияния репликации. |
 |
| ЭКРАН 3. Просмотр хронологических записей агента слияния, в которых есть сообщение об успешном завершении проверки. |
В случае неудачного завершения проверки агент формирует системное сообщение 20574, а при совпадении результатов — сообщение 20575. Затем агент записывает информацию о положительных или отрицательных результатах проверки в хронологический журнал агента слияния, как показано на Экране 3. Агент слияния продолжит передавать изменения подписчику, даже если проверка показала, что подписчик не синхронизирован с издателем.
Автоматизация проверки и установка предупреждений
Механизмы, используемые для автоматизации процесса проверки достоверности данных репликации, выполняемой методом транзакций, отличаются от механизмов, применяемых для проверки данных репликации методом слияния. Кроме того, в случае публикации методом слияния используются различные механизмы в зависимости от того, как сконфигурирован агент слияния — для непрерывной работы или для запуска по расписанию. В случае публикации методом транзакций просто создается задание, которое запускает процедуру sp_publication_validation в соответствии с расписанием, например каждые сутки в час ночи. Если в публикации методом слияния агент слияния конфигурируется для постоянной работы, то параметр -ValidateInterval должен установить, с какой периодичностью (в минутах) процесс должен проводить проверки подписчика (по умолчанию — каждые 60 минут). К примеру, если требуется проводить проверку раз в сутки, то следует установить значение параметра -Validate равным 1 или 2, а параметра -ValidateInterval равным 1440 минутам.
При использовании публикации методом слияния, в которой агент слияния сконфигурирован для запуска по расписанию, предположим, каждые 5 минут, нужно создать задание, которое будет изменять значение параметра -Validate на 1 или 2 в те моменты, когда должна проводиться проверка. Например, можно составить задание, которое будет запускаться каждую полночь и будет применять процедуру sp_change_agent_ parameter для изменения значения параметра -Validate на 1 или 2. Помимо этого, необходимо создать еще одно задание, которое будет возвращать значение параметра -Validate в 0 по завершении проверки. Для второго задания можно поставить условие, что его будут запускать сообщения 20574 или 20575, которые генерируются после окончания выполнения проверки достоверности.
Для автоматизации отклика на проверку достоверности следует активизировать типовые предупреждения, выдаваемые в случае появления как сообщения 20574 (проверка не прошла), так и сообщения 20575 (проверка успешно завершилась). Сконфигурировать эти предупреждения можно с помощью монитора репликаций (Replication Monitor), входящего в состав Enterprise Manager. Предупреждения также могут выполнить некоторые действия, например известить оператора или записать сообщение в журнал.
Проверки для двунаправленной репликации методом транзакций
Проверка сценариев двунаправленной репликации методом транзакций, в которой участвуют подписчики с правом немедленного обновления, намного сложнее обычной репликации методом транзакций. Это обусловлено тем, что пользователи или процессы потенциально могут обновлять данные издателя и подписчиков одновременно. Для корректной проверки достоверности необходимо приостановить внесение изменений всеми пользователями непосредственно в данные издателя на время проведения проверки. Пользователи могут продолжать модифицировать данные издателя, но эти изменения будут переданы ему лишь по окончании проверки.
Время выполнения и блокировки
На время вычисления контрольной суммы и числа строк определенной таблицы процесс проверки репликации объявляет разделяемую блокировку этой таблицы. Но даже для очень большой таблицы вычисления не занимают много времени. Проводились измерения времени выполнения процедуры
| Размер таблицы | С предварительной загрузкой таблицы в кэш данных | Без предварительной загрузки таблицы в кэш данных | ||
| число строк | число строк и контрольная сумма | число строк | число строк и контрольная сумма | |
| 100 000 строк, 5 Мбайт | < 1 с | < 1 с | < 1 с. | < 1 с |
| 1 млн. строк, 50 Мбайт | 1 с | 4 с | 5 с | 5 с |
| 5 млн. строк, 250 Мбайт | 3 с | 22 с | 30 с | 30 с |
Ограничения проверки достоверности репликаций
При проведении проверок репликации следует иметь в виду следующие ограничения.
- Процесс проверки исключает столбцы с текстами и образами при подсчете контрольной суммы. Для таблиц, содержащих такие столбцы, можно запускать процедуру проверки, но она будет вычислять контрольную сумму только для столбцов, не содержащих ни текста, ни образов.
- Для корректного вычисления контрольной суммы необходима идентичность таблиц у издателя и у подписчиков: должны совпадать столбцы и порядок их следования, разрядность и типы данных, а также свойство NULL/NOT NULL.
- Нельзя запускать процедуру проверки статей, которые были отфильтрованы по вертикали, поскольку подписчик располагает только некоторым подмножеством столбцов, имеющихся у издателя. В результате значения контрольных сумм будут различаться.
- Использование чисел с плавающей запятой может вызвать расхождение контрольных сумм, если для передачи данных подписчику применяется программа копирования символьных массивов (bcp), поскольку незначительные различия неизбежны при переходе от формата представления числа с плавающей запятой к формату символьной строки. Чтобы исключить различия можно либо использовать собственную программу bcp, либо применять числовой или десятичный тип данных вместо формата с плавающей запятой. Символьный режим bcp используется при наличии разнородных подписчиков.
- Для того чтобы значения контрольных сумм были корректны, необходимо создавать таблицу у издателя с помощью единственного оператора CREATE TABLE. Это обусловлено тем, что внутренняя структура таблицы может слегка отличаться в зависимости от того, как была создана таблица — одним оператором CREATE TABLE или сначала оператором CREATE TABLE, а затем несколькими операторами ALTER TABLE. Алгоритм, который используется процедурами проверки достоверности репликаций для подсчета контрольных сумм, оказывается чувствительным к этим незначительным различиям. Поэтому он может давать разные значения для таблиц издателя и подписчика, даже если данные в них совпадают. Поскольку автоматический процесс синхронизации всегда задействует один оператор CREATE TABLE для создания таблицы у подписчика, то проще всего решить эту проблему путем использования одного оператора CREATE TABLE для создания таблицы у издателя. (Если вы хотите проверить идентичность внутренних структур таблиц издателя и подписчика, то можете сравнить значения смещения столбцов для каждой таблицы в системной таблице syscolumns.)
Успех репликаций
Наиболее серьезные проблемы с репликацией возникают в SQL Server тогда, когда нарушается синхронность данных издателя и подписчиков. Пользователи могут получить недостоверные данные, или может произойти сбой репликации из-за отсутствия синхронизации данных. Например, не исключена вероятность отказа агента распространителя, в результате чего появится ошибка ключа дубликата. Теперь, когда вы познакомились с возможностями проверки достоверности данных репликаций, предоставляемыми SQL Server 7.0, вы сами сможете обнаружить нарушения синхронизации данных до того, как они превратят в хаос всю систему.