У нас есть топология репликации слиянием, включающая одного издателя, несколько публикаций и несколько подписок. Работает без проблем не менее 8 месяцев.
Несколько дней назад мне сообщили, что мои коды PO «без изменений» «меняются» со стандартного стиля «ZWWTP / PO-0092» на новый стиль «ZWWT»: символы от 5 до 8 в коде заказа. были изменены на другую строку: chr (0) & chr (1) & chr (0) & chr (1) на некоторых серверах
Я дошел до того, что оказалось, что один из моих процессов репликации / подписки генерировал такие фиктивные данные: коды PO на издателе и у этого конкретного подписчика больше не совпадали с недавно обновленными или добавленными записями. Коды для ПО, созданные на стороне подписчика, будут изменены при загрузке на издателя (оставаясь чистыми на стороне подписчика). Заказы на покупку, загруженные из издателя, будут распространяться с измененным кодом заказа на подписчике.
Затем я смог очистить / настроить данные на обоих серверах с помощью некоторых утилит сравнения таблиц + несколько операторов UPDATE, но теперь при каждом выполнении репликации между двумя серверами появляются одни и те же расхождения: мои чистые / идентичные данные на обоих серверы будут возвращены в неконвергентное состояние после успешной репликации: те же записи, те же значения!
Не думаю, что я оставил в сети много доступных ресурсов, касающихся конвергенции и репликации данных. Я не нашел ничего. Я планирую выбросить / перестроить существующую публикацию / подписку через 3 часа, но я все еще ищу рациональный ответ на мою проблему, прежде чем она превратится в психоаналитическую проблему:
Кто-нибудь имеет представление о том, что происходит?
PS: кстати, поскольку код PO не используется в качестве естественного ключа, эта проблема репликации не влияет на целостность базы данных. Еще один аргумент в пользу суррогатных ключей , которые всегда работают в отличие от естественных ключей , которые работают большую часть времени , но это обсуждалось где-то еще .. .
РЕДАКТИРОВАТЬ: ну, я сделал это, и он не работал! Я бросил и подписку, и публикацию, пересоздал публикацию, но потом не смог создать снимок. Сервер не смог управлять тем, что он называет «Запись выделения диапазона идентификаторов для издателя», который «не найден в системной таблице MSmerge_identity_range.
После просмотра я обнаружил статью , в которой говорится, что такая проблема может возникнуть, если «вы удалили первую публикацию, созданную в базе данных публикаций»
Как смешно! Это именно то, что я только что сделал!
К счастью, эта проблема должна быть решена с помощью накопительного пакета 5 SQLServer 2005, который мне все еще нужно загрузить и установить. Но теперь возникает вопрос: как пользователи SQLServer 2005 могли работать до выхода этого CP5?
EDIT2: накопительный пакет 5 не работает, и я все еще не могу создать снимок для моей новой репликации!