«Быстрое» инкрементное резервное копирование SQL Server?

Question

Я работаю над очень большой базой данных (250+ гигабайт) с более чем 225 миллионами записей. С базой данных трудно работать просто из-за ее размера. Эта база данных доступна только для чтения.

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

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

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

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

Есть предложения? Я также открыт для предложений/ссылок на страницы по производительности, так как я никогда не работал с базой данных такого размера.

Answer 1

Вы описываетедоставка бревен, но вы хотите использовать «дифференциальные» резервные копии вместо резервных копий журналов, что является проблемой вашего подхода. С доставкой журналов вы восстанавливаете базу данных один раз, а затем применяете резервные копии журналов по мере их создания на основном сайте, и вам никогда не придется переделывать первоначальное полное восстановление резервной копии. Просто продолжайте применять отправленный журнал каждые несколько часов, и у вас будет доступная только для чтения копия.

Answer 2

Возможно, эта третья сторона создаст что-то вродерепликацияпереносить изменения каждую ночь?

Answer 3

Если вам разрешен доступ к среде, в которой размещается производственная база данных, а также главная и доступная только для чтения база данных может быть одним и тем же экземпляром базы данных, работающим под управлением SQL2005 / SQL2008 Enterprise edition, вы можете использовать снимки базы данных. Это даст вам мгновенную копию базы данных, доступную только для чтения, на момент времени.

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

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

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

Если вы не используете Enterprise или вам нужны данные, близкие к реальным, то транзакционная репликация — это еще один вариант.

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

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

Answer 4

Ремус ответил на него первым, но вот как будет работать сценарий доставки журналов:

1. третья сторона отправляет вам полную резервную копию базы данных 1/1
2. Вы восстанавливаете базу данных в режиме norecovery в режиме ожидания, это устанавливает базу данных только для чтения (только для dbos)
3. Третья сторона отправляет вам резервную копию журнала транзакций (или несколько) на 1/2, и вы применяете их к базе данных, обновляя изменения. После применения резервной копии база данных снова будет в режиме ожидания, только для чтения
4. Повторяйте процесс ежедневно.