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

Среда: SQL Server 2005 SP2 (9.0.3077) Транзакционные публикации (рабочая и бета-версия)

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

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

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

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


database sql-server replication sql-server-2005
person DBAndrew    schedule 24.04.2009    source источник
comment
Я не хочу играть здесь в Stackoverlfow, однако этот вопрос является довольно сложным запросом репликации SQL Server. Я бы посоветовал опубликовать его на форуме Microsoft SQL Server Replication Forum, а затем обновить этот пост, добавив в него результаты.   -  person John Sansom    schedule 25.04.2009
comment
Хотя я сейчас тоже работаю над некоторыми репликациями, я согласен с Джоном. Это довольно сложный вопрос. Удачи. :) Возможно, придется подождать, пока кто-нибудь сделает querytimeout.com   -  person Chad Grant    schedule 25.04.2009
comment
Согласен, Хиллари Коттер - известный эксперт по репликации и следит за форумом репликации сервера sql в социальных сетях. .msdn.microsoft.com / Forums / en-US / sqlreplication.   -  person Nick Kavadias    schedule 26.04.2009
comment
Попробуйте ServerFault.com. Теперь любой желающий может получить к нему доступ с паролем alt.sysadmin.recovery.   -  person Patrick McElhaney    schedule 18.05.2009
comment
Я принимаю это как работающее по назначению и считаю это недокументированной функцией Microsoft SQL SErver.   -  person DBAndrew    schedule 16.06.2009

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

person Simon Hughes    schedule 05.06.2009

arrow_upward
0
arrow_downward

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

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

pjjH

person Paul Harrington    schedule 28.05.2009