Соблазнительно «вмешиваться» в нормальную репликацию и «снимать с охраны» удаление хранимых процедур на стороне абонента, но это не оставляет возможности восстановиться после сбоя репликации. Если репликация пытается восстановиться, может потребоваться повторная инициализация, и это приведет к удалению «устаревших» данных, которые агент репликации считает удаленными.
Альтернативой является использование обычной репликации и использование сценария, который генерирует триггеры вставки и обновления для всех таблиц в базе данных подписчиков, которые вставляют / обновляют эти данные в еще одну третью базу данных. Таким образом, третья БД будет собирать все данные, которые когда-либо существовали, вторая БД может повторно инициализировать свою подписку, если это необходимо (когда вы делаете, просто помните, что массовые вставки не вызывают триггер вставки и проверяют новые данные добавьте его в третью БД), и первая БД не должна выполнять дополнительную работу, как триггеры.