Резервное копирование базы данных SQL для отчетов

Question

Мне нужна помощь / предложения по резервному копированию двух больших баз данных на один сервер, предназначенный для отчетов. Ситуация:

У моей компании есть две базы данных для внутреннего сайта. Один для Великобритании и один для Европы. Оба зеркалированы для DR.

У меня есть сервер в Европе, который предназначен для Microsoft Reporting Services, где мы запускаем отчеты на основе данных, собранных в этих двух базах данных.

Мы не хотим указывать службы отчетов на действующие базы данных по соображениям производительности / безопасности, поэтому в настоящее время мы ежедневно выполняем резервное копирование обеих баз данных и восстанавливаем их на нашем сервере служб отчетов.

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

Наша цель состоит в том, чтобы обновлять данные не менее чем на 15 минут, было предложено взглянуть на Log Shipping, поэтому я хотел бы знать, есть ли у кого-нибудь опыт в настройке этого, и каковы плюсы и минусы и есть ли лучшая альтернатива?

Любая помощь будет признательна, Спасибо

Answer 1

Доставка журналов - отличное решение для этого. У нас есть статьи об этом в разделе доставки журналов SQLServerPedia , и у меня есть видеоурок, в котором рассказывается о различных вариантах. О доставке журналов следует помнить, что когда произойдет восстановление, ваши пользователи будут исключены из базы данных отчетов.

Репликация не имеет этой проблемы, но репликация далеко не такова, как "установи и забудь" - она ​​требует много времени и не так надежна, как хотелось бы. , Кроме того, вам может потребоваться внести изменения в схему, чтобы использовать репликацию. Доставка журналов более автоматическая и стабильная, но за счет удаления пользователей во время восстановления.

Вы можете минимизировать это, имея два графика доставки журналов - один для дневного времени в рабочее время и один для остальных. В рабочее время вы восстанавливаете данные только один раз в час (или меньше), а в остальное время вы делаете это каждые 15 минут.

Answer 2

Мы разработали похожую среду. Мы использовали зеркальное отображение для передачи данных на наш сервер отчетов и создали автоматическую процедуру для создания моментальных снимков базы данных каждые 15 минут. Эти снимки создаются в нашей среде всего от 1 до 2 секунд и дают нам копию базы данных только для чтения. Дайте мне знать, если вы хотите, чтобы я углубился в детали.

Примечание мы используем Enterprise на обоих серверах.

Answer 3

Я бы рекомендовал вам изучить использование репликации транзакций.

Звучит так, как будто вы пытаетесь реализовать сценарий, аналогичный тому, который мы сейчас реализуем сами.

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

Разгрузка данных отчетов - это распространенный сценарий репликации, который описан здесь в документации по Microsoft Replication.

http://msdn.microsoft.com/en-us/library/ms151784.aspx

Брент прав в том, что для репликации действительно необходим элемент конфигурации, наряду с соображениями безопасности, которые необходимо учитывать, однако, на мой взгляд, существует ряд ключевых преимуществ использования репликации, в том числе:

• Снижение задержки по сравнению с журналом доставка.
• Возможность публикации только Статьи (таблицы), которые необходимы для отчетности.
• Снижение требований к хранению.
• Меньше публикуемых данных означает меньше сетевой трафик.
• Доступ к вашей отчетности данные / база данных всегда.

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

Я надеюсь, что то, что я описал, понятно и имеет смысл, но, пожалуйста, не стесняйтесь обращаться ко мне, если у вас есть какие-либо вопросы.

Answer 4

Вы должны рассматривать репликацию как альтернативу резервным копиям.