Репликация/клонирование данных с одного MS SQL Server на другой

Question

Я пытаюсь получить содержимое одной базы данных MSSQL ко второй базе данных MSSQL. Нет необходимости в управлении конфликтами, без обновления схемы. Это просто обычная копия и замена данных. Данные базы данных назначения будут перезаписаны, если кто-то там что-то изменил.

Очевидно, что есть много способов сделать это репликации

• SQL Server: хорошо отлажена, но с использованием старых протоколов. Кроме того, многие разработчики продолжают говорить мне, что дьявол находится в деталях, и репликация может не всегда работать должным образом, и это лучший выбор для администратора, но не для разработчика.
• MS Sync Framework: MSF считается прекрасной новой технологией. Да, это новый материал, который вы любите получать, потому что он звучит так новаторски. Существует общий подход к синхронизации, это звучит так: изучите одну технологию и как интегрировать источник данных, вам никогда не придется изучать, как развивать синхронизацию снова. Но, с другой стороны, вы можете прочитать, что основным сценарием использования является синхронизация баз данных MSSQL Compact с MSSQL.
• Службы интеграции SQL Server: Это звучит как аварийное плановое решение. Если брандмауэр не работает, у нас есть пакет, который может быть запущен снова и снова ... пока брандмауэр не упадет или аутентификация не будет исправлена.
• Brute Force копирует и заменяет файлы базы данных: Вероятно, это не лучший выбор.

Конечно, при просмотре веб-сайтов Microsoft я читал, что каждая технология (помимо грубой силы, конечно) считается надежным решением, которое может применяться во многих сценариях. Но это, конечно, не тот материал, который я хотел услышать.

Итак, что вы думаете об этом? Какую технологию вы предлагаете.

Спасибо!

Stefan

Answer 1

Самый простой механизм - отправка журнала. Первичный сервер может помещать резервные копии журнала на любой UNC-путь, а затем вы можете использовать любые инструменты синхронизации файлов, чтобы управлять получением журналов с одного сервера на другой. Абонент просто автоматически восстанавливает любые резервные копии журнала транзакций, которые он находит в своей локальной папке. Это автоматически обрабатывает не только данные, но и изменения схемы.

Абонент будет доступен только для чтения, но это именно то, что вы хотите - в противном случае, если кто-то может обновить записи на подписчике, вы окажетесь в мире обиды.

Answer 2

Я бы добавил два метода в ваш список.

• писать сценарии T-SQL для ВСТАВИТЬ ... SELECT данные непосредственно
• Создать полную резервную копию базы данных и восстановить его на новый сервер

Если это большая база данных, и вам «Не буду делать это слишком часто, тогда я бы выбрал вариант резервного копирования и восстановления. Он выполняет большую часть работы для вас и гарантирует копирование всех объектов.

Я не слышал никого, использующего Sync Framework, поэтому мне было бы интересно узнать, успешно ли он использовал его.