Сопровождение тиражирования сведением в SQL Server 2000

Изо всех механизмов тиражирования сведение требует особого внимания администратора, поскольку степень свободы участников в этом типе тиражирования самая высокая. Специальная база данных Distribution в сведении фактически не участвует, а вся служебная информация хранится в дополнительных объектах основных баз данных на издателе и подписчике. В этой статье я хочу кратко описать возможности SQL Server 2000, которые оказались наиболее полезными для поддержки тиражирования сведением, и рассказать об особенностях перевода сопровождаемых систем на новую версию.

Статья основана на опыте сопровождения популярной системы www.netwizard.ru. Она адресована администраторам и, возможно, убедит их в целесообразности перехода на SQL Server 2000.

 

Служебные таблицы, процедуры и триггеры для поддержки сведения

В документации тиражирование сведением (слиянием) предлагается использовать в тех случаях, когда между издателем и подписчиком нет надежной постоянной связи. Хотя в версии 2000 появилась возможность применять очереди сообщений MSMQ, эта рекомендация остается актуальной. В интервалах между процедурами сведения издатель и подписчик имеют полную свободу. В результате сведения состояние данных всех участников становится одинаковым. Этой работой занимаются специальные процессы, называемые агентами сведения (Merge Agent). В зависимости от типа подписки агент Merge Agent может принадлежать либо подписчику, либо дистрибьютору. В SQL Server 2000 реализован больший параллелизм в работе агента сведения и, как следствие, обеспечено более эффективное взаимодействие между серверами.

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

Например, таблицы Sysmergepubluca-tions и Sysmergesubscriptions содержат по одной записи на каждую публикацию и подписку соответственно, а в таблице Sysmergearticles каждая запись соответствует статье. В таблицах Sysmergeschemachange и Systrans-chemas содержатся данные об изменении схемы на издателе. Основной можно считать таблицу MSmerge_contents. Именно ее в первую очередь использует агент сведения для определения изменений данных. Число записей в ней неуклонно растет в течение всего времени тиражирования. Три таблицы связаны с удалением данных: MSmerge_tombstone, MSmer-ge_delete_conflicts и MSmerge_errrorlineage. Они содержат информацию об удалении данных в тиражируемых таблицах, удалении данных в результате возникновения конфликтов и дополнительно об удалении данных на подписчике, которые еще не перенесены на сервер-издатель. Таблица MSmerge_genhistory содержит значения поколений (generations), о которых участнику тиражирования стало известно за период удержания (retention period). В течение периода удержания, по умолчанию составляющего 14 дней, подписчик и издатель обязаны синхронизироваться. В противном случае будет выполнена повторная инициализация подписки. В распоряжении администратора есть и справочные хранимые процедуры, выдающие информацию о тиражировании. Назначение процедур нетрудно понять по их именам: sp_helpmergepublication, sp_helpmergearticle, sp_helpmergearticlecolumn, sp_helpmergefilter , sp_helpmergesubscription, sp_helpmer-gepullsubscription, sp_helpmergealternatepublisher, sp_helpmergearticleconflicts, sp_helpmergeconflictrows, sp_helpmergedeleteconflictrows.

Для поддержки тиражирования на издателе и на подписчике создаются системные хранимые процедуры c префиксами sp_ins_, sp_upd_ и sp_sel_. Процедура с префиксом sel_ используется агентом сведения для выборки добавленных или измененных данных из таблиц, участвующих в тиражировании. Если данные добавляются или обновляются, служебные триггеры вызывают хранимые процедуры, а те уже вносят изменения в системные таблицы. Таким образом, каждая транзакция, вызванная пользователем, влечет за собой целую серию транзакций в системных таблицах. Это ведет к увеличению времени отклика, иногда в несколько раз, а также может вызвать проблемы с блокировками. Такова плата за тиражирование, и разработчикам и администраторам следует помнить о ней.

Процедуры с префиксом sp_cft_ служат для регистрации конфликтов. Для каждой таблицы, участвующей в тиражировании, создаются триггеры с префиксами ins_, upd_ и del_, соответствующие типу транзакции. Триггеры на издателе создаются во время подготовки снимка, а триггеры на подписчике – во время применения снимка.

 

Особенности сопровождения тиражирования

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

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

Дополнительная особенность связана с тем, что при длительном сопровождении заметно возрастает объем служебных таблиц, что не только увеличивает размер базы, но и замедляет сведение. Каким образом решение этих задач оптимизировано в SQL Server 2000?

 

Альтернативное расположение снимка

Для настройки тиражирования важно обеспечить быструю доставку снимка подписчику. В SQL Server 2000 администратор получил возможность управлять расположением снимка. Можно получить одновременно два снимка: в папке для снимков по умолчанию и в папке общего доступа в сети. Расположение снимка является свойством публикации, редактируемым с помощью Enterprise Manager. При доступе к снимку через ftp, если нет уверенности в разрешении имен DNS, лучше указать IP-адрес узла и путь внутри папки ftp Root. Вариант настройки приведен на Экране 1.

Экран 1. Настройка альтернативного расположения снимка.

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

 

Синхронизация с альтернативным партнером

При использовании SQL Server 2000 подписчик, участвующий в тиражировании сведением, может выполнить синхронизацию с альтернативным сервером. Альтернативный партнер может быть точной копией (клоном) первоначального издателя, глобальным подписчиком или публикующим подписчиком. Напомню, что глобальный подписчик имеет собственный ненулевой приоритет для разрешения конфликтов. Администратор в критических ситуациях может использовать этот механизм для синхронизации по требованию, если основной издатель недоступен. Запретить или разрешить использование альтернативных партнеров можно на лету, при активной подписке. Эти настройки относятся к свойствам публикации. Информация об альтернативных партнерах хранится в таблице MSmerge_altsyncpartners. Разумеется, администратор должен обеспечить выполнение требований к схеме и данным для альтернативного партнера.

 

Изменение схемы на издателе

При изменении схемы на издателе тиражирование сведением в SQL Server 2000 останавливать не нужно. Варианты изменения схемы могут быть различны, но все они выполняются через настройку свойств публикации. Удобно использовать для этого Enterprise Manager. Например, поле таблицы относится к публикуемым данным, и его нужно удалить. Это делается через интерфейс свойств публикации. Другой пример: поле добавляется в таблицу. Даже если оно не будет опубликовано, процедура выполняется через тот же интерфейс. При добавлении поля можно задать и его добавление к публикации. Третий пример: нужно изменить длину поля. Это самый сложный случай. Он требует предварительного сохранения значений поля. Сохранить значения поля нужно сразу после синхронизации. Потом поле удаляется и снова выполняется синхронизация. После чего поле отсутствует и на издателе, и на подписчике. Затем на издателе добавляется поле с новой длиной, например больше прежней, и заполняется сохраненными значениями. Синхронизация выполняется в третий раз. Поле в новом виде доступно и на издателе, и на подписчике. Хотя тиражирование в этом случае можно не останавливать, исчезновение и появление поля может неприятно удивить пользователей, поэтому подобные эксперименты проводить не стоит.

 

Расширение возможностей публикации

Для таблиц, участвующих в тиражировании сведением, наличие первичного ключа необязательно. Достаточно иметь в таблице поле типа uniqueidentifier с признаком ROWGUIDCOL. Во время создания публикации SQL Server автоматически построит по этому полю служебный индекс типа Unique, который будет существовать, пока существует публикация. SQL Server 2000 позволяет настроить вертикальную фильтрацию данных в тиражировании сведением, соответственно, уменьшить объем первоначального снимка и увеличить производительность. Фильтрация относится к свойствам публикации и может быть изменена в период сопровождения из Enterprise Manager или с помощью хранимой процедуры sp_mergearticlecolumn.

 

Новые средства разрешения конфликтов

Тиражирование сведением изначально предполагает возникновение конфликтов. SQL Server 2000 допускает интерактивное вмешательство пользователя в процесс разрешения конфликтов при синхронизации с помощью команды Synchronize группы Accessories. Встроенные механизмы разрешения конфликтов обеспечивают: разрешение в пользу определенного значения поля, разрешение в пользу минимального или максимального значения, разрешение в пользу первого или последнего значения, установку суммарного или среднего значения, а также добавление (дописывание) разных текстовых значений. Замена программы разрешения конфликтов возможна в период сопровождения и не требует повторной инициализации подписки. Для повышения уровня безопасности администратор может установить проверку цифровой подписи программ разрешения конфликтов, включенных в SQL Server 2000. Потенциальным источником конфликтов при сведении всегда были поля с признаком Identity. Создавая публикацию или редактируя позднее ее свойства, можно указать диапазоны генерируемых значений Identity для разных серверов. Если в публикации есть поля с этим свойством и на подписчиках добавляются записи, при автоматическом управлении диапазонами значения поля на каждом подписчике не повторяются, и возникновение конфликтов исключено. Пример настройки приведен на Экране 2.

Экран 2. Настройка автоматического назначения уникальных значений Identity для участников тиражирования.

 

Проверка тиражируемых данных

Во время сопровождения системы полезно периодически выполнять проверку тиражируемых данных. Эти проверки эффективны, хотя выполняются не так быстро и на время блокируют таблицы сначала на подписчике, а затем на издателе. Серверы, участвующие в тиражировании, во время проверок не должны быть сильно загружены. Проверка может выполняться разными способами, причем как на издателе, так и на подписчиках. Replication Monitor в Enterprise Manager позволяет выполнить проверку всех подписок к публикации. На Экране 3 показаны необходимые для этого случая настройки.

Экран 3. Варианты проверки подписки.

Хранимые процедуры sp_validatemergepullsubscription и sp_validatemergesubscription предоставляют более широкие возможности и позволяют проверить отдельную подписку. Установка в профиле агента сведения значения параметра -Validate, равным 1 или 2, также потребует проверки.

Во время проверки агент сведения подсчитывает и сравнивает количество записей и контрольные суммы для таблиц, участвующих в тиражировании, на подписчике и издателе. В случае неудачной проверки можно использовать имеющуюся в SQL Server 2000 заготовку оповещения Replication: Subscriber has failed data validation. Если проверка дала отрицательный результат, стоит выполнить повторную инициализацию подписки. При повторной инициализации подписки можно использовать возможность предварительной загрузки изменений данных с сервера-подписчика на сервер-издатель перед переносом нового снимка. На Экране 4 показано окно, появляющееся при выборе команды Reinitialize из контекстного меню подписки.

Экран 4. Параметр переноса изменений на сервер-издатель перед повторной инициализацией подписки.

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

EXEC sp_resyncmergesubscription London,
 Mydb, MyPublicattion, Moscow, Mydb, 2,
 'Oct 2 2001 12:00AM'

означает выбор всех поколений изменений на сервере-издателе London в базе Mydb для публикации MyPub-licattion, начиная с даты Oct 2 2001 12:00AM, и перенос их на сервер-подписчик Moscow в базу Mydb.

При выполнении

EXEC sp_resyncmergesubscription London, Mydb, 
MyPublicattion, Moscow, Mydb, 1

синхронизация начнется с момента последней успешно выполненной проверки.

 

Контроль размеров служебных таблиц

Пока существует тиражирование сведением, служебные таблицы MSmerge_contents и MSmerge_tombstone неуклонно растут. Периодическая очистка этих служебных таблиц повышает производительность сведения. Для очистки применяется специальная хранимая процедура sp_mergecleanupmetadata, которая появилась еще в Microsoft SQL Server 7.0 Service Pack 2 (SP2).

Она подчищает служебные таблицы MSmerge_contents и MSmerge_tombstone на издателе. Параметр reinitialize_subscriber этой процедуры по умолчанию установлен в TRUE, что означает повторную инициализацию подписки. Если используется установка FALSE, то администратор должен гарантировать, что подписчик и издатель синхронизировались. К сожалению, на время выполнения процедуры пользовательский доступ пользователей к базе запрещается. Администратор должен аккуратно:

1. выполнить синхронизацию;
2. закрыть доступ пользователей к базе на издателе и на подписчике;
3. выполнить синхронизацию с параметром -Validate;
4. выполнить sp_mergecleanupmetadata на издателе;
5. открыть доступ;
6. сделать резервную копию базы на издателе.

Опытные администраторы используют для очистки служебных таблиц и свои собственные процедуры. Если есть гарантия, что в течение заданного времени синхронизация будет успешно выполнена, то из таблиц MSmer-ge_contents и MSmerge_genhistory можно удалить все поколения (generations), накопленные за этот период времени. В Листинге 1 показан пример хранимой процедуры, выполняющей эту работу.

 

Перевод тиражирования сведением с SQL Server 7.0 на SQL Server 2000

Все сказанное до сих пор должно было убедить читателя в преимуществах перевода тиражирования на SQL Server 2000. Что ждет администраторов на этом пути? Привычная схема обновления остается в силе: сначала издатель и распространитель, затем подписчики. На некоторые моменты хочется обратить особое внимание. Например, на показанные на Экране 5 и используемые по умолчанию настройки обновления нескольких полей записи при сведении. По умолчанию SQL Server 2000 выполняет эти действия одним оператором Update, а SQL Server 7.0 – несколькими. Тексты триггеров и хранимых процедур отличаются. Если сохранить настройку по умолчанию, триггеры старого приложения, использующие конструкцию If Update, не смогут корректно работать. Проще снять галочку и не использовать настройку по умолчанию, чем переписывать триггеры.

Экран 5. Настройка обновления нескольких полей записи при сведении.

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

Экран 6. Пример назначения дополнительных сценариев при переносе снимка.

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