MS-SQL Server 2005: несовместимые данные после репликации

Question

У нас есть топология репликации слияния, включая один издатель, несколько публикаций и несколько подписей. Он работает как минимум 8 месяцев без проблем.

Несколько дней назад мне сообщили, что мои коды PO были «изменены» без каких-либо причин, начиная со стандартного стиля «ZWWTP/PO-0092» и заканчивая новым стилем «ZWWT»: символы с 5 по 8 в ПО код был изменен на другой строки является CHR (0) & CHR (1) & CHR (0) & CHR (1) на некоторых серверах

я достиг той точки, когда оказалось, что один только из моих репликации/suscription процессов было генерируя такие фиктивные данные: коды PO на издателе, и этот конкретный подписчик больше не соответствовал недавно обновленным или добавленным записям. Коды для PO, созданных на стороне абонента, будут изменены при загрузке в издатель (оставаясь чистым на подписчике). PO, загруженные из издателя, будут распространяться с измененным кодом PO на подписчике.

После этого я смог очистить/отрегулировать данные на обоих серверах с помощью некоторых утилит сравнения таблиц + некоторых операторов UPDATE, но те же самые расхождения теперь появляются каждый раз, когда репликация выполняется между двумя серверами: мои чистые/идентичные данные на оба сервера будут возвращены в состояние без конвергенции после успешной репликации: одни и те же записи, одинаковые значения!

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

Кто-нибудь имеет представление о том, что происходит на?

PS: Кстати, поскольку код PO не используется как естественный ключ, эта проблема репликации не влияет на целостность базы данных. Еще один аргумент в пользу surrogated ключей , которые работают ВСЕГДА в оппозиции к естественным ключей , которые работают большую часть времени, но this has been discussed somewhere else ...

EDIT: хорошо, я сделал это, и он не работает! Я бросил как подписку, так и публикацию, воссоздал публикацию, но затем я не смог создать моментальный снимок. Сервер не смог управлять тем, что он называет «Идентификатор выделения диапазона идентификаторов для издателя», который «не найден в системной таблице MSmerge_identity_range.

После просмотра я нашел это article, говоря, что такая проблема может возникнуть когда «Вы уронили первую публикацию, которая была создана в базе данных публикации»

Как смешно это! Это именно то, что я только что сделал!

к счастью, эта проблема должна быть решено с SQLServer 2005 кумулятивного пакета 5, который мне еще нужно загрузить и установить. Но теперь встает вопрос: как пользователи SQLServer 2005 могли работать до выпуска этот CP5?

EDIT2: накопительный пакет 5 не работает, и я все еще не могу создать снимок для своей новой репликации!

Answer 1

Я думаю, что у вас есть правильный план;)