Репликация SQL Server 2005

Question

Окружающая среда: SQL Server 2005 с пакетом обновления 2 (9.0.3077) Транзакционные публикации (производство и бета-версия)

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

Чтобы сэкономить ресурсы и сократить время ожидания подписчиков, я установил для свойства репликации для этой хранимой процедуры значение «Выполнение хранимой процедуры» вместо значения по умолчанию «Только определение хранимой процедуры». Таким образом, когда хранимая процедура удаляет более 2 000 000 записей, они не передаются подписчикам. Вместо этого выполняется выполнение хранимой процедуры, и выполняется та же самая реплицированная хранимая процедура для подписчиков, и она удаляет те же 2 000 000+ строк.

У меня проблема со второй публикацией. Мне не нужно было такое поведение, поэтому я оставил свойству article в хранимой процедуре значение «Только определение хранимой процедуры» и ожидал, что репликация удалит строки у другого подписчика, но это не так. Таблица у подписчика просто продолжала набирать записи. Поэтому, чтобы исправить это, я установил свойство Article в «Execution ...» и назвал его хорошим. Вероятно, это лучшее решение, так как бета-версия подходит для производства, но все равно ощущается как бред, поскольку свойства публикации должны работать независимо друг от друга.

Вопрос: Почему свойство статьи «Выполнение хранимой процедуры» имеет приоритет и применяется к другой публикации, даже если в другой публикации оно установлено как «Только определение хранимой процедуры»?

Answer 1

Мы широко используем репликацию в нашей компании, поскольку у нас есть 38 складов в нескольких странах, все из которых реплицируются на наш основной сервер в Лондоне.

Во-первых, ваши фильтры репликации должны использовать представления, даже простые. Таким образом, если вам нужно настроить фильтр (см. Предложение WHERE), вам просто нужно изменить вид и все готово. В противном случае вам придется повторно опубликовать свои данные и подписать всех, что может быть настоящей болью.

Вы упомянули, что вы выполняете одно и то же удаление как для подписчика, так и для издателя, чтобы синхронизировать их. Это заставляет меня дрожать по спине. Вам гораздо лучше удалить их в одном месте и позволить серверу реплицировать подписчикам сделанные изменения. Начиная с SQL Server 2005, репликация сейчас очень быстрая и эффективная. SQL 2000 был и является довольно медленным для репликации. Если вы используете SQL 2005/2008, просто убедитесь, что ваш уровень совместимости (щелкните правой кнопкой мыши по db, properties, options) установлен на 90 (2005) или 100 (2008). Это переключает SQL Server на быстрые и эффективные методы репликации.

Другим способом является не удаление данных, а их сохранение и фильтрация с использованием условия where в публикации.

Answer 2

Прошло много времени с тех пор, как я активно администрировал репликацию, но я подозреваю, что ответ связан с архитектурой программы чтения журнала и тем, что вы делитесь статьей между публикациями. Насколько я понимаю, что программа чтения журнала будет перелистывать журнал и искать операции с реплицируемыми элементами. В зависимости от настроек товара отдельные изменения данных могут быть опубликованы в таблице в базе данных распространителя, либо будет опубликована запись вызова процедуры. В любом случае, это свойство статьи, а не публикации, членом которой является статья. Я предполагаю (но не проверял и не проверял), что вы можете создать несколько статей поверх одного и того же объекта базы данных, и одну из них можно реплицировать с @ type = 'logbased', а другую с @ type = 'proc exec'

Возьмем все это с большой долей соли: хотя сейчас я занимаюсь разработкой на SQL 2008, последний раз, когда я что-то делал с репликацией, был SQL 7.

pjjH