QL Server предоставляет многочисленные функции, с помощью которых администраторы и разработчики баз данных могут успешно внедрять, проектировать и обслуживать различные задачи. SQL Server Integration Services (SSIS) и репликация слиянием — два компонента, которые прекрасно дополняют друг друга, хотя специалисты не всегда задумываются о возможности их совместного использования. Службы SSIS появились в версии SQL Server 2005 в качестве замены для DTS. С помощью SSIS можно строить корпоративные решения для извлечения, преобразования и загрузки (ETL). Кроме того, это чрезвычайно мощная платформа автоматизации и обслуживания заданий. Администратор баз данных может внедрять различные пакеты SSIS, автоматизируя высокоуровневые превентивные задачи с целью оптимального выполнения экземпляров SQL Server в любой среде.

В SQL Server репликация слиянием превратилась в компонент синхронизации и распространения корпоративных данных. Как и в случае с другими компонентами SQL Server, установить его проще, чем обслуживать. Неправильное обслуживание системы репликации слиянием может привести к простоям, снижению производительности и необходимости вносить изменения в проект. Затраты на решение этих проблем всегда рассматриваются компаниями как убытки, не учтенные при составлении бюджета.

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

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

1. Распространение.

2. Публикация.

3. Подписка.

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

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

• spreplmonitorhelpmcrgesession;

• sysmergcarticles;

• sysmergcsubscriptions;

• MSreplication monitordata;

• MSmcrge_sessions;

• MSmcrge_genhistory;

• MSmcrgeagents.

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

«Implementing Replication Overview» (http://msdn. microsoft. com/cn-us/ library/msl 51215%28 v=sql. 105%29. aspx).

Предыдущая статьяИспользование Move-ltem
Следующая статьяОбзор возможностей SQL Server Compressed Backup