SQL Server Merge Replication: синхронизация времени синхронизации, применение тысяч ненужных изменений схемы

Question

У нас есть публикация слияния, которая использует ряд методов репликации в ~ 80 статьях (фильтрация имени хоста на одной таблице, фильтрация соединения для нескольких других; таблицы, использующие двунаправленное направление синхронизации, другие с «только загрузкой, запрет изменений подписчиков», некоторые таблицы с использованием управления диапазоном идентификационных данных, другие - не нужны).

Мы используем push-репликацию для баз данных подписчиков, у которых уже есть все необходимые таблицы, поэтому мы используем «удалить данные» для «действия, если имя используется». Таблицы имеют одинаковые схемы как для баз данных подписчика, так и для публикации, но пустые до начала репликации.

Проблема заключается в том, что иногда инициализация подписки занимает ~ 3 минуты, но в других случаях она отключается через ~ 20 минут, используя идентичные шаблонные базы данных подписчиков и идентичные начальные наборы данных (~ 10 000 записей). И после инициализации, при синхронизации, вместо того, чтобы принимать ~ 5 секунд, он снова принимает ~ 20 минут. И, смотря на историю на мониторе репликации, в истории синхронизации говорится, что она вносит 1000 изменений схемы (даже когда изменений данных не было).

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

Замечание в случае, если это применимо: я использовал строку символов unicode 100 символов (созданную случайным образом из полного диапазона символов Юникода) в качестве имени хоста для разных подписчиков. Я подозревал, что это может вызвать проблему, но с тех пор я воспроизвел проблему, используя строчную буквенную строку на 50 символов.

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

Answer 1

Если это репликация слиянием. Вопросы: действительно ли ваши базы данных издателей и подписчиков одинаковы? У вас должны быть сетевые ресурсы вместо ftp в вашем случае для передачи, то есть моментальных снимков?

Answer 2

В случае, если кто попадается это, вот решение:

Когда мы предоставлен новый «абонент», мы сделали новый набор данных в таблицах для данного абонента (на основе значения по умолчанию). Однако мы создали ярлык при создании этой новой копии данных; мы отключили все ограничения, затем сделали наш select..insert, а затем снова включили ограничения. Это было связано с тем, что было много таблиц с большим количеством ограничений, и мы не хотели проходить через каждую таблицу справа (и, кроме того, мы знали, что собираемся добавить данные о хорошей целостности).

Проблема заключается в том, что все ограничения отключены, а затем снова включены, записывается репликацией слиянием как две изменения схемы. (Вместо «нет»). Поэтому каждый раз, когда мы добавляли подписчиков, мы создавали множество изменений схемы. И в следующий раз, когда какой-либо подписчик синхронизирован - он должен был отправить все эти бессмысленные ограничения вкл/выкл.

Из-за особенностей нашего ярлыка на самом деле было добавлено более двух изменений схемы, подобных этому для каждого нового абонента. Поэтому, если абонент не синхронизировал какое-то время, у него получится тысячи новых изменений схемы.

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

Решение: Удалите «ярлык» и просто скопируйте данные в правильном порядке, не касаясь ограничений. Никаких дополнительных проблем.