Повышение производительности репликации слиянием
После рассмотрения советов по повышению общей производительности, описанных в разделе Увеличение общей производительности репликации, ознакомьтесь с этими дополнительными сведениями, относящимися к репликации слиянием.
Структура базы данных
Столбцы индекса, применяемые в фильтрах строк и фильтрах соединения.
При использовании фильтра строк для опубликованной статьи создайте индекс для каждого столбца, используемого в предложении WHERE фильтра. В отсутствие индекса MicrosoftSQL Server должен читать каждую строку таблицы, чтобы определить, следует ли включить строку в секцию. При наличии индекса SQL Server может быстро найти нужные строки. Производительность будет наилучшей, если репликация может полностью разрешить предложение WHERE фильтра, используя только лишь индекс.
Важно также индексирование всех столбцов, используемых в фильтре соединения. При каждом запуске агент слияния просматривает базовую таблицу, чтобы выяснить, какие строки в родительской таблице и какие строки в связанных таблицах включены в секцию. Благодаря созданию индекса для объединяемых столбцов, SQL Server не требуется считывать каждую строку таблицы при каждом запуске агента слияния.
Дополнительные сведения о фильтрации см. в разделе Фильтрация опубликованных данных для репликации слиянием.
Рассмотрим чрезмерную нормализацию таблиц, включающих данные с типом «большие объекты» (LOB).
При синхронизации агенту слияния может потребоваться считать и передать целую строку данных от издателя или подписчика. Если строка содержит столбцы, использующие большие объекты (LOB), то этот процесс может потребовать выделения дополнительной памяти, и негативно скажется на производительности, хотя эти столбцы могут еще даже не быть обновленными. Чтобы уменьшить вероятность такого влияния на производительность, рассмотрите возможность помещения LOB-столбцов в отдельную таблицу, используя отношение «один к одному» для остальных данных в строке. Не рекомендуется использовать типы данных text, ntext и image. При включении больших объектов (LOB) рекомендуется использовать типы данных varchar(max), nvarchar(max), varbinary(max) соответственно.
Разработка публикации
Используйте публикации с уровнем совместимости 90RTM (SQL Server 2005 и более поздние версии).
Укажите, что публикация должна поддерживать только SQL Server 2005 или более поздние версии, если только один подписчик (или более) не использует версию SQL Server. Это позволит публикации использовать преимущества новых возможностей и оптимизации производительности. Дополнительные сведения см. в подразделе «Уровни совместимости для публикаций слиянием» раздела Использование нескольких версий SQL Server в топологии репликации.
Используйте соответствующие параметры хранения публикации.
Срок хранения публикации, то есть максимальное время до обязательной синхронизации подписки, определяет, как долго сохраняются метаданные отслеживания. Большое значение может влиять на хранение и производительность. Дополнительные сведения о настройке публикации см. в разделе Окончание срока действия и отключение подписки.
При работе с таблицами, которые изменяются только на издателе, используйте статьи, доступные только для загрузки. Дополнительные сведения см. в разделе Оптимизация производительности репликации слиянием при работе со статьями, доступными только для загрузки.
Создание и использование фильтров
Ограничьте сложность предложений в фильтрах строк.
Ограничение сложности критериев фильтрации способствует повышению производительности, когда агент слияния оценивает изменения строк для отправки подписчикам. Избегайте использования вложенных запросов SELECT в предложениях фильтров строк слияния. Вместо этого рассмотрите возможность использования фильтров соединения, которые в целом более эффективны для секционирования данных в одной таблице на основе предложения фильтра строк из другой таблицы. Дополнительные сведения по фильтрации см. в разделе Фильтрация опубликованных данных для репликации слиянием.
Используйте предварительно вычисляемые секции с параметризованными фильтрами (применяются по умолчанию). Дополнительные сведения см. в разделе Оптимизация производительности параметризованного фильтра с помощью предварительно вычисляемых секций.
Предварительно вычисляемые секции накладывают ряд ограничений на поведение фильтра. Если для приложения невозможно соблюдение этих ограничений, установите для параметр keep_partition_changes значение True, что обеспечит выигрыш в производительности. Дополнительные сведения см. в разделе Параметризованные фильтры строк.
Используйте неперекрывающиеся секции, если данные фильтруются, но не являются общими для пользователей.
Репликация может оптимизировать производительность для данных, не разделяемых между секциями или подписками. Дополнительные сведения см. в разделе Параметризованные фильтры строк.
Не создавайте сложные иерархии фильтров соединения.
Фильтры соединения с пятью и более таблицами могут негативно повлиять на производительность во время процесса слияния. Если создаются фильтры соединения для пяти и более таблиц, рекомендуется рассмотреть другие решения.
Избегайте фильтрации таблиц, являющихся в основном поисковыми таблицами, небольшими таблицами и таблицами, не подлежащими изменению. Сделайте эти таблицы все вместе частью публикации. Рекомендуется использовать фильтры соединения только между теми таблицами, которые должны быть секционированы среди подписчиков. Дополнительные сведения см. в разделе Фильтры соединения.
Рассмотрите возможность денормализации структуры базы данных или использования таблицы сопоставлений, если в соединении присутствует большое число таблиц. Например, если менеджеру по продажам нужны данные только по его клиентам, но требуется шесть соединений, чтобы связать клиента с продавцом, рассмотрите возможность добавления в таблицу пользователей столбца, идентифицирующего продавца. Данные менеджера по продажам будут избыточны, но затраты на денормализацию таблиц отчасти могут быть компенсированы выигрышем в производительности при секционировании репликации.
Внимательно разрабатывайте приложения для того, чтобы улучшить производительность предварительно вычисляемых секций, когда пакеты содержат много изменяемых данных. Убедитесь в том, что изменения данных в фильтре соединения родительской таблицы выполняются перед соответствующими изменениями в дочерних таблицах.
Присвойте параметру join_unique_key значение 1, если это допустимо логически.
Установка этого параметра в значение 1 указывает, что связь между дочерней и родительской таблицами в фильтре соединения — «один к одному» или «один ко многим». Установите этот параметр в значение 1, только если на соединяющий столбец в дочерней таблице наложено ограничение, гарантирующее уникальность. Если параметр установлен в значение 1 неправильно, конвергенции данных может не произойти. Дополнительные сведения см. в разделе Фильтры соединения.
Избегайте выполнения пакетов со многими изменениями при использовании предварительно вычисляемых секций.
При выполнении агента слияния после запуска пакета, выполняющего большое количество изменений данных, этот агент пытается разделить большой пакет на более мелкие. Во время этого другие процессы агента слияния могут быть заблокированы. Рассмотрите возможность уменьшения количества изменений и запускайте агент слияния между обработкой пакетов. Если это невозможно, увеличьте значение параметра generation_leveling_threshold для этой публикации.
Вопросы использования подписок
Разнесите расписания синхронизации подписок.
Если с издателем синхронизируется большое число подписчиков, рассмотрите возможность разнесения расписаний так, чтобы агенты слияния запускались в разное время. Дополнительные сведения см. в следующих разделах:
SQL Server Management Studio: Как указать расписание синхронизации (среда SQL Server Management Studio)
Программирование репликации на языке Transact-SQL: Как определить расписания синхронизации (программирование репликации на языке Transact-SQL)
Параметры агента слияния
Дополнительные сведения об агенте слияния и его параметрах см. в разделе Агент слияния репликации.
Обновите все подписчики с подписками по запросу до версии SQL Server 2005 или более поздней.
При обновлении подписчика до SQL Server 2005 или более поздней версии обновляется агент слияния, используемый подписками на подписчике. Чтобы воспользоваться преимуществами множества новых возможностей и оптимизации производительности, необходим агент слияния SQL Server 2005 или более поздней версии.
Если синхронизация подписки выполняется по быстрому соединению, а изменения отправляются с издателя и подписчика, используйте для агента слияния параметр –ParallelUploadDownload.
В SQL Server 2005 появился новый параметр агента слияния: –ParallelUploadDownload. Установка этого параметра позволит агенту слияния одновременно обрабатывать изменения, передаваемые на издатель, и изменения, загружаемые на подписчик. Это полезно в средах с большими объемами данных и высокой пропускной способностью сети. Параметры агента могут задаваться в профилях агента или в командной строке. Дополнительные сведения см. в следующих разделах:
Попробуйте увеличить значение параметра -MakeGenerationInterval, особенно если при синхронизации чаще происходят передачи с подписчиков, нежели загрузки на подписчики.
При синхронизации строк данных с большим объемом данных, например со столбцами больших объектов, веб-синхронизация может потребовать дополнительной памяти и привести к снижению производительности. Это происходит, когда агент слияния создает XML-сообщение, в котором содержится слишком много строк и большой объем данных. Если агент слияния потребляет при веб-синхронизации слишком много ресурсов, следует уменьшить число строк, посылаемых в одном сообщении, одним из следующих способов.
Используйте для агента слияния профиль медленного канала связи. Дополнительные сведения см. в разделе Профили агента репликации.
Уменьшите значения параметров агента слияния -DownloadGenerationsPerBatch и -UploadGenerationsPerBatch до 10 или менее. По умолчанию они равны 50.
Вопросы использования моментальных снимков
Создайте столбец ROWGUIDCOL в больших таблицах до того, как будет создаваться исходный моментальный снимок.
Репликация слиянием требует, чтобы у всякой опубликованной таблицы был столбец ROWGUIDCOL. Если столбца ROWGUIDCOL нет в таблице до того, как агент моментальных снимков создаст файлы исходного моментального снимка, агент должен сначала добавить и заполнить столбец ROWGUIDCOL. Чтобы получить преимущество в производительности при создании моментальных снимков во время репликации слиянием, создайте столбец ROWGUIDCOL для каждой таблицы до выполнения публикации. У столбца может быть любое имя (rowguid используется агентом моментальных снимков по умолчанию), но должны быть следующие характеристики типа данных.
Тип данных UNIQUEIDENTIFIER.
Применяется по умолчанию для NEWSEQUENTIALID() или NEWID(). Рекомендуется использовать NEWSEQUENTIALID(), так как эта функция может обеспечить повышенную производительность при внесении и отслеживании изменений.
Установлено свойство ROWGUIDCOL.
Уникальный индекс столбца.
Выполните предварительное создание моментальных снимков и/или разрешите подписчикам запрашивать создание и применение моментального снимка при первоначальной синхронизации.
Используйте один или оба этих параметра, чтобы предоставить моментальные снимки публикациям, использующим параметризованные фильтры. Если не указать один из этих параметров, подписки будут инициализированы с помощью серии инструкций SELECT и INSERT, а не с использованием программы bcp. Этот процесс — гораздо более медленный. Дополнительные сведения см. в разделе Моментальные снимки для публикаций слиянием с параметризованными фильтрами.
Советы по обслуживанию и наблюдению
Выполняйте время от времени повторную индексацию системных таблиц репликации слиянием.
Как часть обслуживания репликации слиянием, проверяйте время от времени рост размера системных таблиц, связанных с репликацией слиянием: MSmerge_contents, MSmerge_genhistory и MSmerge_tombstone, MSmerge_current_partition_mappings и MSmerge_past_partition_mappings. Периодически проводите повторную индексацию этих таблиц. Дополнительные сведения см. в разделе Реорганизация и перестроение индексов.
Наблюдайте за производительностью синхронизации с помощью вкладки Журнал синхронизации монитора репликации.
Для репликации слиянием монитор репликации отображает подробную статистику на вкладке Журнал синхронизации для каждой статьи, обработанной в процессе синхронизации, включая время, затраченное на каждую стадию обработки (передача изменений, загрузка изменений и т. д.). С помощью монитора репликации можно обнаружить особые таблицы, вызывающие замедление, к тому же, в мониторе репликации удобно устранять проблемы, связанные с производительностью подписок на публикацию слиянием. Дополнительные сведения о просмотре подробной статистики см. в разделе Как просмотреть сведения и выполнить задачи для агентов, связанных с подпиской (монитор репликации).