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

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

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

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

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

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

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

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


sql-server backup replication log-shipping sql-server-administration
person Phil    schedule 18.05.2009    source источник
comment
Это принадлежит serverfault.com   -  person Andomar    schedule 18.05.2009

Ответы (4)


arrow_upward
2
arrow_downward

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

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

person jgardner04    schedule 18.05.2009
comment
Насколько сложно это настроить и поддерживать? Мы также используем версию Enterprise на наших серверах. - person Phil; 19.05.2009
comment
Это не очень сложно для обоих. После настройки зеркального отображения я создал процедуру, которая сбрасывает снимок и воссоздает его каждые 15 минут. Все автоматизировано, поэтому я настроил и не возился с этим за пару месяцев. - person jgardner04; 22.05.2009
comment
Я настроил это как на наших зеркалах в Великобритании, так и на Европе, и оно работает очень хорошо, снимки создаются за считанные секунды, и мы можем получить доступ к данным в течение последних 15 минут, это действительно хорошее решение, спасибо Джонатон! - person Phil; 01.06.2009
comment
Это отличное решение для простых платформ баз данных. Однако стоит отметить, что в очень больших базах данных (VLDB) это может не обеспечить достаточную производительность для платформы создания отчетов. Репликация в таком случае имеет значение, потому что вы можете настроить реплицированную базу данных, т. е. добавить индексы для конкретных запросов на обслуживание отчетов, не внося тех же изменений на издателе (таким образом смягчая пагубные последствия для платформы OLTP). - person John Sansom; 04.06.2009
comment
Джон очень прав насчет VLDB. Спасибо, что добавили этот момент, Джон. - person jgardner04; 13.08.2010

arrow_upward
2
arrow_downward

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

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

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

person Brent Ozar    schedule 18.05.2009
comment
Спасибо, Брент, это действительно полезно, когда вы говорите об исключении пользователей, означает ли это, что они просто теряют доступ к базе данных на определенный период времени каждый час? или это на самом деле выкинет их из сеанса терминальных служб на нашем сервере отчетов? Извините, если это глупый вопрос, я новичок в SQL Server :) - person Phil; 18.05.2009
comment
Совсем не глупый вопрос! Они потеряют доступ к базе данных — база данных прекратит соединения и будет ждать, пока журнал транзакций будет восстановлен. - person Brent Ozar; 18.05.2009
comment
Приносим извинения за поздний ответ... Я настроил доставку журналов в тестовой базе данных между двумя SQL-серверами 2005 года, и она работает очень хорошо! Однако (и это моя вина, что я не упомянул об этом в своем первоначальном вопросе!) Мне не разрешено отправлять журналы с SQL 2005 на сервер 2008, на котором выполняются наши отчеты. Я не осознавал, что между ними могут возникнуть проблемы с совместимостью, пока не начал настраивать журналы транзакций. Я предполагал, что 2008 будет совместим. Знаете ли вы, есть ли способ обойти это? Спасибо - person Phil; 22.05.2009
comment
Вы можете настроить ручную доставку журналов между SQL 2005 и 2008, написав свои собственные сценарии T-SQL или используя для этого сторонние продукты. Как правило, это не очень хорошая идея, потому что вы не можете использовать коробку SQL 2008 в качестве метода аварийного переключения — после того, как вы переключитесь на 2008, вы не сможете вернуться. Короче говоря, да, вы можете это сделать, но нет, это не легко и не очень хорошая идея. - person Brent Ozar; 22.05.2009
comment
Спасибо, Брент. Я пытался сделать автоматическую отправку журналов с 2005 по 2008 год, проблема, с которой я столкнулся, заключалась в том, что когда файл был отправлен, его нужно было преобразовать в 2008 год, это означало, что база данных, получающая файлы на сервере 2008 года, всегда находилась в состоянии восстановления и не удалось получить доступ для целей отчетности. Единственный способ, которым я мог получить доступ, — это отключить задачу доставки журналов. - person Phil; 04.06.2009

arrow_upward
1
arrow_downward

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

person Johnno Nolan    schedule 18.05.2009
comment
Спасибо, Джон, я посмотрю на это! - person Phil; 18.05.2009

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

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

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

person John Sansom    schedule 18.05.2009
comment
Спасибо, Джон, это было очень ясно и очень полезно! У меня есть немало информации от вас, ребята, и я протестирую эти методы и дам вам знать, как у меня дела. - person Phil; 19.05.2009
comment
Пожалуйста. Не забудьте сообщить нам, как у вас дела или если вам нужна дополнительная помощь. - person John Sansom; 19.05.2009
comment
Привет, Джон, я изучил этот метод, и хотя он будет работать в большинстве сценариев (и это также предпочтительная рекомендация Microsoft), он пока не подходит для нас, только потому, что это будет означать изменение нашей схемы базы данных. Но это то, на что мы будем обращать внимание в будущем, когда будем улучшать нашу структуру для определенных целей. - person Phil; 22.05.2009
comment
Пожалуйста. Следует отметить, что только репликация слиянием потребует применения изменений схемы к вашей базе данных. Транзакционная репликация не вносит никаких изменений в схему. - person John Sansom; 22.05.2009