Супермаг
...
. Настройка отказоустойчивости Oracle Database
ГК «Сервис Плюс»
Москва, 2015
Оглавление
Введение
Кластеризация СУБД
Описание
Возможности
Схема лицензирования 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 БД
...
Real Application Clusters - RAC – опция базы данных Oracle, которая позволяет настраивать отказоустойчивые и хорошо масштабируемые серверы баз данных на основе объединения нескольких вычислительных систем. В архитектуре RAC экземпляры СУБД Oracle одновременно выполняются на нескольких объединенных в кластер системах, производя совместное управление общей базой данных.
По существу, с точки зрения приложения – это единая СУБД. Такой подход позволяет достичь исключительно высокой готовности и масштабируемости любых приложений. Гибкость и эффективность планирования ресурсов позволяют наращивать мощности до любого уровня по требованию, по мере изменения потребностей бизнеса.
RAC используется для создания корпоративных сетей распределенной обработки данных. Такие сети строятся из большого количества стандартизованных недорогих компонентов: процессоров, серверов, сетевых устройств и устройств хранения данных. RAC – это программный продукт и технология, позволяющая объединить все эти компоненты в эффективную вычислительную систему всей организации.
| Якорь |
|---|
| _Toc426358717 |
|---|
| _Toc426358717 |
|---|
|
Возможности
Масштабируемость
RAC дает пользователям возможность добавлять в кластер новые узлы при возрастании требований к ресурсам, производить постепенное увеличение мощности системы при оптимизации затрат на оборудование.
При использовании вместе с СУБД Oracle сформированные с помощью Grid-технологии пулы стандартных недорогих компьютеров и модульных систем хранения данных делают это решение еще более гибким. Процесс наращивания ресурсов становится значительно более простым и быстрым, поскольку при необходимости расширения к кластеру можно добавлять новые узлы вместо того чтобы заменять существующие более мощными. Технология Cache Fusion, реализованная в Real Application Clusters, и поддержка InfiniBand, предусмотренная в СУБД Oracle, позволяют практически линейно наращивать пропускную способность системы без каких-либо изменений в приложениях.
Высокая готовность
Другое ключевое преимущество кластерной архитектуры на основе Oracle RAC – присущая ей устойчивость к отказам за счет наличия множества узлов. Поскольку физические узлы работают независимо друг от друга, отказ одного или нескольких узлов не оказывает влияния на работу остальных узлов кластера. Аварийное переключение сервиса может быть произведено на любой узел Grid. В самой крайней ситуации система на базе Real Application Clusters способна поддерживать работу базы данных даже при отказе всех узлов за исключением одного.
Подобная архитектура позволяет прозрачно вводить в действие узлы или выводить их из работы, например, для технического обслуживания, в то время как остальная часть кластера будет продолжать поддерживать работу СУБД.
Баланс нагрузки
RAC поддерживает новую абстракцию, получившую название сервиса. Сервисы представляют классы пользователей базы данных или приложений. Задание и применение бизнес-политик к сервисам позволяет разрешать такие проблемы, как выделение узлов на периоды пиковых вычислительных нагрузок или автоматическое устранение последствий отказа сервера. Это гарантирует предоставление системных ресурсов в требуемый период времени и там, где это необходимо для решения поставленных задач.
| Якорь |
|---|
| _Toc426358718 |
|---|
| _Toc426358718 |
|---|
|
Схема лицензирования Oracle RAC
Если вы используете СУБД Oracle редакции Enterprise, то вам необходимо покупать лицензии на опцию Oracle RAC. Опции лицензируются согласно приобретенному количеству лицензий на СУБД Oracle Enterprise Edition.
Но если вы используете Oracle Standard Edition, то можно использовать функционал Real Application Cluster бесплатно!
| Якорь |
|---|
| _Toc426358719 |
|---|
| _Toc426358719 |
|---|
|
Настройка Oracle RAC
Детальные шаги настройки RAC мы опускаем, так как они полностью и очень подробно приведены в документации компании Oracle.
| Якорь |
|---|
| _Toc426358720 |
|---|
| _Toc426358720 |
|---|
|
Резервирование СУБД – Online Backup
...
Резервное копирование СУБД Oracle подразумевает создание резервных копий файлов данных, управляющих файлов и файлов архивных журналов повторного выполнения.
Различают два вида резервирования: «горячее» и «холодное» (либо «online» и «offline» ). Первое возможно при работающем экземпляре Oracle, второе – только при остановленном. Нас с точки зрения обеспечения максимальной отказоустойчивости интересует только «горячее» резервное копирование.
Выполняется оно с помощью утилиты Oracle Recovery Manager - RMAN.
| Якорь |
|---|
| _Toc426358722 |
|---|
| _Toc426358722 |
|---|
|
Схема лицензирования RMAN
RMAN – полностью бесплатная утилита в составе поставки Oracle Database.
| Якорь |
|---|
| _Toc426358723 |
|---|
| _Toc426358723 |
|---|
|
Настройка СУБД
...
Пример скрипта создания полного бекапа. Вызываем в командной строке утилиту 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
| Якорь |
|---|
| _Toc426358725 |
|---|
| _Toc426358725 |
|---|
|
Рекомендуемый сценарий резервирования
...
Основной и резервный серверы сконфигурированы как кластер, каждый сервер имеет собственное дисковое хранилище. СУБД Oracle установлена на два сервера и оба сервера запущены.
Журнальные файлы основной СУБД по мере их заполнения пересылаются на резервную СУБД. Таким образом, резервная СУБД всегда отстает от основной примерно на один, последний, журнальный файл.
В случае выхода из строя одного из серверов продолжает работать резервный, и информация поддерживается в актуальном состоянии. Переход к резервной БД необратим.
| Якорь |
|---|
| _Toc426358728 |
|---|
| _Toc426358728 |
|---|
|
Схема лицензирования Manual Standby
Необходимо лицензировать второй – резервный- сервер СУБД. Причем редакция резервного сервера должна полностью совпадать с редакцией основного.
| Якорь |
|---|
| _Toc426358729 |
|---|
| _Toc426358729 |
|---|
|
Предварительные настройки
...
Для успешной передачи на резервную БД всех изменении в исходной БД – они должны попадать в журналы повторного выполнения. Для этого необходимо перевести СУБД в режим архивирования журналов.
Проверяем, включен ли этот режим. Для этого подключаемся к основной БД под полномочиями 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.
| Якорь |
|---|
| _Toc426358732 |
|---|
| _Toc426358732 |
|---|
|
Включение принудительного журналирования изменений
Некоторые операции в БД могут выполняться с опцией NOLOGGING (как при указании хинта в запросе, так и при наличии этой опции у какой-либо таблицы, табличного пространства). Поэтому для гарантированного появления всех изменений в журналах повторного выполнения следует включить принудительное журналирование всех операций основной БД:
Для этого следует выполнить команду под SYSDBA:
sql>ALTER DATABASE FORCE LOGGING;
| Якорь |
|---|
| _Toc426358733 |
|---|
| _Toc426358733 |
|---|
|
Создание резервной копии СУБД
...
Также копируем в каталог C:\BACKUP файл паролей СУБД. Он находится по умолчанию в каталоге %ORACLE_HOME%\database и именуется в формате PWD%ORACLE_SID%.ora
Выполняем запрос к основной БД:
sql>select dbid from v$database;
| Якорь |
|---|
| _Toc426358734 |
|---|
| _Toc426358734 |
|---|
|
Перенос резервной копии на сервер Standby
На сервере резервной БД также создаем каталог 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 резервного сервера.
| Якорь |
|---|
| _Toc426358735 |
|---|
| _Toc426358735 |
|---|
|
Развертывание резервной копии на сервере Standby
На резервном сервере запускаем консоль 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;
| Якорь |
|---|
| _Toc426358736 |
|---|
| _Toc426358736 |
|---|
|
Включение режима применения логов на сервере Standby
В консоли sqlplus под полномочиями sysdba включаем режим применения журналов повторного выполнения на сервере Standby:
cmd>sqlplus "as sysdba"
sql>alter database recover automatic standby database until cancel;
sql>alter database recover cancel;
| Якорь |
|---|
| _Toc426358737 |
|---|
| _Toc426358737 |
|---|
|
Включение режима read only на сервере Standby
В момент включения режима доступа к БД Standby «только на чтение» невозможно применение журналов с основной БД. Поэтому этот вариант работы нежелателен. Но допустим если периодически – например, каждую ночь – будет осуществляться применение журналов повторного выполнения за прошедшие сутки.
cmd>sqlplus "as sysdba"
sql>shutdown immediate
sql>startup nomount;
sql>alter database mount standby database;
sql>alter database open read only;
| Якорь |
|---|
| _Toc426358738 |
|---|
| _Toc426358738 |
|---|
|
Перенос и применение логов на сервере Standby
Перенос журналов повторного выполнения может осуществляться скриптами копирования файлов. Для простоты рассмотрим вариант, когда на сервере 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 минут из-за потенциально высокой нагрузки на процесс архивации журналов.
| Якорь |
|---|
| _Toc426358739 |
|---|
| _Toc426358739 |
|---|
|
Мониторинг работы Manual Standby
...
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 уже для этой – активированной СУБД.
Логичным выглядит вариант, когда после восстановления СУБД, бывшей ранее основной, она настраивается теперь уже как резервная по отношению к текущей БД. Настройку следует выполнять аналогично описанным в этом разделе шагам.
| Якорь |
|---|
| _Toc426358741 |
|---|
| _Toc426358741 |
|---|
|
Переключение клиентского ПО на активированную Standby БД
...