Доброго времени суток.
Дано: база у "соседей". Каждый день они пересоздают нам базу только с "нашими" данными, делают бакап и шлют его по FTP. Мы у себя его разворачиваем и все довольны.
Проблема - канал узкий, база большая, хотелось бы ускорить, а по причине пересоздания дифф или лог неприменим.

Какие есть варианты синхроницазии?
Желательно чтобы "соседи" ничего не меняли на их стороне.
Предполагаю, что за день база не могла сильно поменятся.
Старый добрый бакап/рестрор вполне подходит для выходных.

Я пока думаю в сторону CHECKSUM_AGG(CHECKSUM(поля, которые нам нужны))
То бишь если для всей таблицы CHECKSUM_AGG (можно и count(*) до кучи) не отличается от нашего, то изменений в таблице не было. Если отличается дробим таблицу на части и проверяем каждую часть чтобы не тащить CHECKSUM для каждой строки.
Для таблиц с датой проще всего взять дату в качестве диапазона разбиения
select CHECKSUM_AGG(CHECKSUM), count(*) from table group by year(date_field)
select CHECKSUM_AGG(CHECKSUM), count(*) where year(date_field)='2018' from table group by month(date_field)
select CHECKSUM_AGG(CHECKSUM), count(*) where month(date_field)=07 from table group by day(date_field)

Для таблиц без даты (справочников), ну пусть будут первые буквы от значения не суть важно.

Вопрос: делал ли кто-нибудь что-нибудь подобное?
Видит ли кто нибудь подводные камни, скрытые грабли и т.п?

Alexander Usбэкап сжимаете? Разумеется
TaPaK так судя по всему из бекапа пересоздают и вырезают потом. Эти добрые люди делают
truncate database_for_them.dbo.mytable
insert into database_for_them.dbo.mytable
select * from ourdatabase.dbo.mytable where some_conditions=true

Либо вообще (не выяснял подробностей)
drop database database_for_them
create database database_for_them
select * into database_for_them.dbo.mytable
from ourdatabase.dbo.mytable where some_conditions=true

так что на timestamp/rowversion надежды нет.

alexeyvgСамое узкое место - пересылка неких данных, причём эта часть меняться не будет.
Непонятно тогда, в чём вопрос, менять то ничего нельзя.
Или я неправильно понял про допустимость изменений? Идеальное решение - на их стороне анализировать обе базы - вчерашнюю и нынешнюю, формировать дельту, накатывать на вчерашнюю и посылать ее по узкому каналу.
Но это означает дополнительную работу для них либо доступ нам к их базе.
Так что у нас есть только наша вчерашняя база на нашей стороне и наша сегодняшняя база на их стороне.
Раз в неделю допустимо делать бакап/рестор чтобы полностью синхронизировать базы, а в рабочие дни хотелось бы синхронизировать скриптом.

alexeyvgПроблема всего лишь в том, что у них не было вчерашней базы.
Вот я и посоветовал просто её оставлять. Хорошая идея, мне в голову не пришла.
Озадачу руководство, пусть забьют стрелу, начнут предъявы, разборки, поставят бутылку тамошнему админу составляют план действий.
Однако вернемся к первому вопросу из топика: что можно сделать из того что есть?
Кто нибудь уже строил подобный велосипед?
Если строил, то описывал ли свои злоключения?
Где могут быть грабли - типа CHECKSUM отстой, надо использовать BINARY_CHECKSUM или HASHBYTES и т.п.

TaPaK так а с чем вы сверять будете, если нет предыдущей копии? Особенно про дробим Предыдущая копия есть на нашей стороне канала.
Но канал узкий, база большая, а дельта маленькая, но непредсказуемая.

Идея была в том, чтобы разбить каждую таблицу на части достаточно большие, чтобы этих частей было немного и достаточно маленькие чтобы не реплицировать неизменные части.
На примере есть таблица с датой d_tran


запрос вернет нам всего несколько тысяч записей, сравним с таким же запросом по нашей вчерашней базе и сразу отсечем неизменные строки (с одинаковым hash)

Владислав КолосовОни репликацией занимаются вручнуюИменно. Но пока не занимаюсь, а прорабатываю варианты.

alexeyvgCHECKSUM будет ошибаться,Вот это меня и напрягает. Хотя может я просто на воду дую. Будь там int(64) было бы легче.
alexeyvg а HASHBYTES дольше считает, и даёт больше данныхУ HASHBYTES другая проблема, на вход CHECKSUM_AGG можно подать только int, то есть выбор только между CHECKSUM и BINARY_CHECKSUM

alexeyvgЕсли изменения размазаны, то смысла нет, т.к. оно у вас постоянно будет показывать, что в каждой части что-то поменялось.Вот именно эту часть и будем реплицировать вместо всей большой таблицы.
Владислав Колосов если у вас нет доступа к сформированным удалённым даннымДоступ по чтению туда есть.
Владислав Колосов или другая сторона не желает выполнять дифференциальные выгрузки, то вы не решите проблему. А другая сторона ничего менять не хочет по причинам от меня не зависящим.

alexeyvgНу да, каждую часть будете реплицировать ,то есть всю базу :-)Это вряд ли, но я понял вашу мысль.