Физический Standby DB для Oracle SE

В комментариях к статье хабраюзера querct «Еще раз про Oracle standby» возник вопрос о возможности создания сервера наката (standby) на Oracle SE. Ответ — возможно. Любопытно? Пожалуйте под кат.

Дабы не вводить никого в замешательство и сохранить единообразие формы и сущности, в статье будут приняты все обозначения и требования из упоминаемой статьи. Теоретическую часть можно почерпнуть там же, я же расскажу об особенностях реализации standby базы с помощью Oracle SE и постараюсь осветить возможные «подводные камни».

Для начала необходимо: 2 разных сервера, для основной и резервной БД, с идентичными ОС, пользователями и группами пользователей — владельцев всех файлов и каталогов Oracle, а так же присутствие абсолютно одинаковых profile этих пользователей, а также вся структура каталогов и переменные окружения одинаковы. Oracle software на резервном сервере уже установлено.

Приступим.

1 шаг:
Для начала, нам нужно скопировать все файлы основной БД на резервный сервер. В зависимости от режима работы базы и ее объема существуют разные варианты. Самый простой, но не всегда приемлимый способ, это сделать холодный бекап. Сложность в том, что для этого надо останавливать БД — если у вас эта возможность есть — замечательно. Останавливаете базу и просто копируете файлы данных. А также делаете резервные копии управляющих файлов (на всякий случай) и оперативных журналов.

Получить список необходимого для копирования можно так:

SQL> select name from v$datafile;
SQL> select member from v$logfile;

Если возможности останосить базу нет, то необходимо сделать горячий бекап. Для этого можно воспользоваться утилитой RMAN, либо провести процедуру в ручном режиме:
Для этого необходимо:

SQL> alter tablespace <TB_name> begin backup;

и скопировать все файлы данных, входящие в это табличное пространство.

Важно! Не забудте отключить режим backup после копирования всех файлов.

SQL> alter tablespace <TB_name> end backup;

Повторить для всех табличных пространств. Бекап получен.

2 шаг:
Теперь нам необходимо создать управляющий файл для нашей standby БД.
Тут все просто, на основном сервере:

SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS 'имя_файла_для_стендбая';

3 шаг:
Копируем все файлы, относящиеся к нашей основной БД на резервный сервер(файлы данных, управляющие файлы, файл паролей и redologs), т.о. мы получаем две идентичных БД на двух серверах.

4 шаг:
Заменить все управляющие файлы на standby на созданный на 2 шаге.
Количество и адреса можно посмотреть в параметре control_files.

SQL> show parameter control_files;

5 шаг:
Здесь мы и получаем основную проблему с использованием Oracle SE, отсутствует тот самый DataGuard, который полностью реализует процесс передачи и применения архивных логов на standby.
Наша задача передать архивлоги с основной базы на резервную. Для передаци логов можно использовать SSH, либо расшарить папку из параметра LOG_ARCHIVE_DEST_n и сделать ее mount на нашем standby, но это уже вопрос безопасности.

Реализовать периодическую передачу можно простейшим shell скриптом, занесенным в расписание cron. Примеры таких скриптов можно найти в сети, либо написать самому.

Советы:
— В скрипте желательно реализовать процесс логирования работы самого скрипта, чтоб вы всегда смогли отследить его работу;
— Также рекомендую автоматизировать процесс удаления примененных логов, что бы вы не столкнулись с нехваткой места(при активном формировании архивлогов), но здесь тоже есть свои сложности. Вы должны помнить о возможности нарушения работы standby сервера и не удалить еще не применненые, а так же о необходимости регулярного резервирования вашей БД, чтоб вы не удалили примененные логи до их основного бекапа(например на ленточное устройство). Эти моменты регулируются уже особенностями режимами работы вашей БД и политикой обеспечения доступности/надежности. Либо же ориентируясь на нагрузку на вашу БД регулярно чистить логи вручную.

6 шаг:
Запускаем standby:

SQL> startup nomount pfile=имя_файла_для_стендбая;
SQL> atler database mount standby database;
SQL> recover standby database;
AUTO

И всё — standby получен, накат архивных журналов происходит.

Важные замечания:
— При переключении с основной базы на резервную, основная не переходит в режим standby и ее надо пересоздать;
— При крахе основной базы вы можете потерять часть данных, которые не были заархивированы(временной промежуток регулируется периодичностью отработки скрипта в cron);
— Основная база при работе на Oracle SE(без использования DataGuard), не воспринимает резервную как таковую и следить за работай standby необходимо;
— При создании новых файлов данных на основной базе, их необходимо копировать на резервную;
— Standby БД может быть открыта в режиме read-only, но в таком случае накат логов происходить не будет, и после этого ее необходимо вернуть в прежнее состояние и завершить все сессии;
— Для перехода на резервную базу вы открываете в обычном режиме, не забыв поменять адреса(либо имя хоста) в tnsnames и listener.ora, что б ваши приложения, работающие с БД, продолжили функционировать в штатном режиме. Либо же с использованием возможностей сетевого оборудования, присваивать базам логические ip-адреса;
— На резервной базе данных вы будете видеть ошибку о том, что она не может найти следйющий архивный журнал;
— Знайте, этот журнал еще не заархивирован на основной БД, проверить это вы можете выполнив:

SQL> ALTER SYSTEM SWITCH LOGFILE;

На основной базе, дождаться отработки скрипта по расписанию(либо выполнить его принудительно) и проверить факт наката этого лога на standby.

Итог:

Подобный вариант решения проблемы организации standby более трудоемкий, требует больших усилий и контроля работы со стороны администратора БД, но значительно дешевле варианта с DataGuard Oracle EE.