Standby oracle что это
Защита данных
(Data Guard, by Arup Nanda 
)
)Аруп Нанда, Член-директор коллегии Oracle ACE
Источник: сайт корпорации Oracle, серия статей «Oracle Database 11g: The Top New Features for DBAs and Developers» («Oracle Database 11g: Новые возможности для администраторов и разработчиков»), статья 22 http://www.oracle.com/technetwork/articles/sql/11g-dataguard-083323.html
В этой статье показывается, как механизм Active Data Guard (Активная Защита Данных) делает инвестиции в резервную среду осмысленными (worthwhile), как в результате применяя архивированных журналов и преобразования физической резервной базы данных в резервную снаршот-базу данных выполняются запросы в реальном времени, как появляется хост новой улучшенной инфраструктуры.
В Oracle Database 11g имеется так много расширенных технических возможностей опции Data Guard, что о них можно написать целую книгу. Но «нельзя объять необъятное» в небольшой статье. Поэтому здесь я расскажу только о тех фичах, которые считаю самыми интересными.
Упрощение создания Standby Database (резервной базы данных)
Давайте сначала создадим физическую резервную базу данных (physical standby database). В Oracle Database 11g этот процесс стал намного легче, используя только одну команду утилиты RMAN, которая всё нужное сделает. Ранее можно было использовать визард-интерфейс (wizard interface) опции Grid Control, чтобы построить Data Guard между двумя машинами. Но в этот момент нашего рассуждения механизм Oracle Enterprise Manager Grid Control 11g еще не доступен, а [встроенный] механизм Database Control не имеет визарда Data Guard. Но независимо от опыта использования команд языка SQL, установку среды Data Guard в Oracle Database 11g можно считать пустячным делом. Это настолько просто, что я покажу все нужные шаги прямо здесь.
Предположим, что имя основной (primary) базы данных prolin11 и она работает на сервере prolin1. Надо установить резервную (standby) базу данных на сервере prolin2. Имя экземпляра резервной базы данных должно быть pro11sb. Выполняем следующие действия:
Приведенные ниже две строки – это строки соединения RMAN с основным и резервным экземплярами:
Ну что, создание физической резервной базы данных облегчилось? Да, теперь это столь же просто как выполнение скрипта!
Опция Active Data Guard (Активная Защита Данных)
Одним из традиционных возражений на применение Data Guard с физической резервной базой данных является пассивность этой резервной базы. В Oracle Database 10g и ниже физическая резервная база данных могла открыться только_для_чтения (скажем, чтобы перенести на нее создание отчетов), но это было возможно только после остановки процесса восстановления. В прежних выпусках, если Data Guard — часть DR-решения, действительно нельзя позволить себе приостановить процесс восстановления для длительный период из-за опасности отставания. Таким образом, физическая резервная база данных была фактически бесполезна для любого применения только_для_чтения.
В Oracle Database 11g эта ситуация изменяется: можно открыть физическую резервную базу данных в режиме только_для_чтения и перезапустить процесс восстановления. Это означает, что можно продолжить обеспечение синхронизации с первичной базой, но одновременно можно также использовать резервную базу для производства отчетов. (Как и в предыдущих версиях можно также организовать резервное копирование, используя резервную базу.) Давайте посмотрим, как это делается.
Во-первых, отменим управляемое резервное восстановление:
Затем откроем базу данных в режиме только_для_чтения:
Вплоть до этой точки в pre-11g версиях процессы идентичны. А теперь, 11g-функция покажет свое преимущество: в то время, как резервная база данных открыта в режиме только_для_чтения, можно возобновить управляемый процесс восстановления.
Теперь резервная база переведена в режим управляемого восстановления с применением файлов системного журнала и в тоже время она открыта. Как в этом удостовериться? Довольно просто; проверим только максимальный порядковый номер журнала на первичной базе и сравним его с номером на резервной. На основной базе переключим файлы журнала и проверим максимальный порядковый номер файла журнала:
Переключение журнала произошло, но в это время резервная база была открыта в режиме только_для_чтения. Проверим на ней максимальный номер файла журнала:
Также 79, то же самое значение, что и на первичной базе. Это доказывает, что накат журнала продолжается. Ну, можно сказать, это просто подтверждает применение журналов; но будут при этом видимы изменения, происходящие на основной базе это время? Давайте проверим. На первичной базе создадим таблицу:
. затем сделаем несколько переключений журнальных файлов и подождем, пока эти журналы не применятся к резервной базе.. Затем её проверим:
Прекрасно! Таблица появилась в резервной базе и готова к запросам.
Помните, мы находились в состоянии Real Time Apply (RTA), в котором изменения, произошедшие на первичной базе немедленно появляются на резервной базе, если доступна сеть. Режим RTA не обязательно подразумевает Active Data Guard (ADG), но делает ADG еще более полезной, поскольку на резервной базе можно видеть последние изменения на базе первичной.
Однако, внимательный читатель может быть обеспокоен проблемами безопасности. База данных находится в режиме только_для_чтения, следовательно, ничто не может быть в нее записано. Но если параметр audit_trail будет установлен в значение DB на первичной базе (значение по умолчанию в Oracle Database 11g), то оно же будет таким же на резервной базе, но данные audit_trail не могут быть записаны в базу данных — она же только_для_чтения. Так куда поступают эти данные?
Найдем строку, которая беззвучно присутствует в журнале регистрации событий (alert log):
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
[Параметр инициализации AUDIT_TRAIL изменяется на OS, поскольку значение DB НЕ совместимо для базы данных, открытой только_для_чтения]
Ага! Сбор аудит-данных (audit trails) не останавливается; он автоматически переводится в файлы OS, когда база данных открыта. Когда активируется резервная база данных, данные audit_trail автоматически удаляются из DB.
Snapshot Standby
(Резервная снапшот- база данных)
Вот типичный сценарий: Предположим, что новое приложение развертывается на базе данных, и вы задаетесь вопросом, какое воздействие оно окажет на производительность базы данных. В Oracle Database 11g имеется усовершенствованный инструмент (Database Replay ), который захватывает SQL-предложения и воспроизводит их, но есть один нюанс: чтобы увидеть производительность, надо их выполнить. Эти запросы приходят из системы тестирования, но их воспроизведение на производственной системе не целесообразно. Во-первых, приложение на ней может не развернуться; а во-вторых, даже если приложение все-таки развернуто, нельзя позволить себе запустить приложение, производящее изменения в чужих таблицах. Так, что же нужно сделать, чтобы определить воздействие приложения?
Правильный ответ дает Oracle Database 11g, в которой физическая резервная база данных (physical standby database) может быть временно преобразована в резервную снапшот- базу данных (Snapshot Standby Database). В этом режиме можно выполнить приложение, которое изменяет множество таблиц, и определить его эффективность. Как только выявлено воздействие приложения, можно восстановить резервную базу данных в ее нормальное состояние. Это выполняется с использованием точки восстановления в базе данных, применяя Flashback-функциональность базы данных, чтобы восстановить ретроспективное состояние в определенной точке, а затем отменить все изменения. Давайте видеть, как это делается.
Во-первых, запустим восстановление на резервном устройстве, если это уже не происходит:
Ждем, пока восстановление не использует несколько файлов системного журнала. Затем остановим восстановление.
В этой точке можно создать снапшот-резервную базу данных. Необходимо знать и помнить, что это действие включает ретроспективную Flashback-журнализацию. Поэтому если область флэш-восстановления не была сконфигурирована, будет получено следующее сообщение:
Чтобы избежать этого, необходимо создать область флэш-восстановления. Если это ещё не сделано, не волнуйтесь, её можно создать прямо сейчас:
Теперь, когда формальности выполнены, можно преобразовать эту резервную базу данных в спапшот-резервную базу, используя простую команду:
Теперь перезапустим базу данных:
Теперь база данных открыта для операций чтения-записи:
Теперь закрываем базу, затем открываем ее в режиме mount и стартуем процесс «managed recovery» (управляемое восстановление):
Старт процесса управляемого восстановления:
Теперь резервная база данных вернулась в режим управляемого восстановления (managed recovery mode). Само собой разумеется, что когда база была в режиме снапшот, архивные журналы, полученные от первичной базы данных, к ней не применялись. Теперь они будут задействованы, но это может занять некоторое время прежде, чем резервная база полностью нагонит первичную.
Снапшот-резервная база данных позволяет использовать резервную базу данных для точного предсказания последствий изменений в производственной базе прежде, чем изменения были сделаны. Но и не только это. Есть и другое преимущество. Помните, мы использовали RTA, когда изменения в первичной базе данных немедленно появляются на резервной базе, если, конечно, доступна сеть? Ну, а если кто-то сделает ошибку на основной базе данных, например, выполнив массовое обновление или изменение некоего кода? В предыдущих версиях мы сознательно использовали задержку [обновления] резервной базы данных, чтобы задержать распространение таких ошибок на резервную базу. Но такая задержка также означает, что резервная база не может быть одномоментно активирована или использоваться в качестве активной копии производственной базы.
Этого больше нет. Поскольку можно ретроспективно откатить базу данных во времени, нет надобности сохранить задержку. Если возникает проблема, всегда можно ретроспективно вернуться к предыдущему состоянию.
Преобразование физической резервной базы в логическую
(Conversion from Physical to Logical Standby)
Теперь можно легко преобразовать физическую резервную базу данных в логическую. Это выполняется следующей последовательностью действий:
Теперь логическая резервная база данных полностью готова к эксплуатации! Но как только физическая резервная база преобразовывается в логическую, обратное преобразование в физическую невозможно, если только не воспользоваться специальной фразой («keep identity»), описанный в разделе ниже.
Rolling Upgrade
(Накатываемые обновления)
Не секрет, что одной из болевых точек в деятельности администратора базы данных является необходимость прерывать работу базы данных на разумные по длительности периоды времени, чтобы выполнить обновления. В Oracle Database 11g это стало значительно легче при наличии резервной базы данных какого-либо типа посредством использования процесса накатывания обновлений:
Если имеется логическая резервная база, все довольно просто, поскольку такая резервная база непосредственно применяет SQL-предложения, поступающие из первичной базы, и обновление может легко быть на ней сделано. Можно остановить восстановление, обновить резервную базу, затем продолжать восстановление, чтобы нагнать первичную, а затем переключить между собой резервную и первичную базы. Затем сделать обновление на базе данных, которая была первичной, а стала резервной логической, и, наконец, обратно поменять роли этих баз так, чтобы первичной снова стала обновленная исходная первичная база. А обновленная резервная база, побыв некоторое время первичной базой, снова резервной.
Однако из-за простоты использования и управления многие резервные базы данных строятся как физические. Если резервная база не логическая, а физическая, то с незначительными различиями перечисленные выше действия в большинстве своем остаются теми же самыми: нужно временно преобразовать резервную базу в логическую, а затем преобразовать её обратно в физическую. Здесь ключевое слово «временно» — не навсегда! Поэтому надо воспользоваться командой конвертации с новой фразой «keep identity» («сохранение идентификационных данных»), как показано ниже:
Другие усовершенствования
(Other Improvements)
Есть ещё несколько существенных усовершенствований функциональности Data Guard, например:
Сжатие redo-журналов
(Redo Compression)
В Oracle Database 11g можно сжать поток redo-файлов, который идет на резервный сервер через SQL*Net, если установить параметр компрессии в значение true. Это работает только для журнальных файлов, которые посылаются для ликвидации разрыва связи. Вот команда, которую можно использовать, чтобы включить сжатие в нашем примере
Сетевой тайм-аут
Net Timeout
Механизм Data Guard отправляет redo-данные на резервный сервер, где соединяется с экземпляром базы данных. Если этот экземпляр вовремя не отвечает, служба передачи журналов ждёт в течение заданного времени ожидания, а затем отказывается от соединения. Значение тайм-аута может быть установлено в Oracle Database параметром net_timeout. В режиме максимальной защищенности (maximum protection) служба передачи журналов повторит попытку 20 раз перед отказом.
Но сначала необходимо узнать, как много в настоящий момент имеется задержанных к передаче журналов. Новое представление v$redo_dest_resp_histogram показывает это время как гистограмму:
Представление показывает, сколько времени было потрачено на отгрузку данного блока. Если посмотреть на данные из этого представления после нескольких дней работы, то можно вычислить более приемлемое значение тайм-аута по сравнению с имеющимся. Затем можно установить значение тайм-аута:
Возвращаясь к нашему примеру отметим в значении параметра элемент «net_timeout=20».
Динамически Изменяемые Параметры
(Dynamically Alterable Parameters)
Отметим столбец DYNAMIC, который показывает, изменяемо ли значение динамично или нет. Почти все параметры являются динамичными. Например, чтобы изменить параметр APPLY_SERVERS, не останавливая резервную базу данных, можно ввести:
Это установит значение параметра apply_servers равным 2, что может быть сделано без остановки резервной базы.
Таблица Событий SQL Apply
SQL Apply Event Table
В Oracle Database 10g события, связанные с SQL Apply? записываются в аварийный журнал, что не очень эффективно, так как можно написать скрипты, которые проверят предупреждения и создадут отчеты. В Oracle Database 11g события по умолчанию записываются в новую таблицу LOGSTDBY$EVENTS в схеме SYSTEM. Вот пример запроса:
По многим причинам очень полезно хранить события в таблице; главное, легче управлять и отчитываться. Но иногда также полезно видеть в аварийном журнале события об ошибках и сообщения, особенно, если имеется некий мониторинговый инструмент для сканирования аварийного журнала на предмет поиска ошибок и сообщений. Можно поднять логическую резервную базу данных и применить параметр «event_log_dest» в значении «DEST_ALL»:
Это можно сделать динамически, и теперь события попадут и в таблицу, и в журнал регистрации событий (alert log – также аварийный журнал базы данных). После выполнения этой команды можно проверить журнал событий; предлагается альтернатива выбора наименьшего из этих двух строк и возможно большего количества событий Apply SQL:
Заключение
Во-первых, было показано, как тривиально можно создать физическую резервную базу данных из активной основной базы данных. Кроме того, показано, как легко можно преобразовать эту физическую резервную базу в логическую. Самое большое преимущество заключается в том, что резервная база может теперь продуктивно использоваться, обеспечивая некоторые бизнес-действия. Опция Active Data Guard позволяет открывать резервные базы данных для выполнения запросов с одновременным применением архивных журналов. Резервная база данных типа снапшот позволяет выполнять на базе производственные задачи с последующим возвратом к некой точке в прошлом, с которой возобновляется нормальный процесс управляемого восстановления. Эти две возможности позволяют повысить эффективность задействования резервного сервера, что должно быть существенным поводом для применения продвинутых опций Oracle Database 11g R2.
Standby 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 ;
2 Getting Started with Oracle Data Guard
Considerations when getting started with Oracle Data Guard are discussed in the following topics:
2.1 Standby Database Types
A standby database is a transactionally consistent copy of an Oracle production database that is initially created from a backup copy of the primary database. Once the standby database is created and configured, Oracle Data Guard automatically maintains the standby database by transmitting primary database redo data to the standby system, where the redo data is applied to the standby database.
A standby database can be one of these types: a physical standby database, a logical standby database, or a snapshot standby database. If needed, either a physical or a logical standby database can assume the role of the primary database and take over production processing. An Oracle Data Guard configuration can include any combination of these types of standby databases.
2.1.1 Physical Standby Databases
A physical standby database is an exact, block-for-block copy of a primary database. A physical standby is maintained as an exact copy through a process called Redo Apply, in which redo data received from a primary database is continuously applied to a physical standby database using the database recovery mechanisms.
A physical standby database can be opened for read-only access and used to offload queries from a primary database. If a license for the Oracle Active Data Guard option has been purchased, Redo Apply can be active while the physical standby database is open, thus allowing queries to return results that are identical to what would be returned from the primary database. This capability is known as the real-time query feature.
Oracle Database Licensing Information for more information about Oracle Active Data Guard
Benefits of a Physical Standby Database
A physical standby database provides the following benefits:
Disaster recovery and high availability
A physical standby database is a robust and efficient disaster recovery and high availability solution. Easy-to-manage switchover and failover capabilities allow easy role reversals between primary and physical standby databases, minimizing the downtime of the primary database for planned and unplanned outages.
A physical standby database can prevent data loss, even in the face of unforeseen disasters. A physical standby database supports all datatypes, and all DDL and DML operations that the primary database can support. It also provides a safeguard against data corruptions and user errors. Storage level physical corruptions on the primary database are not propagated to a standby database. Similarly, logical corruptions or user errors that would otherwise cause data loss can be easily resolved.
Reduction in primary database workload
Oracle Recovery Manager (RMAN) can use a physical standby database to off-load backups from a primary database, saving valuable CPU and I/O cycles.
A physical standby database can also be queried while Redo Apply is active, which allows queries to be offloaded from the primary to a physical standby, further reducing the primary workload.
The Redo Apply technology used by a physical standby database is the most efficient mechanism for keeping a standby database updated with changes being made at a primary database because it applies changes using low-level recovery mechanisms which bypass all SQL level code layers.
2.1.2 Logical Standby Databases
A logical standby database is initially created as an identical copy of the primary database, but it later can be altered to have a different structure. The logical standby database is updated by executing SQL statements. The flexibility of a logical standby database lets you upgrade Oracle Database software (patch sets and new Oracle Database releases) and perform other database maintenance in rolling fashion with almost no downtime. From Oracle Database 11 g onward, the transient logical database rolling upgrade process can also be used with existing physical standby databases.
Oracle Data Guard automatically applies information from the archived redo log file or standby redo log file to the logical standby database by transforming the data in the log files into SQL statements and then executing the SQL statements on the logical standby database. Because the logical standby database is updated using SQL statements, it must remain open. Although the logical standby database is opened in read/write mode, its target tables for the regenerated SQL are available only for read-only operations. While those tables are being updated, they can be used simultaneously for other tasks such as reporting, summations, and queries.
A logical standby database has some restrictions on datatypes, types of tables, and types of DDL and DML operations. See Data Type and DDL Support on a Logical Standby Database for information on data type and DDL support on logical standby databases.
Benefits of a Logical Standby Database
A logical standby database is ideal for high availability (HA) while still offering data recovery (DR) benefits. Compared to a physical standby database, a logical standby database provides significant additional HA benefits:
Minimizing downtime on software upgrades
A logical standby database is ideal for upgrading an Oracle Data Guard configuration in a rolling fashion. Logical standby can be used to greatly reduce downtime associated with applying patchsets and new software releases. A logical standby can be upgraded to the new release and then switched over to become the active primary. This allows full availability while the old primary is converted to a logical standby and the patchset is applied. Logical standbys provide the underlying platform for the DBMS_ROLLING PL/SQL package, which is available as of Oracle Database 12 c Release 1 (12.1). The DBMS_ROLLING package provides functionality that allows you to make your Oracle Data Guard configuration highly available in the context of rolling upgrades and other storage reorganization.
Support for reporting and decision support requirements
A key benefit of logical standby is that significant auxiliary structures can be created to optimize the reporting workload; structures that could have a prohibitive impact on the primary’s transactional response time. A logical standby can have its data physically reorganized into a different storage type with different partitioning, have many different indexes, have on-demand refresh materialized views created and maintained, and can be used to drive the creation of data cubes and other OLAP data views. However, a logical standby database does not allow for any transformation of your data (such as replicating only a subset of columns or allowing additional columns on user tables). For those types of reporting activities, Oracle GoldenGate is Oracle’s preferred solution.
2.1.3 Snapshot Standby Databases
A snapshot standby database is a type of updatable standby database that provides full data protection for a primary database. A snapshot standby database receives and archives, but does not apply, redo data from its primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.
A snapshot standby database diverges from its primary database over time because redo data from the primary database is not applied as it is received. Local updates to the snapshot standby database cause additional divergence. The data in the primary database is fully protected however, because a snapshot standby can be converted back into a physical standby database at any time, and the redo data received from the primary is then applied.
Benefits of a Snapshot Standby Database
A snapshot standby database is a fully updatable standby database that provides disaster recovery and data protection benefits that are similar to those of a physical standby database. Snapshot standby databases are best used in scenarios where the benefit of having a temporary, updatable snapshot of the primary database justifies the increased time to recover from primary database failures.
The benefits of using a snapshot standby database include the following:
It provides an exact replica of a production database for development and testing purposes, while maintaining data protection at all times. You can use the Oracle Real Application Testing option to capture primary database workload and then replay it for test purposes on the snapshot standby.
It can be easily refreshed to contain current production data by converting to a physical standby and resynchronizing.
The ability to create a snapshot standby, test, resynchronize with production, and then again create a snapshot standby and test, is a cycle that can be repeated as often as desired. The same process can be used to easily create and regularly update a snapshot standby for reporting purposes where read/write access to data is required.
Oracle Database Testing Guide for more information about Oracle Real Application Testing and the license required to use it
2.2 User Interfaces for Administering Oracle Data Guard Configurations
You can use the following interfaces to configure, implement, and manage an Oracle Data Guard configuration:
Oracle Enterprise Manager Cloud Control
Oracle Enterprise Manager Cloud Control provides a GUI interface for the Oracle Data Guard broker that automates many of the tasks involved in creating, configuring, and monitoring an Oracle Data Guard environment. See the Oracle Enterprise Manager Cloud Control online Help for information about the GUI and its wizards.
SQL*Plus Command-line interface
Several SQL*Plus statements use the STANDBY keyword to specify operations on a standby database. Other SQL statements do not include standby-specific syntax, but they are useful for performing operations on a standby database. See SQL Statements Relevant to Oracle Data Guard for a list of the relevant statements.
Several initialization parameters are used to define the Oracle Data Guard environment. See Initialization Parameters for a list of the relevant initialization parameters.
Oracle Data Guard broker command-line interface (DGMGRL)
The DGMGRL command-line interface is an alternative to using Oracle Enterprise Manager Cloud Control. The DGMGRL command-line interface is useful if you want to use the broker to manage an Oracle Data Guard configuration from batch programs or scripts. See Oracle Data Guard Broker for complete information.
2.3 Oracle Data Guard Operational Prerequisites
The following sections describe operational requirements for using Oracle Data Guard:
2.3.1 Hardware and Operating System Requirements
Note 413484.1 discusses mixed-platform support and restrictions for physical standbys.
Note 1085687.1 discusses mixed-platform support and restrictions for logical standbys.
The same release of Oracle Database Enterprise Edition must be installed on the primary database and all standby databases, except during rolling database upgrades using logical or transient logical standby databases.
Using SQL Apply to Upgrade the Oracle Database for information about rolling database upgrades
2.3.2 Oracle Software Requirements
The following list describes Oracle software requirements for using Oracle Data Guard:
Oracle Data Guard is available only as a feature of Oracle Database Enterprise Edition. It is not available with Oracle Database Standard Edition.
It is possible to si mulate a standby database environment with databases running Oracle Database S tandard Edition. You can do this by manually transferring archived redo log files using an operating system copy utility or using custom scripts that periodically send archived redo log files from one database to the other, registering them, and using media recovery to roll forward the copy of the database at the disaster recovery site. Such a configuration does not provide the ease-of-use, manageability, performance, and disaster-recovery capabilities available with Oracle Data Guard.
Using Oracle Data Guard SQL Apply, you can perform a rolling upgrade of the Oracle database software from patch set release n (minimally, this must be release 10.1.0.3) to any higher versioned patch set or major version release. During a rolling upgrade, you can run different releases of the Oracle database on the primary and l ogical standby databases while you upgrade them, one at a time. For complete information, see Using SQL Apply to Upgrade the Oracle Database and the ReadMe file for the applicable Oracle Database 10 g patch set release.
The COMPATIBLE database initialization parameter must be set to the same value on all databases in an Oracle Data Guard configuration, except when using a logical standby database, which can have a higher COMPATIBLE setting than the primary database.
The primary database must run in ARCHIVELOG mode. See Oracle Database Administrator’s Guide for more information.
The primary database can be a single instance database or an Oracle Real Application Clusters (Oracle RAC) database. The standby databases can be single instance databases or Oracle RAC databases, and these standby databases can be a mix of physical, logical, and snapshot types.
Each primary database and standby database must have its own control file.
If a standby database is located on the same system as the primary database, the archival directories for the standby database must use a different directory structure than the primary database. Otherwise, the standby database may overwrite the primary database files.
To protect against unlogged direct writes in the primary database that cannot be propagated to the standby database, turn on FORCE LOGGING at the primary database before performing data file backups for standby creation. Keep the database in FORCE LOGGING mode as long as the standby database is required.
The user accounts you use to manage the primary and standby database instances must have either the SYSDG or SYSDBA administrative privilege.
For operational simplicity, Oracle recommends that when you set up Oracle Automatic Storage Management (Oracle ASM) and Oracle Managed Files (OMF) in an Oracle Data Guard configuration that you set it up symmetrically on the primary and standby database(s). If any database in the Oracle Data Guard configuration uses Oracle ASM, OMF, or both, then every database in the configuration should use Oracle ASM, OMF, or both, respectively, unless you are purposely implementing a mixed configuration for migration or maintenance purposes. See the scenario in Creating a Standby Database That Uses OMF or Oracle ASM for more information.
Because some applications that perform updates involving time-based data cannot handle data entered from multiple time zones, consider setting the time zone for the primary and remote standby systems to be the same to ensure the chronological ordering of records is maintained after a role transition.
2.4 Standby Database Directory Structure Considerations
The directory structure of the various standby databases is important because it determines the path names for the standby data files, archived redo log files, and standby redo log files. If possible, the data files, log files, and control files on the primary and standby systems should have the same names and path names and use Optimal Flexible Architecture (OFA) naming conventions. The archival directories on the standby database should also be identical between sites, including size and structure. This strategy allows other operations such as backups, switchovers, and failovers to execute the same set of steps, reducing the maintenance complexity.
Your operating system-specific Oracle documentation for more information about Optimal Flexible Architecture (OFA)
Otherwise, you must set the filename conversion parameters (as shown in Table 2-1) or rename the data file. Nevertheless, if you need to use a system with a different directory structure or place the standby and primary databases on the same system, you can do so with a minimum of extra administration.
The three basic configuration options are illustrated in Figure 2-1. These include:
If you have a standby database on the same system as the primary database, you must use a different directory structure. Otherwise, the standby database attempts to overwrite the primary database files.
For operational simplicity, Oracle recommends that when you set up Oracle Automatic Storage Management (Oracle ASM) and Oracle Managed Files (OMF) in an Oracle Data Guard configuration that you set it up symmetrically on the primary and standby database(s). If any database in the Oracle Data Guard configuration uses Oracle ASM, OMF, or both, then every database in the configuration should use Oracle ASM, OMF, or both, respectively, unless you are purposely implementing a mixed configuration for migration or maintenance purposes. See the scenario in Creating a Standby Database That Uses OMF or Oracle ASM for more information.
Figure 2-1 Possible Standby Configurations
Description of «Figure 2-1 Possible Standby Configurations»
Table 2-1 describes possible configurations of primary and standby databases and the consequences of each.
Table 2-1 Standby Database Location and Directory Options