Я делал это в прошлом с помощью Log Shipping.Единственное, что вам нужно сделать с исходной базой данных, чтобы включить это, - установить для модели восстановления значение «Полный», а затем настроить для нее расписание полных и резервных копий журнала транзакций.Более подробный план:
- Настройка исходной базы данных с моделью восстановления, для которой задано значение Полная.
- Создание «первой» полной резервной копии
- Создание целевой базы данных путем восстановленияполное резервное копирование, оставив его в режиме ожидания *
- Настройка расписания резервного копирования журнала транзакций.Частота полностью зависит от ваших обстоятельств, но в целом вы не хотите, чтобы файлы резервных копий t-log были слишком большими.
- Настройка доставки журналов между двумя базами данных
*Режим ожидания обеспечивает доступ к базе данных только для чтения.Обратите внимание, что вы не можете применить последующее восстановление к резервной базе данных, если к ней открыты какие-либо соединения.
Временные рамки - это сложная часть.Предположительно, вы хотите обновлять базу данных один раз в день, скажем, в полночь по Гринвичу (это «ваше стандартное время»), что означает, что: - в это время убедитесь, что нет открытых соединений с целевой базой данных (то есть уничтожьте любуюнайдите и убедитесь, что ваши пользователи знают, что вы будете это делать!) - Применить накопленные за тот день восстановления за тот период
Я делал это несколько лет назад, и я не думаю, что эти точные требования были поддержанывстроенными утилитами доставки журналов (или слишком сложными).Как бы то ни было, не так уж и сложно «свернуть свое»;просто отследите последний примененный t-log, напишите процедуру уничтожения соединения «Shoot Zem All», извлеките и примените все последующие, найденные в папке резервной копии.