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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

С репликацией такой проблемы нет, но репликация далека от принципа «установил и забыл»: управление ею требует много времени, и оно не так надежно, как хотелось бы.Кроме того, вам, возможно, придется внести изменения в схему, чтобы использовать репликацию.Доставка журналов осуществляется более автоматически и стабильно, но за счет исключения пользователей во время восстановления.

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

Answer 3

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

Answer 4

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

Похоже, вы хотите реализовать сценарий, аналогичный тому, который мы сейчас реализуем сами.

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

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

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

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

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

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

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