Вопросы резервного копирования и оптимизации базы 400+гб.

http://www.sql.ru/forum/actualthread.aspx?tid=855324 - Эта проблема была с тестовым сервером, её решил, всем спасибо.



Следующий вопрос, есть база объёмом 400+гб. Резервное копирование никогда не делалось, режим восстановления – симпле. Думаю, что это никогда не делалось из-за того, что на внешнем стородже(подключен по FC 8гб/с) было мало свободного места(сейчас меньше 100мб свободно). В свете того, что в эти выходные я планирую добавить новые жёсткие диски в сторедж, и увеличить свободный объём на 150ГБ.
Одбц чек дб возвращает порядка 7000 ошибок по базе, исправления не делали.
Мейнтаненс палана тоже нету, индексы наверно никогда не пересчитывали.
Основная база, САЙЗ – 385ГБ.
Спейс авейлобл – 100ГБ.

Предполагаю сделать следующие:
1. Делаю копию базы(физическое копирование файлов)
2. Добавляю новые ХДД.
3. Делаю одбц чек дб с репейр_олоу_дата_лосс
4. Делаю шринк дата бейз.
5. После этого делаю ещё один полный бэкап(уже средствами ентерпрайз менеджер)
6. Включаю режим восстановления Фул.
7. Назначаю резервное копирование транскт_лога на кажду ночь – ну тут буду ещё смотреть смотря от того как он будет расти, от объёма.
8. Планирую на раз в неделю мейнтененс план.


Ещё вопрос, в соседней теме проскочило, что это не очень хорошо, если темповая база находится на одном диске/папке с остальными базами. На сколько я понимаю, это из-за того, что возможны варианты когда идёт выборка/упдейт по основной базе, и сразу дублирование этой инфы в темп_бд что приводит к высокой утилизации ХДД. На сколько это актуально при использовании стореджей внешних? Я так понимаю, что даже если я разнесу темповую базу на отдельный лун, то всё равно упрусь в потолок интерфейса FC. Или нет? Вариант хранить базу на локальных дисках, не очень хорош тем, что сиквел крутится на отказоустойчивом кластере. И базы должны быть доступны с обоих серверов на случай падения оного из них.



Может кто-то посоветовать что-то? Может я что-то не делаю/собираюсь делать?

Заранее спасибо!

пункты 4 и 5 лишнии, архивировать стоит уже в режиме full и не лог, а данные и лог.
shrink можно сделать один раз, если много пустого места.

Возможно я тогда что-то недопонимаю?
В моём понимаю, один из смыслов режима ФУЛЛ, в том, что сделав единожды полный бек-ап, мы в дальнейшем можем делать уже только бек трансакшен лога.
И в случае проблем, восстанавливать по ФУЛЛ бекап + трансакшен логии по нарастанию. Я не прав?
Вопрос в том, что сделать 400ГБ бекап – физически сложно, т.к. единственное время когда с базой не работают это воскресенье с 2 до 10 вечера. В остальное время её активно пользуют, а копирование по сети 400гб занимает 5-6часов. По этому и хотелось делать Один раз фулл, в дальнейшем только трансакт-логи. Естественно, что фул бекап тоже будет делаться, но не каждый день. А один-два раза в месяц.

me2k

Возможно я тогда что-то недопонимаю? В моём понимаю, один из смыслов режима ФУЛЛ, в том, что сделав единожды полный бек-ап, мы в дальнейшем можем делать уже только бек трансакшен лога. И в случае проблем, восстанавливать по ФУЛЛ бекап + трансакшен логии по нарастанию. Я не прав? Вопрос в том, что сделать 400ГБ бекап – физически сложно, т.к. единственное время когда с базой не работают это воскресенье с 2 до 10 вечера. В остальное время её активно пользуют, а копирование по сети 400гб занимает 5-6часов. По этому и хотелось делать Один раз фулл, в дальнейшем только трансакт-логи. Естественно, что фул бекап тоже будет делаться, но не каждый день. А один-два раза в месяц.

Ну вы попробуйте как-нибудь восстановить логи хотя бы за неделю, и сразу все станет ясно. xD

Я с сиквелом работаю очень не давно )
Если можно подробнее, с какими проблемами я столкнусь? Если верить книжкам, то там всё бело и пушистое )
Это не так?

Как ещё по вашему можно организовать копирование таких объёмов?

версия сервера?

2000 СП4

me2k
Я с сиквелом работаю очень не давно ) Если можно подробнее, с какими проблемами я столкнусь? Если верить книжкам, то там всё бело и пушистое ) Это не так? Как ещё по вашему можно организовать копирование таких объёмов?

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

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

У вас наверняка большая часть объема базы - архивные данные.
Попробуйте вынести их в read-only файловую группу, и сделать ее бэкап один раз, соответственно бэкапить придется только активную часть базы.

me2k
2000 СП4

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