Варианты перемещения данных с различных серверов SQL на один сервер SQL на ночной основе

Question

У нас есть 3 сервера SQL (A, B и C).Сервер А связал серверные соединения с B и C. У нас есть несколько представлений на A, которые объединяют данные из B и C. Не удивительно, что эти представления ужасно медленны, и для их запроса требуются часы.Мы говорим о тысячах записей в нескольких таблицах в B и C.

Наша идея состоит в том, чтобы переместить данные из B и C в локальные таблицы на A, а затем указать представления на локальные таблицы.Мы предложили несколько вариантов передачи данных:

1. Каждую ночь реплицируйте данные из B и C в A, перемещая только дельты в таблицы на A (а не весь набор данных)
2. Каждую ночь восстанавливайте базы данных B и C в локальных базах данных на A и направляйте все представления на локальные базы данных
3. Напишите на A настраиваемую хранимую процедуру, чтобы каждыйночью, DROPs локальные таблицы и заполняет их данными из B и C, используя SELECT * INTO.Укажите все представления на A на локальные таблицы.
4. Подобно варианту 3, напишите пользовательскую хранимую процедуру для A, которая каждую ночь вычисляет deltas между локальными таблицами на A иэквивалентные таблицы на B и C. Укажите все представления на A на локальные таблицы.

Мы не хотели использовать вариант 1, потому что (согласно нашему старшему администратору базы данных) репликация изменила бы таблицы наB и C (например, добавление столбцов с именем msrepl_tran_version).Системы на B и C являются сторонними приложениями, которые мы не можем изменять.

Мы не хотели использовать вариант 2, потому что мы не хотим иметь КАЖДУЮ таблицу из B и C. Мы хотим толькоподмножество таблиц.Эти базы данных огромны, и их восстановление заняло бы слишком много места.

В настоящее время мы изучаем вариант 3. Однако он мне не подходит, потому что каждую ночь мы перемещаем большое количестводанные и 90 с чем-то процентов данных, которые мы передаем с B и C, такие же, как и прошлой ночью.

Старший администратор базы данных предложил вариант 4 в качестве единственного другого способа, кроме варианта 1, переместить дельты через каждую ночь.Тем не менее, это похоже на большую работу.Конечно, это общая проблема, и ее можно решить без написания пользовательского кода?

У кого-нибудь есть другие предложения?

Answer 1

Вы никогда не сможете правильно определить дельты.Не изобретайте колесо, у проблемы, которую вы описываете, есть простое прямое решение:

• имеют настроенные B и C транзакционные репликация
• на B и C добавьте интересующую таблицу (и) в качестве опубликованных статей.
• имеет подписку A на B и C и получает обновления почти в реальном времени

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