У нас есть новая система, работающая на 64-разрядной версии SQL Server 2008 r2. Существует основная база данных оперативной обработки транзакций (OLTP), которая принимает большой объем обновлений из нескольких тысяч систем точек продаж в магазинах по всей стране. Чтобы защитить эту жизненно важную функцию, я решил внедрить специальный сервер базы данных отчетов, с которого несколько пользователей будут запускать довольно сложные отчеты.
Я понимаю, что было несколько вариантов, но я решил использовать репликацию транзакций в качестве механизма для копирования данных из базы данных OLTP в новую базу данных отчетов - односторонняя репликация.
Решение хорошо себя зарекомендовало. Теперь меня спрашивают, какие изменения необходимо внести в политику резервного копирования, чтобы охватить архитектурные изменения. Я читал такие страницы, как MSDN: стратегии резервного копирования и восстановления моментальных снимков и репликации транзакций но я думаю, что это перебор для моего решения. Фактически, я сейчас думаю, что нам просто нужно продолжать делать резервные копии данных и журналов OLTP. Если база данных отчетов или какая-либо из баз данных репликации системы (например, распределения) выйдет из строя, тогда это не проблема - мы можем очистить все, а затем заново создать репликацию. Я понимаю, что создание полного моментального снимка OLTP потребует много времени (около 5 часов), но я был бы более расслаблен, пытаясь восстановить резервные копии различных файлов данных и журналов в правильной последовательности.
Я считаю, что сложные стратегии, изложенные в статье MSDN, были бы только способом пойти для более сложного решения репликации, чем у меня, например, если бы было несколько подписчиков с 2-сторонней репликацией.
Вы бы согласились? Буду признателен за любой совет.
Большое спасибо,
Роб.,
Я предполагаю, что у вас уже есть хорошие стратегии резервного копирования для вашей базы данных OLTP и базы данных отчетов, которые успешно работают в производственной среде. Я действительно не вижу, чтобы у вас возникли какие-либо дополнительные проблемы по поводу внесения изменений в эти пост-репликации.
Вы можете просто сгенерировать сценарии настройки репликации с помощью мастера SSMS. Это позволит вам настроить и настроить параметры репликации в любых будущих средах разработки / тестирования и предоставить резервную копию вашей текущей конфигурации.
Репликация, как известно, может съесть ваш LOG-диск, если по какой-то причине репликация останавливается ... но при условии, что вы вручную или автоматически отслеживаете дисковое пространство и состояние репликации, у вас не должно быть никаких проблем.
Удачи - но, на мой взгляд, резервные копии, необходимые для базовой репликации транзакций, не требуют каких-либо дополнительных стратегий.
В нашей среде у меня такая же установка, как та, которую вы предлагаете. Я согласен с тем, что процедура восстановления баз данных для обеспечения согласованности репликации немного обременительна, и я также предпочитаю воссоздать репликацию, если есть серьезная проблема, но я все равно создаю резервную копию базы данных отчетов.
В течение времени, необходимого для создания и передачи полного снимка (в нашем случае 8 часов), я могу восстановить статическую копию базы данных отчета с другим именем за 30 минут и направить приложение отчета на эту базу данных, чтобы избежать слишком длительного простоя. для моих пользователей отчетов, таким образом пользователи могут выполнять свои отчеты по данным со вчерашнего дня до тех пор, пока реплицируемая база данных не будет запущена и работает.