Оглавление
Введение
Кластеризация СУБД
Описание
Возможности
Схема лицензирования Oracle RAC
Настройка Oracle RAC
Резервирование СУБД – Online Backup
Описание
Схема лицензирования RMAN
Настройка СУБД
Примеры скриптов резервирования
Рекомендуемый сценарий резервирования
Резервная система – Manual Standby
Описание
Схема лицензирования Manual Standby
Предварительные настройки
Настройка Manual Standby
Включение режима ARCHIVELOG
Включение принудительного журналирования изменений
Создание резервной копии СУБД
Перенос резервной копии на сервер Standby
Развертывание резервной копии на сервере Standby
Включение режима применения логов на сервере Standby
Включение режима read only на сервере Standby
Перенос и применение логов на сервере Standby
Мониторинг работы Manual Standby
Активация Manual Standby в качестве рабочей БД
Переключение клиентского ПО на активированную Standby БД
Для обеспечения надежного функционирования СУБД Oracle - с минимальной вероятностью потери важных для бизнеса данных – предлагается использовать следующие возможности Oracle:
Не секрет, что штатные решения компании Oracle достаточно дороги. Поэтому в данном документе мы рассматриваем максимально дешевые варианты настройки – без применения стандартных и рекомендуемых опций СУБД Oracle – DataGuard, ActiveDataGuard, RAC (как опция Enterprise-редакции СУБД). Также предполагается, что в качестве СУБД используется Oracle редакции Standard (именно в этой редакции используется СУБД в комплексе «Супермаг»).
Предполагается, что для настройки отказоустойчивости будет использована СУБД Oracle версии не ниже 11g, установленная в ОС Windows.
Real Application Clusters - RAC – опция базы данных Oracle, которая позволяет настраивать отказоустойчивые и хорошо масштабируемые серверы баз данных на основе объединения нескольких вычислительных систем. В архитектуре RAC экземпляры СУБД Oracle одновременно выполняются на нескольких объединенных в кластер системах, производя совместное управление общей базой данных.
По существу, с точки зрения приложения – это единая СУБД. Такой подход позволяет достичь исключительно высокой готовности и масштабируемости любых приложений. Гибкость и эффективность планирования ресурсов позволяют наращивать мощности до любого уровня по требованию, по мере изменения потребностей бизнеса.
RAC используется для создания корпоративных сетей распределенной обработки данных. Такие сети строятся из большого количества стандартизованных недорогих компонентов: процессоров, серверов, сетевых устройств и устройств хранения данных. RAC – это программный продукт и технология, позволяющая объединить все эти компоненты в эффективную вычислительную систему всей организации.
Масштабируемость
RAC дает пользователям возможность добавлять в кластер новые узлы при возрастании требований к ресурсам, производить постепенное увеличение мощности системы при оптимизации затрат на оборудование.
При использовании вместе с СУБД Oracle сформированные с помощью Grid-технологии пулы стандартных недорогих компьютеров и модульных систем хранения данных делают это решение еще более гибким. Процесс наращивания ресурсов становится значительно более простым и быстрым, поскольку при необходимости расширения к кластеру можно добавлять новые узлы вместо того чтобы заменять существующие более мощными. Технология Cache Fusion, реализованная в Real Application Clusters, и поддержка InfiniBand, предусмотренная в СУБД Oracle, позволяют практически линейно наращивать пропускную способность системы без каких-либо изменений в приложениях.
Высокая готовность
Другое ключевое преимущество кластерной архитектуры на основе Oracle RAC – присущая ей устойчивость к отказам за счет наличия множества узлов. Поскольку физические узлы работают независимо друг от друга, отказ одного или нескольких узлов не оказывает влияния на работу остальных узлов кластера. Аварийное переключение сервиса может быть произведено на любой узел Grid. В самой крайней ситуации система на базе Real Application Clusters способна поддерживать работу базы данных даже при отказе всех узлов за исключением одного.
Подобная архитектура позволяет прозрачно вводить в действие узлы или выводить их из работы, например, для технического обслуживания, в то время как остальная часть кластера будет продолжать поддерживать работу СУБД.
Баланс нагрузки
RAC поддерживает новую абстракцию, получившую название сервиса. Сервисы представляют классы пользователей базы данных или приложений. Задание и применение бизнес-политик к сервисам позволяет разрешать такие проблемы, как выделение узлов на периоды пиковых вычислительных нагрузок или автоматическое устранение последствий отказа сервера. Это гарантирует предоставление системных ресурсов в требуемый период времени и там, где это необходимо для решения поставленных задач.
Если вы используете СУБД Oracle редакции Enterprise, то вам необходимо покупать лицензии на опцию Oracle RAC. Опции лицензируются согласно приобретенному количеству лицензий на СУБД Oracle Enterprise Edition.
Но если вы используете Oracle Standard Edition, то можно использовать функционал Real Application Cluster бесплатно!
Детальные шаги настройки RAC мы опускаем, так как они полностью и очень подробно приведены в документации компании Oracle.
Резервное копирование СУБД Oracle подразумевает создание резервных копий файлов данных, управляющих файлов и файлов архивных журналов повторного выполнения.
Различают два вида резервирования: «горячее» и «холодное» (либо «online» и «offline» ). Первое возможно при работающем экземпляре Oracle, второе – только при остановленном. Нас с точки зрения обеспечения максимальной отказоустойчивости интересует только «горячее» резервное копирование.
Выполняется оно с помощью утилиты Oracle Recovery Manager - RMAN.
RMAN – полностью бесплатная утилита в составе поставки Oracle Database.
Необходимым условием для «горячего» резервирования СУБД Oracle является включение режима ARCHIVELOG.
Oracle записывает все изменения, которые вносятся в находящиеся в памяти блоки данных, в оперативные журналы повторного выполнения (online redo logs), и делает это, как правило, перед их записью в файлы базы данных. Во время процесса восстановления Oracle использует зафиксированные в файлах этих журналов изменения для приведения базы данных в актуальное состояние. Oracle поддерживает два режима для управления такими файлами:
Пример скрипта создания полного бекапа. Вызываем в командной строке утилиту RMAN:
cmd> rman
В консоли RMAN подключаемся к текущей БД:
RMAN>connect target /
И запускаем следующий скрипт:
run { configure retention policy to redundancy 3; configure controlfile autobackup on; CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; backup full database noexclude include current controlfile spfile; format 'С:\backup%d_datafile_%s_%p.bak' tag 'backup_name'; delete noprompt obsolete;
delete archivelog until time 'sysdate-7';
CONFIGURE BACKUP OPTIMIZATION CLEAR; CONFIGURE RETENTION POLICY CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;}
Приведенный скрипт создаст резервную копию БД в каталоге C:\backup.
Восстановление БД из резервной копии возможно с помощью команд:
RMAN> RESTORE DATABASE;RMAN> RECOVER DATABASE;RMAN> ALTER DATABASE OPEN;
Список созданных резервных копий и детали их получения можно посмотреть в системной представлении v$rman_backup_job_details
Мы рекомендуем запланировать выполнение скрипта RMAN по созданию резервной горячей копии на ежедневной основе с помощью «Планировщика» Windows.
Работу скрипта следует планировать на время минимальной работы с БД – ночью. Причем это должно быть не только время минимальной работы пользователей с БД, но и время, в которое не запускаются внутренние процедуры БД и Супермага (например, процедуры расчета себестоимости).
Рекомендуем задавать параметр retention policy не менее 3-х. Т.е. всегда должны быть как минимум 3 версии архива.
Также необходимо удалять устаревшие архивные журналы повторного выполнения, но с достаточно большим запасом – чтобы они успели быть применены на ручном физическом Standby.
Основной и резервный серверы сконфигурированы как кластер, каждый сервер имеет собственное дисковое хранилище. СУБД Oracle установлена на два сервера и оба сервера запущены.
Журнальные файлы основной СУБД по мере их заполнения пересылаются на резервную СУБД. Таким образом, резервная СУБД всегда отстает от основной примерно на один, последний, журнальный файл.
В случае выхода из строя одного из серверов продолжает работать резервный, и информация поддерживается в актуальном состоянии. Переход к резервной БД необратим.
Необходимо лицензировать второй – резервный- сервер СУБД. Причем редакция резервного сервера должна полностью совпадать с редакцией основного.
Для настройки физического Standby с «ручным» переносом и применением журналов повторного выполнения необходимо наличие дополнительного сервера той же операционной системы с установленной СУБД Oracle:
что и на сервере основной БД.
Также оба сервера – основной и резервной БД – должны иметь общую сетевую папку.
Для успешной передачи на резервную БД всех изменении в исходной БД – они должны попадать в журналы повторного выполнения. Для этого необходимо перевести СУБД в режим архивирования журналов.
Проверяем, включен ли этот режим. Для этого подключаемся к основной БД под полномочиями SYSDBA:
cmd>sqlplus "as sysdba"
Если результат запроса
sql>SELECT log_mode FROM v$database;
возвращает NOARCHIVELOG, то необходимо подключится к основной БД под учетной записью SYSDBA и выполнить следующие команды:
sql>shutdown immediate;
sql>startup mount;
sql>alter database archivelog;
sql>alter database open;
Затем следует повторно проверить режим:
sql>SELECT log_mode FROM v$database;
Запрос должен вернуть значение ARCHIVELOG.
Некоторые операции в БД могут выполняться с опцией NOLOGGING (как при указании хинта в запросе, так и при наличии этой опции у какой-либо таблицы, табличного пространства). Поэтому для гарантированного появления всех изменений в журналах повторного выполнения следует включить принудительное журналирование всех операций основной БД:
Для этого следует выполнить команду под SYSDBA:
sql>ALTER DATABASE FORCE LOGGING;
На сервере основной БД создадим каталог C:\BACKUP, в который будем сохранять файлы для переноса на резервную копию СУБД.
На сервере основной БД запустим RMAN. Предварительно нужно добавить в переменную окружения PATH путь до каталога %ORACLE_HOME%\bin. Также необходимо определить переменные окружения ORACLE_HOME и ORACLE_SID. После этого вызываем в командной строке утилиту RMAN:
cmd> rman
В консоли RMAN подключаемся к текущей БД:
RMAN>connect target /
В этот момент необходимо прекратить всякую пользовательскую активность на основной БД.
Выполним следующий скрипт в консоли RMAN:
run
{
change archivelog all crosscheck;
allocate channel c1 type disk maxpiecesize 50G;
delete noprompt backup tag 'TO_STANDBY';
backup AS compressed backupset tag 'TO_STANDBY' format 'C:\backup\TO_STANDBY_datafiles_%s_%p'
database;
backup as copy current controlfile for standby format 'C:\backup\TO_STANDBY_control.ctl'
reuse;
sql "create pfile=''C:\backup\TO_STANDBY_pfile.ora'' from spfile";
release channel c1;
}
После выполнения RMAN скрипта в каталоге C:\BACKUP должны появиться файлы
Также копируем в каталог C:\BACKUP файл паролей СУБД. Он находится по умолчанию в каталоге %ORACLE_HOME%\database и именуется в формате PWD%ORACLE_SID%.ora
Выполняем запрос к основной БД:
sql>select dbid from v$database;
На сервере резервной БД также создаем каталог C:\BACKUP.
Переносим все содержимое каталога C:\BACKUP сервера основной БД на сервер резервной БД.
Задаем системные переменные окружения ORACLE_HOME и ORACLE_SID, ссылающиеся на домашнюю директорию и имя экземпляра СУБД резервного сервера. Также добавляем в начало системной переменной окружения PATH путь до %ORACLE_HOME%\bin.
Открываем на редактирование файл TO_STANDBY_pfile.ora на резервном сервере.
Добавляем следующие строки:
*.audit_trail='FALSE'
*.standby_file_management=AUTO
*.log_archive_dest_1='LOCATION=C:\backup'
Если резервная СУБД не содержит настроенного Listener на экземпляр БД с тем же SID/SERVICE, что и основная БД, то необходимо сконфигурировать его рестартовать. Также следует указать в файле %ORACLE_HOME%\NETWORK\ADMIN\tnsnames.ora запись для обращения к резервной БД.
Копируем файл паролей из каталога C:\BACKUP в каталог %ORACLE_HOME%\database резервного сервера.
На резервном сервере запускаем консоль RMAN:
cmd>rman
В консоли RMAN подключаемся к текущей БД:
RMAN>connect target /
Задаем dbid равным значению основной БД (подставьте вместо 123456789 корректное значение):
RMAN>set dbid 123456789
Стартуем резервную БД без монтирования файлов с параметрами отредактированного PFILE:
RMAN>startup force nomount pfile='C:\backup\TO_STANDBY_pfile.ora';
Восстанавливаем контрольный файл из резервной копии:
RMAN>restore controlfile from 'C:\backup\TO_STANDBY_control.ctl';
RMAN после восстановления напишет путь и имя до созданного контрольного файла. Это значение нужно указать в файле C:\backup\TO_STANDBY_pfile.ora, в строке:
*.control_files='…..'
Теперь можно примонтировать файлы резервной БД:
RMAN>alter database mount;
Запускаем процесс развертывания БД из файлов резервной копии:
RMAN> run{
restore database;
switch datafile all;
};
В консоли sqlplus под полномочиями sysdba выполним команды:
cmd>sqlplus "as sysdba"
sql>shutdown immediate;
sql>startup nomount pfile='C:\backup\TO_STANDBY_pfile.ora';
sql>create spfile from pfile='C:\backup\TO_STANDBY_pfile.ora';
sql>alter database mount standby database;
В консоли sqlplus под полномочиями sysdba включаем режим применения журналов повторного выполнения на сервере Standby:
cmd>sqlplus "as sysdba"
sql>alter database recover automatic standby database until cancel;
sql>alter database recover cancel;
В момент включения режима доступа к БД Standby «только на чтение» невозможно применение журналов с основной БД. Поэтому этот вариант работы нежелателен. Но допустим если периодически – например, каждую ночь – будет осуществляться применение журналов повторного выполнения за прошедшие сутки.
cmd>sqlplus "as sysdba"
sql>shutdown immediate
sql>startup nomount;
sql>alter database mount standby database;
sql>alter database open read only;
Перенос журналов повторного выполнения может осуществляться скриптами копирования файлов. Для простоты рассмотрим вариант, когда на сервере Standby примонтирована сетевая папка T:\ORACLE_ARCH, ссылающаяся на папку redo-журналов основной СУБД.
Расположение папки с архивными redo-журналами основного сервера определяется в параметре log_archive_dest_1. Посмотреть его значение можно в системном представлении v$parameter.
Если данный параметр пустой, можно узнать расположение архивных журналов запросом к системному представлению V$ARCHIVED_LOG. Если вы только что включили режим ARCHIVELOG, то журнальных файлов еще может не быть. Выполните команду
sql>alter system switch logfile;
И архивный журнал появится как в файловой системе основного сервера, так и запись о нем в таблице V$ARCHIVED_LOG.
Теперь, когда мы знаем, в какой папке основного сервера будут появляться файлы архивных журналов повторного выполнения – определим эту папку как сетевую с привилегиями на чтение пользователю, под которым стартует служба Oracle СУБД на сервере Standby.
На сервере Standby примонтируем сетевую папку в папку с именем T:\ORACLE_ARCH.
Также явно зададим для службы Oracle учетную запись, из-под которой должна работать служба. Эта учетная запись должна содержать указанную точку монтирования.
Наконец, следует исправить параметр log_archive_dest_1 на резервном сервере:
cmd>sqlplus "as sysdba"
sql>alter system set log_archive_dest_1='LOCATION=T:\ORACLE_ARCH';
Таким образом, после проделанных действий резервная СУБД всегда будет иметь доступ к файлам с архивными redo-журналами.
Для регулярного применения архивных журналов на резервном сервере следует запланировать (например, с помощью «Планировщика» Windows) с заданной периодичностью выполнение командного файла:
set ORACLE_BASE=C:\Oracle;
set ORACLE_HOME= c:\Oracle\server;
set PATH=%PATH%;%ORACLE_HOME%\bin;
sqlplus /nolog << EOFconnect sys/productive_sys_password@PRODUCTIVE as sysdba ALTER SYSTEM SWITCH LOGFILE;
exit;EOF
sqlplus /nolog << EOFconnect sys/standby_sys_password@STANDBY as sysdba ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE UNTIL CANCEL;
ALTER DATABASE RECOVER CANCEL;exit;EOF
Очевидно, что на резервном сервере должна быть настроена tns-запись PRODUCTIVE в файле %ORACLE_HOME%/network/admin/tnsnames.ora, ссылающаяся на экземпляр основной СУБД. И tns-запись STANDBY, ссылающая на экземляр резервной СУБД.
Чем чаще будет выполняться этот файл, тем меньше будет отставание резервной СУБД от основной. Но не рекомендуется выполнять его чаще чем раз в 5 минут из-за потенциально высокой нагрузки на процесс архивации журналов.
Необходимо осознавать, что в ходе ручного применения журналов повторного выполнения на Standby сервере возможны какие-либо коллизии. Это могут быть сетевые проблемы, проблемы доступа к примонтированной сетевой папке, проблемы доступа по tns-протоколу к основной БД и т.д.
Поэтому обязательно следует настроить какой-либо мониторинг работоспособности механизма передачи и применения архивных журналов.
Мы рекомендуем использовать в качестве системы всеобщего мониторинга ZABBIX. Opensource-систему, с открыми исходными кодами, большим сообществом пользователей и наличием в интернете множества готовых скриптов и шаблонов различных видов мониторинга.
Что делать если беда все-таки произошла: пользователи звонят по телефонам и сообщают о том, что БД недоступна; либо (что предпочтительно) система автоматического мониторинга (например, ZABBIX или NAGIOS) уведомила администратора СУБД о падении основного сервера…
В случае возникновения сбоев в работе основного сервера БД мы не рекомендуем настраивать какое-либо автоматические переключение – FAILOVER – с основной БД на Standby.
Эта операция необратима!!!
Поэтому решение об активации резервной БД должно приниматься штатным администратором СУБД соответственно ситуации.
Итак, шаги по активации:
sql>ALTER DATABASE RECOVER AUTOMATIC STANDBY DATABASE UNTIL CANCEL;
sql>ALTER DATABASE RECOVER CANCEL;
sql>shutdown immediate; sql>startup nomount; sql>alter database mount standby database;
sql>ALTER DATABASE ACTIVATE STANDBY DATABASE; sql>shutdown immediate sql>startup;
Следует понимать, что после активации Standby базы данных – она становится основной, PRIMARY. А значит, что нужно в кратчайшие сроки настроить физический Standby уже для этой – активированной СУБД.
Логичным выглядит вариант, когда после восстановления СУБД, бывшей ранее основной, она настраивается теперь уже как резервная по отношению к текущей БД. Настройку следует выполнять аналогично описанным в этом разделе шагам.
В случае активации резервного экземпляра вся работа пользователей должна осуществляться уже с ним.
Чтобы это произошло максимально безболезненно, мы рекомендуем следующие шаги:
Если же работа с БД осуществляется напрямую, в обход «сервера приложений Супермага», то рекомендуем следующее: