Standby oracle что это

Обновлено: 06.07.2024

Oracle Data Guard: Развертывание физического Standby средствами Oracle Database

Технология Oracle Data Guard предалагает решение для обеспечения высокой доступности, повышенной производительности и автоматического преодоления последствий сбоя.

Изменения в основной базе данных могут быть переданы в резернвые базы данных с гарантией отсутствия потерь данных в процессе передачи.

-------------------------
Как установить физический Oracle DataGuard, смотрите лучше здесь.

Поддерживаются 2 типа резервных баз данных - с осуществлением физического и логическог резервирования.
Физическая резервная база данных содержит те же самые структуры, что и основная. Логическая - может иметь другие внутренние структуры (например, дополнительные индексы, используемые для генерации отчетов). Синхронизация основной базы данных с резервными осуществляется путем передачи журнальных данных через SQL - операторы, выполняемые над резервной базой данных.

Физическая резервная база данных является поблочной копией первичной базы данных. Во время восстановления в аварийных ситуациях, резервная база даных в точности похожа на основную базу данных.

Логическая база данных - используется для подготовки отчетов (при подготовке отчетов требуются существенные ресурсы системы). В этом случае резерная база данных открывается только для чтения и пользователи, которым необходимо сформировать отчеты работают с ней. При этом основная база данных продолжает работать на прием данных от операторов.

Ниже рассматривается вариант создания основной (primary) и резервной (standby) БД ORACLE и выполнения переключении (switchover) с основной на резервную БД.

Организация резервной (standby) БД ORACLE - предназначено для обеспечения наименьшего временем простоя и наименьшей потери данных для БД, в случае проведения профилактических работ или выхода из строя одного из серверов БД.

В данном примере мы рассмотрим способ создания physical standby c помощью RMAN.

В блогах нашего сообщества вы можете найти приемы резервного копирования позволят защитить базу данных от неожиданных отказов дисков и прочих неполадок с оборудованием. Наличие хорошо спроектированной системы с зеркальным отображением дисков или сконфигурированным массивом RAID обеспечит достаточную степень избыточности для сохранения работоспособности базы данных после обычных аварий. Однако даже самые продуманные схемы резервного копирования не могут гарантировать высокой готовности системы. Любая серьезная авария способна легко вывести информационные ресурсы организации из строя и стать причиной длительных простоев в предоставлении услуг. Для защиты от подобных событий требуется иметь в распоряжении не только обычные системы резервного копирования, но и целую стратегию по обеспечению высокой готовности.

Системы с высокой готовностью

Система с высокой степенью готовности будет обеспечивать практически непрерывную доступность данных при возникновении аварий практически любого рода. Главным способом для обеспечения такой высокой степени готовности является применение нескольких систем данных с разными архитектурами. Oracle предлагает в этом отношении несколько вариантов.

Технология Oracle Data Guard и резервные базы данных часто применяются для обеспечения возможности восстановления после аварий, защиты данных и высокой степени готовности. Поэтому давайте вкратце рассмотрим, как они работают.

Технология Oracle Data Guard и резервные базы данных

Функция резервных баз данных предлагается Oracle уже много лет. Технология Oracle Data Guard представляет собой уровень управления и мониторинга, посредством которого осуществляется обслуживание резервных баз данных. Резервные базы данных поддерживаются в актуальном состоянии, благодаря постоянной передаче изменений с главного сервера.

В случае аварии резервная база данных активизируется и переводится в оперативный режим для выполнения роли главной базы данных. Помимо защиты от полного разрушения главной базы данных, резервная база данных может также применяться и для генерации отчетов.

Базы данных, обслуживаемые в рамках конфигурации Oracle Data Guard, могут находиться как в одной и той же локальной сети (LAN), так и в более широкой глобальной сети (WAN). Резервные базы данных, находящиеся в локальной сети, обеспечивают возможность более быстрого восстановления после обычных неполадок, а резервные базы данных, находящиеся в глобальной сети, лучше защищают от катастрофических аварий, охватывающих весь центр данных или целые локальные сайты. Конфигурировать можно одну главную базу данных и несколько резервных. За счет выбора правильного уровня защиты при настройке резервных баз данных время простоя можно сводить до менее чем одной минуты. Ниже приведен краткий перечень тех многочисленных преимуществ, которые дает использование технологии Oracle Data Guard и резервных баз данных:

Высокая степень готовности.
Защита от аварий.
Защита от физического повреждения данных.
Защита от ошибок пользователей.
Возможности передачи управления (failover) или переключения (switchover), которые могут применяться как для запланированного, так и незапланированного переключения производственных и резервных баз данных.
Географическое разделение главных (первичных) и второстепенных (вторичных) серверов посредством Oracle Net.

Для оказания помощи в создании и управлении конфигурациями Oracle Data Guard компания Oracle предоставляет замечательное программное обеспечение Oracle Data Guard Broker (Брокер защиты данных Oracle). Оно способно поддерживать вплоть до десяти баз данных сразу (одну главную и девять резервных) и управлять выполнением административных операций, наподобие применения журналов, их переноса и передачи управления или переключения с главной базы данных на второстепенную. В нем предусмотрено два интерфейса: интерфейс командной строки и графический пользовательский интерфейс под названием Data Guard Manager (Диспетчер средств защиты данных).

Oracle Data Guard Broker является замечательным инструментом, поскольку автоматизирует выполнение многих задач, связанных с управлением сложными группировками резервных баз данных, а также настройку зачастую сложных сетевых аспектов, необходимых для их обслуживания.

На заметку! Технология Oracle Data Guard не предназначена для обеспечения минимального времени простоя. Она предназначения для усиления защиты данных и предоставления альтернативной базы данных во время проведения запланированного обслуживания производственной базы.

Физические и логические резервные базы данных

Резервные базы данных бывают двух видов: физические и логические. Логическая база данных, несмотря на свое название, все равно является самой настоящей резервной базой данных. Обслуживание логических и физических резервных баз данных осуществляется одинаково: за счет передачи всех изменений из главной производственной базы данных резервной.

Физические резервные базы данных обновляются за счет применения принадлежащих главной базе данных архивных журналов повторного выполнения с помощью фонового процесса ARCH (процесс архивирования). Однако процесс LGWR тоже может использоваться для передачи данных журналов повторного выполнения из главной базы данных резервным. Физические резервные базы данных идентичны производственной базе. Для того чтобы соответствовать производственной базе данных, физическая резервная база данных должна подвергаться постоянному процессу восстановления.

Что касается логических резервных баз данных, то они предусматривают использование тех же самых архивных журналов для извлечения информации о транзакциях, которая применяется к ним с помощью операторов SQL.

Главное отличие между двумя этими видами резервных баз данных состоит в том, что физическую резервную базу данных нельзя использовать для генерации отчетов при выполнении для нее процедуры восстановления. К логической резервной базе данных можно постоянно получать доступ как для генерации отчетов, так и для отправки запросов, даже во время выполнения для нее процедуры восстановления. Всего в конфигурации Oracle Data Guard допускается иметь максимум девять логических и физических резервных баз данных.

И у логических, и у физических резервных баз данных имеются свои собственные преимущества и недостатки. Физическая резервная база данных является традиционным вариантом резервной базы данных Oracle и подразумевает применение журналов повторного выполнения с производственного сервера для выполнения восстановления. Никаких ограничений по данным нет — все типы DML и DDL могут передаваться механически с применением журналов повторного выполнения.

Режимы защиты

При использовании Oracle Data Guard для обслуживания резервных базы данных на выбор доступны три режима защиты. Эти режимы защиты являются отражением компромисса между степенью готовности и степенью производительности.

Режим максимальной защиты. Этот режим, также называемый режимом двойной защиты от сбоев (double failure protection mode), обеспечивает наивысший уровень защиты. Он гарантирует, что в случае выхода из строя главной базы данных никакие данные утрачиваться не будут. Для обеспечения такой защиты данные повторного выполнения перед фиксацией транзакции должны обязательно записываться как в соответствующий оперативный журнал главной базы данных, так и в соответствующий оперативный журнал хотя бы одной резервной базы данных. При невозможности выполнить запись данных повторного выполнения в хотя бы один из журнальных файлов второстепенной базы данных, главная база данных будет останавливаться.
Режим максимальной готовности. Этот режим, также называемый режимом безотлагательной защиты (instant protection mode), обеспечивает защиту от отказа главной производственной базы данных. Он гарантирует наивысший из возможных уровень защиты данных при поддержании главной базы данных в доступном состоянии. При этом режиме данные повторного выполнения с главного сервера записываются на нем асинхронно сразу же после фиксации транзакций. В случае использования этого режима возможна утрата главной базы данных, резервной базы данных или соединения между ними, но не утрата каких-либо данных. При утрате соединения с резервной базой данных главный сервер прекращает пересылать ей изменения, но все равно продолжает работать.
Режим максимальной производительности. При отсутствии необходимости в защите с нулевой потерей данных и желании, чтобы уровень производительности главной базы данных был максимальным, следует выбирать именно этот режим. В этом режиме главная база данных не ожидает получения подтверждения от второстепенной прежде, чем фиксировать транзакции. Из-за этого, в случае выхода главной базы данных из строя, в резервной базе данных может не хватать каких-нибудь изменений, которые уже были зафиксированы в главной базе.

Как не трудно заметить, каждый режим предусматривает обеспечение либо более высокой производительности, либо более сильной защиты данных. Выбирать нужно тот, который более всего соответствует потребностям конкретной организации.

Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

В контексте реализации отказоустойчивых решений основными задачами являются обеспечение быстрого времени восстановления при возникновении нештатной ситуации (аварии) и обеспечение минимальной потери или отсутствия потери данных. Казалось бы СУБД 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 на том же сервере, что и продуктовая БД (что может быть востребовано для распараллеливания по нодам юниксового кластера)

Развернув информационную систему на базе СУБД 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" <<EOF

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'

Читайте также: