Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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