Админ оракла я уже много лет, но вот реализовать горячий бэкап при моих стажных пока не доводилось. Тупо не было смысла пока была возможность делать бэкапы холодные, такие любимые и проверенные временем, не требующие наличия бубна и заячьей лапки в некоторых случаях... Эх, было время. Но все растет все меняется, и вот наш бухгалтерский софт подвязали на текущий учет, а он, сука, работает круглосуточно. Всякие дядьки на подстанциях по ночам составляют планы и т.д. Ну а что еще делать ночью на подстанции где-нибудь в чигирях у черта на куличках, при наличии канала связи и куче свободного времени...
Итак, реализуем горячий бэкап и составляем механизм для восстановления из бэкапа...
Идея горячей резервной копии проста как валенок, при наличии соответствующих знаний :). Все происходит следующим образом:
1. С каждым табличным пространством поочередно проводится следующий набор операций:
-- табличное пространство переводится в режим горячего резервного копирования (после этого данные в него писаться перестают и пишутся только в журналы транзакций, до момента перевода в нормальный рабочий режим)
-- файлы данных табличного пространства копируются в место резервной копии
-- табличное пространство выводится из режима горячего резервного копирования
2. Производится принудительный переворот журналов транзакций
3. Делается резервная копия контрольных файлов 2-мя методами (trace, to file)
4. Делается резервная копия online redo log
5. Делается резервная копия archive redo log
6. Желательно сделать резервную копию конфигурационных файлов (init, orapwd, /etc, network/admin, скриптов резервного копирования и сбора статистики и т.д.)
В результате всех операций получаем набор файлов из которых, при наличии мозга, можно гарантированно восстановить базу.
Идея восстановления из горячей резервной копии просто как валенок с другой ноги, не той, которая была использована для понимания простоты создания резервной копии :) Тут последовательность действий следующая:
1. Все файлы из резервной копии раскладываются по местам. Что это за места такие вы, как создатель резервной копии должны быть в курсе. Если вы не создатель, применяйте мозг, все получится. Если вы не создатель, и мозга нет, то странно что вы вообще интересуетесь такими вопросами и читаете этот блог.
2. Контрольный файл забэкапленый to file плодим тупым копированием в соответствии со значениями, указаными в init файле.
3. открываем базу в nomount
4. Выполняем инструкции по созданию контрольных файлов из trace копии контрольных файлов.
5. Гасим базу immediate.
6. Запускаем в mount
7. Выполняем recover database
8. открываем базу.
9. для верочки еще можно ее перезапустить и увидеть, что все нормально заработало :)
Видите, все просто :):):)
Ну а теперь конкретно реализация скриптами.
Читать далее
год назад
