“Горячее” резервное копирование Oracle с использованием мгновенных снимков ZFS и процедура восстановления

Кхм – по-русски не звучит, потому плюнул – написал in english. Вот возникла задачка, вот и сделал для себя шпаргалку, чтобы кругами не “нарезать” по сайтам – я все-таки далек изрядно от Oracle DBA’s – специфика у меня другая, но вот приходиться и подумать иногда на отстраненные темы…

Рекомендовано к прочтению: Backup and Recovery@orafaq.com, масса полезной документации лежит здесь. Ну и Google никто не отменял.

Итак: есть Oracle 10gR2 + Solaris 10 x86_64. Есть БД. Некая. Которая лежит на ZFS – плюсы и минусы такого размещения я не обсуждаю, по крайней мере – здесь. Есть метод фактически прошлого века – Oracle User-Managed Hot Backups. Настоящие джежаи меня заклюют, но я не вижу способа использования RMAN в сочетании с ZFS Snapshot в рамках одной машины (вижу, но об этом – другой раз 😉 ). Надо: сделать копию БД, которая была бы пригодна к однозначному восстановлению.
Далее – много букофф…

Приступим.
– любым доступным образом проверяем: наличие в памяти Oracle (я обычно смотрю ps -ef | grep pmon), статус БД (открыта/закрыта/etc. – через sqlplus), статус архивации (база ДОЛЖНА быть в состояние ARCHIVELOG – без этого не будет горячего бэкапа), уточняем, куда пишуться наши архивные логи – не буду описывать, как это сделать. Все узнали? Приступаем.
– открываем 2 терминала: 1-й для входа пользователя oracle (наш sqlplus будет работать здесь), 2-й – для root.
– запускаем sqlplus, даем команду – переключаем группу логов – важность сего мероприятия заключена в том, чтобы нам не попасть на “лишнее” переключение в момент создания снимка – эта команда также изменит последовательность:

alter system switch logfile;

– даем команду, которая и начнет наше горячее резвное копирование:

alter database begin backup;

– делаем снимок (от id=0/root):

/usr/sbin/zfs snapshot

– прекращаем процедуру горячего бэкапа:

alter database end backup;

– архивируем текущий журнал – КРАЙНЕ важно получить этот файл вместе с бэкапом – он будет лежать в нашем ранее определенном месте:

alter system archive log current;

– делаем бэкап нашего Самого Важного Файла внутри БД – он нам нужен при восстановлении:

alter database backup controlfile to '/tmp/control-<inst_name>.ctl.bpck';

– на всякий случай можно изготовить копию SPFILE to PFILE и тоже положить ее к нашей резервной копии.
– для упрощения жизни – также полезно изготовить копию control file в читаемом виде, забрав ее в процессе из трейсов:

Все, что нам нужно для получения копии БД – у нас есть. Можем приступить к:
– заливанию всего полчученного счастья на ленты средствами, например NetBackup – делаем клона (zfs clone) в удобном нам месте, “льем” на ленты, не забывая при этом о том, что CoW-snapshot по своей природе создаст нагрузку на дисковую подсистему, которая будет весьма активно конкурировать с нашей продуктивной частью БД.
– созданию клона БД на новой системе – здесь фантазия должна подсказать, что использовать – можно использовать механизмы zfs send/zfs receive (все равно перекидывать файлы руками прийдется), либо использовать NFS-share – либо придумайте сами.
– какие еще варианты – например, такие – быстрое клонирование БД с нашими поправками 😉

При восстановлении есть ряд правил:
– полностью повторяем структуры – где лежат наши файлы с пространствами, где лежат контролы, каталоги для редо-логов
– перед любой манипуляцией дважды проверяем (double-check – как мне нравиться эта фразочка 🙂 ) наличие всего и вся – каталогов, прав доступа, что вводим и как вводим – порядок команд имеет значение!
– не забываем заменить наши control-фалы на заранее сохраненный нами.
– не забываем восстановить наш ранее сохраненный наш файл архивного лога – он нам необходим при восстановлении.

Последовательность восстановления довольно простая. Для начала – монтируем БД (по вкусу используя заранее заготовленный pfile):

startup mount

– выполняем процедуру восстановления:

recover database until cancel using backup controlfile;

Собственно, ньюанс простой – после использования первого же архивного файла мы должны набрать команду CANCEL и прекратить восстановление. Так нам нужно состояние на момент выполнения процедуры горячего бэкапа (фактически его окончание – это переключение лога). Если мы были настолько хитры (и продуманны), что у нас есть набор ВСЕХ архивных логов, изготовленных БД до момента останова (наступления часа Икс – развала нашей инстанции) – восстанавливаем наши логи в нужный каталог, даем команду:

recover automatic database until cancel using backup controlfile;

… и нервно курим “бамбук” в сторонке, до окончания восстановления – последний архив (на котором мы, естественно, “споткнемся” и процедура потребует ручного вмешательства), которого нам так будет не хватать – это и будет повод набрать CANCEL, завершив тем самым процедуру восстановления…

Короче, шансы правильно использовать механизмы, предоставляемые СУБД у нас есть – и они неплохие, если внимательно изучать документацию, делать все последовательно – имея при это вменяемый recovery plan, в котором будет написано множество “а что, если”.

Что можно легко доделать: для начала, избавиться от root везде, где только можно – для этого у нас есть мехнизмы делегирования внутри ZFS. Данная заметка элементарно переноситься на систымы Sun Unified Storage. Короче – был бы интерес, а я бы написал 😉