Standby oracle что это
Развернув информационную систему на базе СУБД Oracle и организовав надёжную стратегию резервного копирования-восстановления, можно приступать к производственной эксплуатации системы. В случае аварии возможно будет восстановить данные на требуемый момент времени. Но что делать, если допустимое время простоя не должно превышать нескольких минут? Тогда не обойтись без различных способов дублирования данных в режиме реального времени.
Один из вариантов такой репликации можно реализовать с помощью специальной базы данных Oracle Standby. Её можно применять совместно с обычным резервным копированием. Режим Standby DB обеспечивает опция Data Guard базы данных Oracle. Конфигурация Data Guard состоит из одной производственной и одной или более резервных баз данных standby, которые находятся в особом режиме, предусматривающем непрерывный приём и применение потока изменений от производственной базы. Изменения передаются по универсальной сети между разнесёнными географически серверами средствами Oracle Net [1]. Упрощённую схему взаимодействия смотрите на рисунке.
Структура Oracle Data Guard
В зависимости от конкретных требований по времени восстановления и допустимой потери данных при аварии (recovery time objective, recovery point objective [2]). Возможны различные сценарии реализации:
- Physical standby DB – резервная база данных является точной физической копией основной, находится в монтированном состоянии и при этом переносится поток redo-информации.
- Logical standby DB – резервная база данных не является точной копией основной, открыта в режиме чтения–записи и при этом переносится поток SQL-команд.
Конфигурация Oracle Data Guard может находиться в трёх режимах защиты: максимальной производительности (maximum performance), максимальной доступности (maximum availability) или максимальной защиты (maximum protection) [3]. Изменения передаются копированием журналов базы данных, текущих или архивных. Их запись осуществляется двумя процессами LGWR или ARCn. Процесс LGWR ведёт запись активных журналов, дополнительные настройки вынуждают его передавать изменения на резервный сервер с помощью так называемых standby redo log-файлов. Процесс ARCn переносит обычные архивные журналы, дополнительные настройки вынуждают его передавать их ещё и на удалённый сервер. Если выбраны режимы максимальных доступности или защиты, поток изменений передаётся с помощью данных, записываемых процессом LGWR. В режиме максимальной производительности возможна передача изменений как LGWR, так и ARCn.
В случае необходимости такая база может быть в короткий срок активирована в качестве производственной.
Поскольку БД Logical Standby не является точной копией основной базы и не поддерживает некоторые типы данных, SQL-команды, имеет требования по обеспечению уникальности строк в таблицах [4], рассмотрим реализацию именно Physical Standby DB. Мне кажется, что использовать БД Logical Standby лучше не как резервную копию, а в качестве базы для отчётов. Выберем для работы основной и резервной баз следующие настройки: производственная база работает в режиме maximum availability, переданные изменения применяются резервной базой в режиме Real-Time Apply Redo. Для такого режима работы инициатором передачи информации об изменениях выступает как раз процесс LGWR. Разница между режимами защиты заключается в том, что в режиме maximum protection транзакция фиксируется только тогда, когда запись произведена и в локальные журналы, и удалённо, в случае невозможности удалённой записи база данных останавливается, а в режиме maximum performance для продолжения работы достаточно только локальной записи, и основная БД продолжает свою работу, даже если связь с резервной базой отсутствует.
Режим maximum availability представляет компромиссный вариант, переключаясь между двумя режимами автоматически. Если связь работает без ошибок, передача происходит синхронно, если произошел сбой, автоматически осуществляется переход в менее строгий режим. После устранения сбоев режим максимальной защиты восстанавливается [5].
Что необходимо для создания тестовой среды:
- Два сервера одинаковой архитектуры, они могут отличаться по количеству процессоров, памяти, дисков, релизом операционной системы и т. п. Пусть сервер primary DB будет называться Poltava, а сервер standby – Fastiv.
- Режим базы данных должен быть ARCHIVELOG.
- Необходимо использовать программное обеспечение Oracle Server версии Enterprize Edition. В тестах будем использовать версию Oracle10.2 EE for Solaris.
Подготовка рабочей конфигурации
Итак, у нас имеется работающая производственная (primary) база данных Oracle, расположенная на сервере Poltava, и нам необходимо создать резервную базу standby на сервере Fastiv. Необходимо подготовить конфигурационные файлы и сделать дополнительные настройки.
Пусть имя базы будет «TST», присвоим для производственной primary-базы значение ORACLE_SID=ORCL, для standby – DB ORACLE_SID=ORCL1. Файлы primary DB находятся в каталоге /tstb/ORCL, файлы standby DB – в каталоге /tstb/ORCL1.
Для работы БД standby присваивать различные значения переменной ORACLE_SID для окружения основной и резервной баз данных необходимости нет, но это позволяет сделать так, чтобы файлы двух баз не накладывались друг на друга. Это позволяет перемещать базы между серверами, временно или в тестовых целях совмещать их на одном и том же сервере, имеющем два сетевых адресса (poltava и fastiv).
Необходимо выполнить следующие действия:
Включим режим force logging на производственной системе для принудительной записи в журналы БД информации, даже для так называемых операций Nologging:
SQL>ALTER DATABASE FORCE LOGGING;
Создадим файлы standby redo log. Они нужны только для работы БД standby, но мы создадим их и на primary, и на standby, в случае переключения ролей между базами не будет необходимости в их создании.
Файлы standby redo необходимо создать не меньшего размера, чем online redo log, и в количестве n+1 от количества redo group (cм. листинг 1).
Листинг 1. Добавление файлов Standby Redo
sqlplus "/ as sysdba"
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/tstb/ORCL/redo01.stb' SIZE 100M REUSE;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 '/tstb/ORCL/redo02.stb' SIZE 100M REUSE;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 '/tstb/ORCL/redo03.stb' SIZE 100M REUSE;
ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 '/tstb/ORCL/redo04.stb' SIZE 100M REUSE;
Установим параметры в файлах параметров init.ora/spfile.ora для primary и standby (см. листинг 2).
Листинг 2. Список параметров файла init.ora/spfile.ora
*.control_files='/tstb/ORCL/control01.ctl', '/tstb/ORCL/control02.ctl', '/tstb/ORCL/control03.ctl'
*.LOG_ARCHIVE_DEST_1='LOCATION=/tstb/log1/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=poltava'
*.LOG_ARCHIVE_DEST_2='SERVICE=fastiv LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=fastiv'
*.control_files='/tstb/ORCL1/control01.ctl', '/tstb/ORCL1/control02.ctl', '/tstb/ORCL1/control03.ctl'
*.LOG_ARCHIVE_DEST_1='LOCATION=/tstb/log/ VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=fastiv'
*.LOG_ARCHIVE_DEST_2='SERVICE=poltava LGWR SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=poltava'
Настроим Oracle Net для сетевых адресов Poltava и Fastiv.
Пример настроек файлов listener.ora и tnsnames.ora приведены в листинге 3.
Данный пост будет интересен тем, перед кем стоит задача настройки Oracle standby, но по каким-либо причинам расширение Data Guard отсутсвует (обычно для его работы требуется Enterprise Edition, но во многих случаях можно встретить Standard Edition). Как настраивать standby с Data Guard и что это вообще такое — можно прочитать в этом замечательном посте. Я, в свою очередь, расскажу как это сделать в спартанских обычных условиях.
Сервер/вм с CentOS 7 и СУБД Oracle Standard Edition (без Data Guard) под primary
Аналогичный сервер/клон вм с CentOS 7 и СУБД Oracle Standard Edition под standby
Настроить standby на текущей инфраструктуре без использования Data Guard.
Далее по тексту будут встречаться примеры команд и SQL-запросов. В начале можно будет увидеть следующие обозначения:
Прежде всего необходимо убедиться, что основная база запущена в режиме archivelog:
Если значение ARCHIVELOG в поле LOG_MODE отсутствует, необходимо перевести базу в этот режим:
Далее необходимо настроить канал, по которому primary-сервер будет передавать архивлоги на standby. Это можно сделать с помощью удаленного хранилища NFS, для его настройки на Primary-сервере потребуется:
Далее настраиваем standby-сервер:
Для проверки, что NFS работает можно закинуть на primary-сервере в директорию /mnt/logs_for_standby любой файлик, после выполнения указанных выше действий он должен появиться в папке /mnt/archivelog на standby-сервере. После настройки NFS и проверки, что он работает, можно переходить к настройке СУБД.
Первым делом внесем изменения в pfile на primary-сервере (вместо нужно подставить значение переменной окружения $ORACLE_HOME):
После открытия файла initTEST.ora на редактирование в него нужно добавить следующие строки:
*.log_archive_dest_1 — это путь для обычных бэкапов Oracle, там хранятся в том числе и архивлоги, созданные при создании инкрементальных бэкапов.
*.log_archive_dest_1 — это директория, в которую нужно дублировать архивлоги (для их применения на standby-сервере). Это та самая директория, которую мы расшарили по NFS.
Следующие параметры описывают состояние директорий и формат архивлогов. После изменения файла нужно перезапустить экземпляр базы (вместо нужно подставить значение переменной окружения $ORACLE_HOME):
Возможно, в дальнейшем мы захотим подключиться к standby-базе с основного сервера, поэтому отредактируем еще файл tnsnames.ora:
Добавляем в него следующие строчки (вместо нужно подставить IP-адрес standby-сервера):
Последним этапом на primary-сервере будет создание бэкапов:
После создания бэкапов на primary-сервере их нужно переместить в точно такие же директории на standby-сервер.
На этом моменте, можно сказать, что мы выполнили половину работы. Далее переходим на standby-сервер и приступаем к настройкам СУБД. Для начала отредактируем файлик tnsnames.ora на случай, если захотим подключаться к обеим базам:
Добавляем следующие строчки (вместо и , разумеется, должны быть реальные IP-адреса):
Стартуем listener и подготавливаем pfileSTBY.ora (вместо нужно подставить значение переменной окружения $ORACLE_HOME):
В pfileSTBY.ora необходимо добавить строчки:
*.control_files — расположение контрол-файла (его бэкап создавали на primary-сервере и должны были переместить в ту же директорию на standby)
*.standby_archive_dest — расположение архивлогов, которые нужно будет применять на standby (в нее монтируется NFS-шара)
Прежде чем переходить к следующему шагу необходимо убедиться, что на standby-сервере присутствуют все пути и файлы с правами oracle:oracle, указанные в pfileSTBY.ora.
Создаем spfile и стартуем экземпляр в nomount-режиме (вместо нужно подставить значение переменной окружения $ORACLE_HOME):
Бэкапы с primary-сервера должны быть перенесены в тот же каталог на standby-сервере (можно через NFS), разворачиваем экземпляр standby из бэкапа:
Далее создадим RMAN-скрипт, который будет запускаться по расписанию и накатывать на standby новые архивлоги. Назвать скрипт можно как угодно (например, rman_stby_recover.cmd), в нем должны быть следующие строки:
Запускать скрипт можно командой:
Разумеется, вместо должен быть указан пароль от SYS. Данную команду можно добавить в shell-скрипт и вызывать по расписанию CRON. Таким образом, поставленную задачу можно назвать выполненной. Архивлоги будут передаваться по NFS и применяться на standby-базе, поддерживая ее в актуальном состоянии. Далее можно экспериментировать с проверками доступности NFS-шары, настраивать мониторинги и т. д (об этом в данном посте уже писать не буду).
На этом все, надеюсь, что пост будет кому-то полезен. Спасибо за внимание, буду рад комментариям и вопросам.
В комментариях к статье хабраюзера 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 begin backup;
и скопировать все файлы данных, входящие в это табличное пространство.
Важно! Не забудте отключить режим backup после копирования всех файлов.
SQL> alter tablespace 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.
Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы
Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом
В контексте реализации отказоустойчивых решений основными задачами являются обеспечение быстрого времени восстановления при возникновении нештатной ситуации (аварии) и обеспечение минимальной потери или отсутствия потери данных. Казалось бы СУБД Oracle обеспечивает создание резервов данных (бэкапов) и поддерживает создание архивных журнолов, чего, в случае полного краха сервера, достаточно для восстановления данных и "подката вперёд" истории изменений базы. Однако, во-первых, это может потребовать довольно много времени и, во-вторых, практически всегда означает потерю части данных, не вошедших в архивные журналы
Для уменьшения времени восстановления сервиса и отрезка потерянных данных после краха сервера, а в отдельных случаях - и для исключения потери данных используется стандартное техническое решение - организация standby базы данных (или просто standby). В терминологии Oracle это решение называют "горячим" резервом, но в соответствии с природой этого решения правильнее говорить о "тёплом" резерве, как более адекватном термине, позаимствованном из терминологии PostgreeSQL. Связано это с тем, что в большинстве стучаев организация standby требует для активации ручных действий администратора, и не обеспечивает сохранность всех транзакций. Однако в отдельных частных случаях можно говорить о резерве "горячем", но это совсем отдельные и частные случаи
Методов организации standby существует несколько, но все они имеют одну основу - отдельный экземпляр и standby копия серверной БД, обычно расположенные на отдельном физическом сервере - для обеспечения резервирования "железа" - принимают с основной базы архивные журналы и периодически подкатывают их на standby копию. Таким образом при нештатной ситуации нет необходимости тратить время на разворачивание базы из резерва и накатывание истории изменений из архивных журналов. Такое решение называется "физический standby", ибо производится "подкат" модифицированых блоков из архивных журналов. Существует также "логический standby", при котором архивные журналы анализируются выделенными механизмами Oracle на предмет восстановления истории SQL операций, и именно такие SQL операции проводятся на standby копии БД. Однако логический стэндбай имеет ограничения я является более громоздким решением, и рассматриваться в настоящем обзоре не будет
За организацию standby необходимо платить, потому что такое решение требует трат на отдельную аппаратную платформу и на лицензирование отдельной копии ПО Oracle, используемой на standby сервере, в дополнение к аппаратной платформе и лицензированию сервера основного. Для Standart Edition редакции движка СУБД организация стэндбая выполняется в ручном режиме, когда именно администратор обеспечивает переключение и копирование архивных журналов ( alter system switch logfile; cp . ) на выделенный standby сервер и периодический запуск команд (alter database recover automatic standby database until cancel; alter database recover cancel;) подката этих журналов на standby копии БД. Обычно для этих целей пишутся скрипты, и задача эта не очень сложная
Возможны два варианта "ручного" стэндбая. В одном случае резервная БД запускается в режиме монтирования обычного контрольного файла с периодическим подкатом архивных журналов командой "RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL", а при необходимости перехода на standby база открывается с опцией RESETLOGS (так называемой смены инкарнации). Во втором случае создаётся специальный standby контрольный файл, монтируется в специальном режиме "ALTER DATABASE MOUNT STANDBY DATABASE" с периодическим подкатом журналов, и активацией при необходимости ". ACTIVATE STANDBY DATABASE", при которой база также открывается в режиме создания новой инкарнации
Особенностями "ручного" standby является обязательная потеря последней части транзакций при крахе основного сервера. Если же производится временный технологический переезд, при котором основной сервер тушится корректно, создания новой инкарнации и потери данных вполне можно избежать, потушив БД на основном сервере и подложив её контрольные файлы и оперативные журналы standby копии. Время простоя при этом обычно довольно мало, так как перенос контрольных файлов и оперативных журналов даже между удалёными площадками обычно не занимает много времени. Ещё одной особенностью является необходимость ручного создания файлов данных в stabdby копии БД при добавлении таких файлов в основной БД, на что, впрочем, можно написать автоматизирующий обработчик
Таким образом при допустимости потери небольшой порции последних транзакций организация "ручного" стэндбая является бюджетным и вполне работоспособным решением. Важно, что для SE редакции СУБД Oracle это практически единственное решение по организации standby, и для администраторов той части организаций, которые не готовы оплачивать дорогостоящий Enterprise Edition навык организации ручного стэндбая может быть полезен. Важно, что возможность потери транзакций сильно связан с особенностями организации прикладного решения, использующего СУБД. В частности возможность повторного ввода данных последних операций операционистами банка может сделать такое решение предпочтительным и в задачах автоматизации банковской сферы, и автор имел практический опыт администрирования таких решений
Более расширенная версия движка СУБД - Enterprise Edition - включает в себя механизм организации физических и логических standby под названием Data Guard. Этот механизм позволяет автоматизировать перенос архивных журналов на standby сервер, определяет пропущенные журналы и подкачивает их, что может быть востребовано при размещении standby сервера на удалённой площадке с относительно ненадёжным сетевым каналом, а также автоматический подкат полученных журналов на standby базу. То есть автоматизирует задачи, решаемые администратором при создании "ручного" standby. Но это не всё
Дополнительными возможностями Data Guard являются полуавтоматическая смена ролей, обеспечивающая переключение основной копии БД и standby копии между собой, что востребовано для сервисных задач (впрочем, это вполне несложно делается руками при использовании "ручного" standby). Кроме того возможен режим работы Data Guard, при котором данные в standby базу подкатываются не из архивных, но из оперативных журналов в режиме реального времени, что позволяет минимизировать возможную потерю данных, но делает конструкцию менее надёжной, ибо любой сбой на standby приводит к недоступности и основной базы, что связано с необходимостью синхронного наката данных оперативных журналов на standby в этом режиме. Синхронный standby подразуменвае установку резервного сервера в непосредственной близости к основному, что обусловлено довольно невысокой надёжностью и временем отклика разделяющих площадки каналов
Кроме того существует механизм автоматической активации standby при отказе доступности основной БД, называемый Data Guard Broker. Однако в силу нещадной глючности у пытавшихся использовать его коллег, равно как и в силу специфики задачи, когда решение о переходе на standby должно учитывать возможности сохранения информации (транзакций), возможности восстановления основного сервера и БД при крахе и особенности ситуации - то есть приниматься человеком по обычно мало формализуемым признакам, автор не считает использование брокера правильным выбором, и относит его больше к "бантикам, втюхиваемым заказчику"
Таким образом для SE редакции можно довольно просто настроить standby в ручном режиме, сопоставимым с таким же режимом для СУБД PostgreeSQL. Это будет надёжное и малобюджетное решение. Для пользователей EE редакции появляется возможность использования Data Guard, который в общем случае будет повторять функциональность и характеристики "ручного" standby. Важно, что при использовании в организации редакций SE и EE можно остановиться на ручном standby, который вполне будет работать и для EE редакции СУБД. Это позволит не разводить зоопарк решений. С другой стороны при необходимости использования дополнительного функционала от Data Guard последний довольно просто настраивается, что будет показано в следующих разделах настоящего обзора
Ещё одним тонким моментом является увязка механизмов резервного копирования данных и standby для исключения ситуации, когда архивные журналы уходят в резервную копию и более недоступны по основному месту расположения, но, в то же время они ещё не перенесены на standby сервер, например в силу проблем с каналами связи с удалённой площадкой, на которой размещён standby. Это особенно актуально для "ручного" режима организации standby
организация Standby посредством Data guard
Необходимо сразу оговориться, что DataGuard - опция Enterprise редакции СУБД, и если вы не лицензировали использование Enterprise, то методы построения standby для вас будут совершенно другими - во многом основывающимися на ручной реализации большей части механизмов, обеспечиваемых DataGuard (ав том числе - копирование архивных журналов на snandby, проверка отсутствия пропусков в последовательности журналов, ручной периодический накат журналов на standby базу, создание новых файлов данных вручную на standby при создании их на основной базе). Т.е. организация standby без Enterprise лицензии является достаточно геморойной, но вполне реализуемой задачей
Можно добавить, что в таком ручном варианте реализация Standby для Oracle вполне сопоставима с реализацией Standby для PostgreeSQL (детально описанный в документации по PostgreeSQL), что лишний раз заставляет задуматься о целесообразности использования дорогостоящего Oracle там, где можно использовать более дешевый, но вполне качественный аналог
В случае же, если у вас Enterprise редакция, вы можете использовать встроенный механизм построения Standby с разнообразным дополнительным функционалом (таким, как временная смена ролей для основной базы и базы standby). Итак, при использовании Data Guard последовательность организации и использования standby выглядит так:
режим сохранности данных меняется формулой
alter database set standby database to maximize [PERFOMANCE | IVAILABILITY | . ]
но !!
- при переводе из дефолта (PERF) нужно настроить копирование не ARCH, но LGWR, для чего в удаленном
archive_log_destination_x='SERVICE=. LGRW SYNC AFFIRM'
- при временной рокировке ролей master и standby (switchover) проблем возникать не должно, а вот при попытке поднять standby базу как master при отказе прежнего master (режим filover) - начинаются засады, и нужно сажать базу в mount, возвращать PERFOMANCE и выкидывать из переменной
arc_log_dest. модификаторы LGWR SYNC AFFIRM
Switchover - временная смена ролей
- режим switchover позволяет резво "рокировать" роли для тех. работ на основной базе и обратно
-- на master базе
select switchover_status from v$database ; => TO STANDBY
alter database commit to switchover to physical standby ;
shutdown immediate ;
закомментировать относящиеся к archive_log_dest_2 опции - иначе потом не просто сменить роли обратно
startup nomount ;
alter database mount standby database ;
alter database recover managed standby database disconnect from session ;
-- потом на standby базе
select switchover_status from v$database ; => TO PRIMARY
alter database commit to switchover to physical primary ;
shutdown immediate ;
раскомментировать относящиеся к archive_log_dest_2 опции для копирования журналов на standby
startup ;
-- потом на standby базе
alter system switch logfile ;
и потом обратный переход
Filover - поднятие standby до master при авари последнего
-- выверить, что накачено максимальное количество журналов
select from v$archive_gap
select from v$archived_log
при необходимости и доступности перенести недостающие журналы и
зарегистрировать их командой
alter database register physical logfile '. ' ;
-- т.к. gap показывает только последний ошибочный диапазон - повторять шаг 1, пока выборка не станет нулевой
-- тушится автонакатывание
alter database recover managed standby database finish ;
или
alter database recover managed standby database finish skip standby logfile ;
-- база делается новой master
alter database commit to switchover to primary ; (альтернатива - alter
database activate standby database ;)
shutdown ;
раскомментировать относящиеся к archive_log_dest_2(xxx) опции для копирования журналов с нового master на standby
startup ;
За кадром настоящей статьи - описание намоленных решений по организации скриптового стэндбая для standart edition и варианты настройки standby на том же сервере, что и продуктовая БД (что может быть востребовано для распараллеливания по нодам юниксового кластера)
Белонин С.С. (С), май 2007 года
(C) Белонин С.С., 2000-2022. Дата последней модификации страницы:2019-12-04 00:43:28
В данной статье мы рассмотрим основные вопросы связанные с использованием резервной БД Oracle, функционирующей в режиме standby. Прежде всего ответим на вопрос - зачем нужна резервная БД? Ее основное назначение - оперативно восстановить основную, также называемую первичной, БД с минимальными потерями информации. Переключить резервную БД в режим основной - это дело нескольких минут при соответствующей организации процессов администрирования баз данных.
Для надежности сервера и устройства хранения данных первичной и резервной баз данных следует разнести в физически изолированные помещения компании, и, даже здания настолько, насколько позволяет сеть компании. В этом случае мы сможем избежать непоправимых потерь даже в случаях таких фатальных событий, как пожары и теракты.
Создание резервной БД имеет смысл для динамичной БД находящейся в режиме ARCHIVELOG, и для экземпляра которой или запущены или создаются при необходимости процессы архивирования журнальных файлов БД. То есть и БД и экземпляр находятся в режиме ARCHIVELOG.
Самый простой слособ это создание копии сервера с использованием одной и той же версии ОС, системных библиотек, с одинаковыми точками установки программного обеспечения Oracle, и с одноименными файлами табличных БД, расположенными в идентичных точках файловой системы. При этом резервный сервер может быть значиткльно менее производительным, а резервный экземпляр Oracle может использовать минимальные ресурсы, поскольку в этом случае резервное копирование будет сводиться к простому применению изменний из журнальных файлов БД. В этом случае практически исчезает необходимость редактирования файлов инициализации, если они используются, за исключением параметров, связанных с выделением оперативной памяти сервера.
Это простейший вариант создания физической резервной БД. Можно также создать логическую резервную БД, в том числе кросс-платформенную. Но процесс восстановления логической БД намного более трудоемкий, так как изменения в БД осуществляются не обновлением блоков данных, а путем трансформации изменений в SQL запросы и выполнение этих запросов.
Итак, мы разработали архитектуру резервного сервера и установили необходимое ПО, в том числе путем простого переноса файлов. Теперь для создания резервной БД нужно выполнить простую процедуру. Остановим экземпляр Oracle с помощью команды SQL*Plus shutdown или shutdown immediate. На короткое время запустим экземпляр в режиме nomount, подмонтируем БД, не открывая ее и создадим резервный контрольный файл, после чего остановим экземпляр :
Теперь остановимся на вопросах управления резервной БД.
Резервная БД должна быть активирована. Для этого из копий основной БД удалим контрольные файлы, поместим на их места созданный резервный контрольный файл, выполним соответствующие изменения в файле инициализационных параметров. Отредактируем при необходимости другие параметры.
Запустим прослушиватель Oracle. Если используется ОС семейства ОС MS Windows, то с помощью утилиты oradim.exe при необходимости создадим службу, и запустим эту службу с помощью этой же утилиты. Заметим, что параметры указанной утилиты для различных версий Oracle разнятся, поэтому сначала имеет смысл запустить ее с вопросом - oradim.exe /? .
Запускаем командную оболочку SQL*Plus с помощью комады sqlplus.exe /nolog . В зависимости от ОС нам может понадобиться или же нет команда SQL*Plus startup nomount . В случае чего оболочка SQL*Plus проинформирует о том, что экземпляр уже запущен. Далее мы монтируем резерную БД,примерно такими директивами :
SQL> CONNECT sys/sys_pwd@standby1 AS SYSDBA
SQL> STARTUP NOMOUNT pfile=/oracle/admin/pfile/initSTBY.ora
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
Если все сделано должным образом, то наша резервная БД готова к использованию. Она может функционировать в 3 основных режимах (mode):
- Managed recovery mode
- Manual recovery mode
- Read-only mode
В управляемом режиме (Managed recovery mode), который правильнее назвать автоматическим, основной сервер передает через прослушиватель резервного сервера архивные журнальные файлы на резервный сервер в соответствующие каталоги, а резервный сервер их автоматически применяет. В версии Oracle9i эта процедура была гордо названа Data Guard. Вы можете с ней ознакомиться с соответствующей технологией по следующей ссылке. Однако использовать эту технологию я не рекомендую. Возможно процедура автоматической передачи файлов безусловно полезна, но насколько она эффективнее процедур передачи файлов, таких как cp или rcp на unix системах? Но для использования указанного режима есть более ощутимые препятствия.
Один раз пришлось столкнуться с ситуацией, когда в среде Windows 2000 Server программные ошибки, выведшие основную БД из строя, были полностью повторены и в резервной БД. И, если бы не было холодной копии резервной БД и соответствующих ей архивных журнальных файлов, то все данные были бы потеряны. Поэтому - незамедлительно применять архивный журнальный файл в резервной БД - неосмотрительно. Хотя в основной БД можно задать задержку на передачу архивных журнальных файлов в резервную БД, но эта задержка имеет технический характер. Она не учитывает возможность обнаружения фатальных событий в основной БД. Эти события обнаруживаются при активной работе с БД, то есть в рабочие дни. Поэтому применять изменения имеет смысл только по истечении рабочих суток, то есть со вторника по пятницу.
Следующий довод состоит в том, что резерную БД следует контролировать на работоспособность. Для этого ее надо переводить в режим доступности чтения из БД (Read-only mode). В этом режиме восстановление не возможно, поэтому за это время возникают пропуски в последовательности архивных журнальных файлов, и для восстановления последовательности, а соответственно возможности автоматического режима, необходимо применять ручной режим. Если БД динамична, журнальные файлы короткие, то восстановить автоматический режим станет затруднительно.
Поэтому ручной режим необходим. А автоматизировать его - это не сложная задача. В 1998 г. известный специалист В.Романчук из компании ЛВС, о профессиональных качествах которого я самого высокого мнения, автоматизировал по моей просьбе этот процесс путем написания скрипта для резервного сервера Oracle 7.3.4 , работающего по управлением ОС Soaris 2.6, объемом около 60 строк. Этот скрипт успешно работал несколько лет, на протяжении которых несколько раз сменился владелец компании.
Поэтому мы выбираем ручной режим, и дополняем его средствами автоматизации. В ручном режиме для восстановления Бд нужно скопировать очередную порцию архивных журнальных файлов в каталог, задаваемый переменной LOG_ARCHIVE_DEST_n (n целое от 1 до 5), или переменной LOG_ARCHIVE_DEST, и запустить восстановление с опцией AUTOMATIC
SQL> RECOVER AUTOMATIC STANDBY DATABASE
ORA-00308: cannot open archived log '/oracle/standby/standby_logs/arcr_1_540.arc'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Вы выбираете опцию CANCEL - и завершаете процесс восстановления.
Media recovery cancelled.
Если мы поместили файлы в другой каталог, то можно использовать команду RECOVER AUTOMATIC STANDBY DATABASE с опцией FROM 'путь_к_каталогу_с_файлами_журнала', напрмер
SQL> RECOVER FROM '/logs' STANDBY DATABASE;
В режиме чтения из резервной БД для многих запросов могут понадобиться сортировки, которые потребуют дисковых операций. Поэтому, возможно, потребуется создание временного табличного пространства с временным файлом
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
SQL> ALTER DATABASE OPEN READ ONLY;
SQL> CREATE TEMPORARY TABLESPACE tbs_1 TEMPFILE 'file_1.f' EXTENT MANAGEMENT LOCAL UNIFORM SIZE 2048M;
При переводе БД в режим standby под Oracle 9.2 проявилась следующая раздражающая ошибка
SGA initialization / DB open not complete even after 5 minutes, QMN0exiting
error 604 detected in background process
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-00604: error occurred at recursive SQL level 1
ORA-01219: database not open: queries allowed on fixed tables/views only
Dump file f:\database\bdump\bv_qmn0_хххх.trc
Она не сказывалась на функциональности. Резервная БД аккуратно применяла архивы журналов. Но плодились файлы дампов и не покидало чувство неудовлетворенности проделанной работой. Причина оказалась легко устранимой. Параметр экземпляра aq_tm_process был не равен 0 и экземпляр безуспешно пытался запустить соответствующие qmno процессы, которые требуют, чтобы БД была открыта. Решить задачу оказалось очень ппросто, примерно следующим образом
alter system set aq_tm_processes = 0 scope=both;
Но мы должны понимать, что тем сасмым мы еще более удаляемся от рабочего экземпляра. И при активации резервной БД следует вернуть первоначальное значение всем измененным параметрам.
Читайте также: