stand by oracle что это
Stand by oracle что это
Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы
Авторская площадка «Наши орбиты» состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом
В контексте реализации отказоустойчивых решений основными задачами являются обеспечение быстрого времени восстановления при возникновении нештатной ситуации (аварии) и обеспечение минимальной потери или отсутствия потери данных. Казалось бы СУБД Oracle обеспечивает создание резервов данных (бэкапов) и поддерживает создание архивных журнолов, чего, в случае полного краха сервера, достаточно для восстановления данных и «подката вперёд» истории изменений базы. Однако, во-первых, это может потребовать довольно много времени и, во-вторых, практически всегда означает потерю части данных, не вошедших в архивные журналы
Возможны два варианта «ручного» стэндбая. В одном случае резервная БД запускается в режиме монтирования обычного контрольного файла с периодическим подкатом архивных журналов командой «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 навык организации ручного стэндбая может быть полезен. Важно, что возможность потери транзакций сильно связан с особенностями организации прикладного решения, использующего СУБД. В частности возможность повторного ввода данных последних операций операционистами банка может сделать такое решение предпочтительным и в задачах автоматизации банковской сферы, и автор имел практический опыт администрирования таких решений
Дополнительными возможностями Data Guard являются полуавтоматическая смена ролей, обеспечивающая переключение основной копии БД и standby копии между собой, что востребовано для сервисных задач (впрочем, это вполне несложно делается руками при использовании «ручного» standby). Кроме того возможен режим работы Data Guard, при котором данные в standby базу подкатываются не из архивных, но из оперативных журналов в режиме реального времени, что позволяет минимизировать возможную потерю данных, но делает конструкцию менее надёжной, ибо любой сбой на standby приводит к недоступности и основной базы, что связано с необходимостью синхронного наката данных оперативных журналов на standby в этом режиме. Синхронный standby подразуменвае установку резервного сервера в непосредственной близости к основному, что обусловлено довольно невысокой надёжностью и временем отклика разделяющих площадки каналов
Таким образом для SE редакции можно довольно просто настроить standby в ручном режиме, сопоставимым с таким же режимом для СУБД PostgreeSQL. Это будет надёжное и малобюджетное решение. Для пользователей EE редакции появляется возможность использования Data Guard, который в общем случае будет повторять функциональность и характеристики «ручного» standby. Важно, что при использовании в организации редакций SE и EE можно остановиться на ручном standby, который вполне будет работать и для EE редакции СУБД. Это позволит не разводить зоопарк решений. С другой стороны при необходимости использования дополнительного функционала от Data Guard последний довольно просто настраивается, что будет показано в следующих разделах настоящего обзора
Ещё одним тонким моментом является увязка механизмов резервного копирования данных и standby для исключения ситуации, когда архивные журналы уходят в резервную копию и более недоступны по основному месту расположения, но, в то же время они ещё не перенесены на standby сервер, например в силу проблем с каналами связи с удалённой площадкой, на которой размещён standby. Это особенно актуально для «ручного» режима организации standby
организация Standby посредством Data guard
Можно добавить, что в таком ручном варианте реализация Standby для Oracle вполне сопоставима с реализацией Standby для PostgreeSQL (детально описанный в документации по PostgreeSQL), что лишний раз заставляет задуматься о целесообразности использования дорогостоящего Oracle там, где можно использовать более дешевый, но вполне качественный аналог
В случае же, если у вас Enterprise редакция, вы можете использовать встроенный механизм построения Standby с разнообразным дополнительным функционалом (таким, как временная смена ролей для основной базы и базы standby). Итак, при использовании Data Guard последовательность организации и использования standby выглядит так:
P.S. Проверить работоспособность можно по alert логам, а также попробовать попереключать журналы на master базе командами
ALTER SYSTEM SWITCH LOGFILE
ARCHIVE LOG ALL
и сравнив вывод команды
select SEQUENCE#,FIRST_TIME,NEXT_TIME,ARCHIVED,APPLIED,creator from v$archived_log where status = ‘A’ order by sequence# ;
— режим switchover позволяет резво «рокировать» роли для тех. работ на основной базе и обратно
— потом на 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 ;
и потом обратный переход
— выверить, что накачено максимальное количество журналов
select from v$archive_gap
select from v$archived_log
при необходимости и доступности перенести недостающие журналы и
зарегистрировать их командой
alter database register physical logfile ‘. ‘ ;
— тушится автонакатывание
alter database recover managed standby database finish ;
или
alter database recover managed standby database finish skip standby logfile ;
Stand by oracle что это
Для надежности сервера и устройства хранения данных первичной и резервной баз данных следует разнести в физически изолированные помещения компании, и, даже здания настолько, насколько позволяет сеть компании. В этом случае мы сможем избежать непоправимых потерь даже в случаях таких фатальных событий, как пожары и теракты.
Создание резервной БД имеет смысл для динамичной БД находящейся в режиме ARCHIVELOG, и для экземпляра которой или запущены или создаются при необходимости процессы архивирования журнальных файлов БД. То есть и БД и экземпляр находятся в режиме ARCHIVELOG.
Самый простой слособ это создание копии сервера с использованием одной и той же версии ОС, системных библиотек, с одинаковыми точками установки программного обеспечения Oracle, и с одноименными файлами табличных БД, расположенными в идентичных точках файловой системы. При этом резервный сервер может быть значиткльно менее производительным, а резервный экземпляр Oracle может использовать минимальные ресурсы, поскольку в этом случае резервное копирование будет сводиться к простому применению изменний из журнальных файлов БД. В этом случае практически исчезает необходимость редактирования файлов инициализации, если они используются, за исключением параметров, связанных с выделением оперативной памяти сервера.
Это простейший вариант создания физической резервной БД. Можно также создать логическую резервную БД, в том числе кросс-платформенную. Но процесс восстановления логической БД намного более трудоемкий, так как изменения в БД осуществляются не обновлением блоков данных, а путем трансформации изменений в SQL запросы и выполнение этих запросов.
Итак, мы разработали архитектуру резервного сервера и установили необходимое ПО, в том числе путем простого переноса файлов. Теперь для создания резервной БД нужно выполнить простую процедуру. Остановим экземпляр Oracle с помощью команды SQL*Plus shutdown или shutdown immediate. На короткое время запустим экземпляр в режиме nomount, подмонтируем БД, не открывая ее и создадим резервный контрольный файл, после чего остановим экземпляр :
Теперь выполняем холодное копирование файлов основной БД в соответствующие каталоги резервного сервера. И можно запускать основную БД. С этого момента о холодном резервном копировании файлов основной БД можно забыть, поскольку эту операцию можно будет выполнять на резервном сервере. Тем не менее рекомендую делать холодное резервное копирование основной БД по крайней мере раз в два месяца. Здесь мы ищем компромисс между надежностью и оперативностью. Резервная БД может накопить ошибки связанные с копированием и применением архивных файлов журнала, поэтому следует оставить возможность их исправить за счет применения последних архивных файлов журнала к последней холодной копии основной БД. Поэтому и архивные файлы журнала следует хранить за все время после создания последней холодной копии основной БД.
Теперь остановимся на вопросах управления резервной БД.
Резервная БД должна быть активирована. Для этого из копий основной БД удалим контрольные файлы, поместим на их места созданный резервный контрольный файл, выполним соответствующие изменения в файле инициализационных параметров. Отредактируем при необходимости другие параметры.
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), который правильнее назвать автоматическим, основной сервер передает через прослушиватель резервного сервера архивные журнальные файлы на резервный сервер в соответствующие каталоги, а резервный сервер их автоматически применяет. В версии Oracle9i эта процедура была гордо названа Data Guard. Вы можете с ней ознакомиться с соответствующей технологией по следующей ссылке. Однако использовать эту технологию я не рекомендую. Возможно процедура автоматической передачи файлов безусловно полезна, но насколько она эффективнее процедур передачи файлов, таких как cp или rcp на unix системах? Но для использования указанного режима есть более ощутимые препятствия.
Следующий довод состоит в том, что резерную БД следует контролировать на работоспособность. Для этого ее надо переводить в режим доступности чтения из БД (Read-only mode). В этом режиме восстановление не возможно, поэтому за это время возникают пропуски в последовательности архивных журнальных файлов, и для восстановления последовательности, а соответственно возможности автоматического режима, необходимо применять ручной режим. Если БД динамична, журнальные файлы короткие, то восстановить автоматический режим станет затруднительно.
Поэтому мы выбираем ручной режим, и дополняем его средствами автоматизации. В ручном режиме для восстановления Бд нужно скопировать очередную порцию архивных журнальных файлов в каталог, задаваемый переменной LOG_ARCHIVE_DEST_n (n целое от 1 до 5), или переменной LOG_ARCHIVE_DEST, и запустить восстановление с опцией AUTOMATIC
SQL> RECOVER AUTOMATIC STANDBY DATABASE
После применения пригодных файло Oracle покажет имя журнала, который в каталоге отсутствует, например, вы можете увидеть следующие сообщения SQL*Plus:
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
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;
Но мы должны понимать, что тем сасмым мы еще более удаляемся от рабочего экземпляра. И при активации резервной БД следует вернуть первоначальное значение всем измененным параметрам.
Построение отказоустойчивой системы с помощью Oracle Physical Standby
Построение отказоустойчивой системы с помощью Oracle Physical StandbyАрхив номеров / 2007 / Выпуск №7 (56) / Построение отказоустойчивой системы с помощью Oracle Physical Standby
Сергей Косько
