Data guard oracle настройка
Data Guard is the name for Oracle's standby database solution, used for disaster recovery and high availability. This article contains an updated version of the 9i physical standby setup method posted here.
You should probably be using the Data Guard Broker to configure and manage your standby database, as described here.
If you already know about Data Guard and want to quickly set up a demo environment using VirtualBox and Vagrant you can follow the instructions in my GitHub repository here.
Подготовка среды
Переключение базы данных на виртуальной машине myVM1 (основная)
Переключитесь с основной базы данных на резервную (с cdb1 на cdb1_stby):
Теперь можно подключиться к резервной базе данных.
Create Standby Using DUPLICATE
Start the auxillary instance on the standby server by starting it using the temporary "init.ora" file.
Connect to RMAN, specifying a full connect string for both the TARGET and AUXILLARY instances. DO not attempt to use OS authentication.
Now issue the following DUPLICATE command.
- FOR STANDBY : This tells the DUPLICATE command is to be used for a standby, so it will not force a DBID change.
- FROM ACTIVE DATABASE : The DUPLICATE will be created directly from the source datafile, without an additional backup step.
- DORECOVER : The DUPLICATE will include the recovery step, bringing the standby up to the current point in time.
- SPFILE : Allows us to reset values in the spfile when it is copied from the source server.
- NOFILENAMECHECK : Destination file locations are not checked.
Once the command is complete, we can start the apply process.
Проверка конфигурации Data Guard
Настройка службы на myVM2 (резервная)
Подключитесь к виртуальной машине myVM2 по протоколу SSH:
Выполните вход в качестве пользователя Oracle:
Измените файл tnsnames.ora, расположенный в папке $ORACLE_HOME\network\admin, или создайте его.
Добавьте следующие записи:
Измените файл listener.ora, расположенный в папке $ORACLE_HOME\network\admin, или создайте его.
Добавьте следующие записи:
Snapshot Standby
Introduced in 11g, snapshot standby allows the standby database to be opened in read-write mode. When switched back into standby mode, all changes made whilst in read-write mode are lost. This is achieved using flashback database, but the standby database does not need to have flashback database explicitly enabled to take advantage of this feature, thought it works just the same if it is.
If you are using RAC, turn off all but one of the RAC instances. Make sure the instance is in MOUNT mode.
Make sure managed recovery is disabled.
Convert the standby to a snapshot standby. The following example queries the V$DATABASE view to show that flashback database is not enabled prior to the conversion operation.
You can now do treat the standby like any read-write database.
To convert it back to the physical standby, losing all the changes made since the conversion to snapshot standby, issue the following commands.
The standby is once again in managed recovery and archivelog shipping is resumed. Notice that flashback database is still not enabled.
Azure CLI используется для создания ресурсов Azure и управления ими из командной строки или с помощью сценариев. В этой статье описывается, как с помощью Azure CLI развернуть базу данных Oracle Database 12c из образа Azure Marketplace. В этой статье представлено пошаговое руководство по установке и настройке Data Guard на виртуальной машине Azure.
Прежде чем начать, убедитесь, что установлен интерфейс командной строки Azure CLI. Дополнительные сведения см. в руководстве по установке Azure CLI.
Start Listener
Make sure the listener is started on the standby server.
Режимы защиты
При использовании Oracle Data Guard для обслуживания резервных базы данных на выбор доступны три режима защиты. Эти режимы защиты являются отражением компромисса между степенью готовности и степенью производительности.
- Режим максимальной защиты. Этот режим, также называемый режимом двойной защиты от сбоев (double failure protection mode), обеспечивает наивысший уровень защиты. Он гарантирует, что в случае выхода из строя главной базы данных никакие данные утрачиваться не будут. Для обеспечения такой защиты данные повторного выполнения перед фиксацией транзакции должны обязательно записываться как в соответствующий оперативный журнал главной базы данных, так и в соответствующий оперативный журнал хотя бы одной резервной базы данных. При невозможности выполнить запись данных повторного выполнения в хотя бы один из журнальных файлов второстепенной базы данных, главная база данных будет останавливаться.
- Режим максимальной готовности. Этот режим, также называемый режимом безотлагательной защиты (instant protection mode), обеспечивает защиту от отказа главной производственной базы данных. Он гарантирует наивысший из возможных уровень защиты данных при поддержании главной базы данных в доступном состоянии. При этом режиме данные повторного выполнения с главного сервера записываются на нем асинхронно сразу же после фиксации транзакций. В случае использования этого режима возможна утрата главной базы данных, резервной базы данных или соединения между ними, но не утрата каких-либо данных. При утрате соединения с резервной базой данных главный сервер прекращает пересылать ей изменения, но все равно продолжает работать.
- Режим максимальной производительности. При отсутствии необходимости в защите с нулевой потерей данных и желании, чтобы уровень производительности главной базы данных был максимальным, следует выбирать именно этот режим. В этом режиме главная база данных не ожидает получения подтверждения от второстепенной прежде, чем фиксировать транзакции. Из-за этого, в случае выхода главной базы данных из строя, в резервной базе данных может не хватать каких-нибудь изменений, которые уже были зафиксированы в главной базе.
Как не трудно заметить, каждый режим предусматривает обеспечение либо более высокой производительности, либо более сильной защиты данных. Выбирать нужно тот, который более всего соответствует потребностям конкретной организации.
Целью данной работы ставилось построение демо стенда для изучения возможностей Oracle Data Guard из узлов Oracle RAC 12.1.0.2.0.
Так как под рукой у меня не нашлось сервера, на котором я бы мог разместить все необходимые мне виртуальные машины (7 штук), то строить будем с использованием офисных PC.
- 3 PC с такими характеристиками: CPU i5, 16 GB RAM
- Обычная офисная сеть 1Gbit/s
На третьем PC разместится одна виртуалка управления с Oracle Enterprise Manager Cloud Control 12c Release 5 (12.1.0.5). Насчет EM — дальше я о нем упоминать не буду ввиду того, что это отдельная тема в данном случае больше связанная не с построением стенда Data Guard, а с его использованием.
Необходимое программное обеспечение Oracle скачиваем с их сайта, а в качестве основной операционной системы я выбрал Fedora 22 с qemu-kvm + libvirt + openvswitch. В качестве гостевой ОС используем Oracle Linux 6.6.
Подготовка Fedora для хостинга виртуальных машин
Распределим IP адреса следующим образом:
Избавляемся от GNOME на каждой из персоналок:
Сконфигурируем HugeMem для виртуалок из расчета 4300M на каждую.
Кластерам нужна синхронизация времени, поэтому на prmy конфигурируем chronyd:
На prmy конфигурируем DHCP сервер для раздачи IP адресов виртуалкам:
В стандартный /etc/named.conf добавим следующие стрчки:
У нас будет свои DHCP и DNS сервера и чтобы не мешать остальной офисной сети мы сконфигурируем для работы стенда свои подсети в отдельных VLAN.
Устанавливаем Open vSwitch:
Создаем отдельный свич для public сети кластера:
Вместе с мостом создается внутренний порт и на нем внутренний интерфейс по имени совпадающем с имением моста ovsbr0. Этот интерфейс будет получать IP адрес с офисного DHCP через физический интерфейс enp3s0.
В свою очередь физический интерфейс enp3s0 подключим к этому мосту:
Конфигурируем порт (VLAN 100) и интерфейс на Open vSwitch для public сети кластеров. Через него будем раздавать IP адреса, DNS и NTP для вируалок кластеров и EM 12c.
Конфигурируем отдельный свич, порт (VLAN 101) и интерфейс на Open vSwitch для первого inetrconnect'а кластера.
Конфигурируем отдельный свич, порт (VLAN 102) и интерфейс на Open vSwitch для второго inetrconnect'а кластеров.
Конфигурируем отдельный свич, порт (VLAN 103) и интерфейс на Open vSwitch для трафика Data Guard.
Создаем такие же определения интерфейсов на sby меняя HWADDR на актуальные и последнюю цифру в IP адресах для sby на 2.
Свичи iconn1, iconn2 и dg0 получились у нас изолированными и их трафик не выходит наружу. Для того чтобы виртуальные машины на prmy могли обмениваться данными по всем внутренним сетям с виртуальными машинами на sby и наоборот, мы подключим эти свичи к ovsbr0, который имеет внешний физический порт.
Реализуем это соединением всех свичей «паровозиком» при помощи Patch портов на свичах.
Определения следующих интерфейсов идентичны на prmy и sby:
Теперь перезагружаем prmy и sby.
Проверяем получившуюся конфигурацию openvswitch:
Конфигурация должна быть одинаковой на всех компьютерах.
Проверяем IP адреса:
Проверяем что ping есть на все адреса.
Создание виртуальных машин
Удаляем default сеть libvirt:
Создаем свои определения сетей:
Создаем диски для prmy1:
Заставить правильно работать qemu+kvm с общими дисками в формате qcow2 мне не удалось, поэтому общие диски создаем в формате raw.
Берем дистрибутив Oracle Linux 6.6 64bit и кладем его на место:
Конфигурируем NFS сервер:
В /stage скачиваем дистрибутивы Grid Infrastructure, Oracle Database 12.1.0.2 и распаковываем их.
Создаем определение виртуальной машины prmy1:
Запускаем Virtual Machine Manager и инсталлируем операционную систему любым удобным для вас способом. Сетевые интерфейсы должны получить свои IP адреса с нашего DHCP. 200MB отдаем для /boot, 8GB для swap и остальное для /. В качестве файловой системы для / и /boot используем, например ext3.
В состав пакетов для установки включим группы пакетов:
Конфигурирование Oracle Linux 6
Подключаемся к созданной виртуалке и конфигурируем ее:
Избавляемся от GNOME:
Избавляемся от вопросов при удалении файла пользователем root:
Избавляемся от запуска ненужных сервисов типа cups и прочих командой chkconfig:
Сервисы ntpd и nscd наоборот включаем:
У меня после перезагрузки получилось следующее:
eth0,eth3 — public eth1, eth2 — interconnect
Создаем группы для Oracle:
Включаем пользователя oracle в группы dba, oper и asmdba
Создаем пользователя grid:
Для удобства будем отображать имя экземпляра Oracle в подсказке bash:
Создаем раздел и файловую систему на диске предназначенном для установки софта Oracle.
Должно получиться так:
Монтировать разделы я хочу не по uuid, а по LABEL:
Нарезаем разделы для ASM дисков, у меня получилось в итоге так:
С сайта Oracle скачиваем пакет oracleasmlib-2.0.4-1.el6.x86_64 помещаем на prmy в /stage и устанавливаем его:
Создаем ASM диски:
На этом конфигурирование виртуалки можно считать законченным, теперь выключаем ее приступаем к ее клонированию. Но перед этим для облегчения клонирования скопируем с нее файлы, которые будут разными в каждой виртуалке.
Клонирование виртуальных машин
Копируем общие диски на sby:
Создаем каталоги для виртуалок:
Копируем наши «эталонные» образы system.qcow и u01.qcow2 на sby.
Клонируем виртуальный диск system.qcow2 на prmy:
Диск u01.qcow2 просто копируем:
Готовим файлы на замену в виртуалках:
Туда же копируем определение виртуальной машины prmy1:
Копируем их в образ виртуальной машины prmy2:
Редактируем определение виртуалной машины prmy2.
меняем имена:
меняем mac адреса:
удаляем IDE контроллер:
И создаем виртуальную машину prmy2:
Продолжаем в том же духе с prmy3.
Имена меняем командой:
Mac адреса соответственно:
Запускаем виртуальные машины:
Подключаемся к ним проверяем что имя у них правильное, соседок по сети, DNS и NTP сервера они видит, диски на месте:
Их тоже стартуем:
Инсталляция Grid Infrastructure
Процесс довольно длинный и скучный.
Инсталлируем Grid Infrastructure на prmy:
Flex Cluster нам не нужен.
Сконфигурируем GNS на домене, указанном в DNS при делегировании зоны.
Сконфигурируем Flex ASM, хотя он тут по большому счету не нужен. Впрочем это же стенд для изучения возможностей и можно ограничить количество узлов на которых стартует ASM двумя. При использовании стандартного ASM можно было сэкономить по памяти — его минимальные требования 300M вместо 1G у Flex ASM.
Берем первые 8 дисков
Если сделали вся как у меня, то проверки и инсталляция должна пройти без замечаний.
После окончания инсталляции выгрузим данные GNS для подключения клиента:
GNS будет в одном экземпляре. Резервный кластер будет использовать GNS основного.
Инсталляция Grid Infrastructure на sby похожа на то что мы уже делали за исключением имен узлов и GNS.
Если бы мы выбрали инсталляцию Flex Cluster, то не смогли бы использовать GNS соседнего кластера.
Создание дополнительных дисковых групп ASM
Нам понадобятся дополнительные дисковые группы на обоих кластерах:
FRA — Fast Recovery Area
ACFS — для общего Oracle Home Oracle Database.
Под каждую дисковую группу берем по 4 оставшихся диска, redundancy external.
На ACFS создаем том и файловую систему acfs и туда будем инсталлировать программное обеспечение Oracle Database. Проблема непрерывности обслуживания при установке патчей и апгрейах нас не очень волнует — на этом стенде вряд ли будет больше одного пользователя. Зато немного быстрее пройдет инсталляция софта и чуть проще будет конфигурировать Data Duard.
Создаем точку монтирования acfs:
Других версий программного обеспечения у нас не будет, поэтому меняем версию совместимости compatible.rdbms и compatible.asm группы DATA на 12.1.0.2.0.
FRA также создаем с compatible.rdbms и compatible.asm 12.1.0.2.0.
На ACFS дополнительно ставим compatible.advm= 12.1.0.2.0.
Нас попросят выполнить скрипт от пользователя root:
Аналогично конфигурируем дисковые группы на кластере sby.
Инсталляция программного обеспечения Oracle Database
Инсталлируем программное обеспечение Oracle Database. Саму базу будем создавать отдельно при помощи dbca. Устанавливаем на все 3 узла кластера.
При проверке он почему-то не видит установленного в нужное ему значения параметра hard memlock=3828161. Создает fixup скрипт, а при его выполнении переустанавливает параметр в то же значение, но все равно на этот параметр обижается.
Короче, смело это игнорируем.
Аналогично устанавливаем софт на кластер sby.
После после завершения инсталляции на sby запускаем следующую команду:
Иначе наша stanby БД не получит доступа к файлам на ASM.
Создание основной кластерной базы данных
Базу данных создать можно и policy или administrator managed. В любом случае для этой БД задействуем только 2 узла кластера. Третий оставим для Far Sync.
Я создавал administrator managed базу данных:
Конфигурирование Oracle Net для Data Guard
Конфигурируем основной кластер. Сначала задействуем оставшуюся неиспользованной сеть 192.168.103.0/24 для Data Guard.
Проверяем те сети, что уже сконфигурированы:
Дальше я буду делать вторую public dhcp сеть, хотя делать этого не стоит даже на стенде, а в документации на команду srvctl add network об этом прямо сказано:
Oracle only supports DHCP-assigned networks for the default network, not for subsequent networks.
Так что в команде srvctl add network используйте опцию -nettype static выделяйте статические VIP адреса, ну и далее по документации.
Тем не менее такую сеть нам сделать позволят и внешне все будет какое-то время работать. Но при старте VIP адреса у меня наблюдался шторм DHCP запросов на этот адрес.
Все это не помешало мне довести создание конфигурации Data Guard до конца (VIP agent не успел своими логами запросов к DHCP переполнить файловую систему).
Следующий свободный номер сети -2, конфигурируем ее:
Добавляем VIP адреса:
Добавляем SCAN LISTENER'ы:
В отличие от тех что в public сети, эти слушают порт 12001.
Добавляем в эту сеть SCAN адрес. Назначение его такое же что и аналогичного SCAN в public сети:
Все что мы сейчас создали должно отобразиться в GNS:
Теперь создадим листенер базы данных в этой сети с названием LISTENER_DG и портом 12001.
Этот листенер предназначет исключительно для Data Guard требует дополнительного конфигурирования на каждом узле кластеров и в нем же будет прописан статический сервис для Data Guard.
Конфигурировать буду в 2 шага, сначала через netmgr для того чтобы не ошибиться в синтаксисе:
А потом еще и руками, потому что netmgr не понимает больших значений параметров *_BUF_SIZE.
Для кластера sby процедуру придется повторить:
Смотрим что получилось (выполняем команду на prmy1):
Синим цветом помечены записи GNS соответствующие адресам второй сети кластера sby.
Создаем листенер базы данных.
Данный пост будет интересен тем, перед кем стоит задача настройки 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-шары, настраивать мониторинги и т. д (об этом в данном посте уже писать не буду).
На этом все, надеюсь, что пост будет кому-то полезен. Спасибо за внимание, буду рад комментариям и вопросам.
Flashback Database
It was already mentioned in the previous section, but it is worth drawing your attention to Flashback Database once more. Although a switchover/switchback is safe for both the primary and standby database, a failover renders the original primary database useless for converting to a standby database. If flashback database is not enabled, the original primary must be scrapped and recreated as a standby database.
An alternative is to enable flashback database on the primary (and the standby if desired) so in the event of a failover, the primary can be flashed back to the time before the failover and quickly converted to a standby database. That process is shown here.
Database Switchover
A database can be in one of two mutually exclusive modes (primary or standby). These roles can be altered at runtime without loss of data or resetting of redo logs. This process is known as a Switchover and can be performed using the following statements.
On the original standby database issue the following commands.
Once this is complete, test the log transport as before. If everything is working fine, switch the primary database back to the original server by doing another switchover. This is known as a switchback.
Initialization Parameters
Check the setting for the DB_NAME and DB_UNIQUE_NAME parameters. In this case they are both set to "DB11G" on the primary database.
The DB_NAME of the standby database will be the same as that of the primary, but it must have a different DB_UNIQUE_NAME value. The DB_UNIQUE_NAME values of the primary and standby database should be used in the DG_CONFIG setting of the LOG_ARCHIVE_CONFIG parameter. For this example, the standby database will have the value "DB11G_STBY".
Set suitable remote archive log destinations. In this case I'm using the fast recovery area for the local location, but you could specify an location explicitly if you prefer. Notice the SERVICE and the DB_UNIQUE_NAME for the remote location reference the standby location.
The LOG_ARCHIVE_FORMAT and LOG_ARCHIVE_MAX_PROCESSES parameters must be set to appropriate values and the REMOTE_LOGIN_PASSWORDFILE must be set to exclusive.
In addition to the previous setting, it is recommended to make sure the primary is ready to switch roles to become a standby. For that to work properly we need to set the following parameters. Adjust the *_CONVERT parameters to account for your filename and path differences between the servers.
Remember, some of the parameters are not modifiable, so the database will need to be restarted before they take effect.
Create Redo Logs
Create online redo logs for the standby. It's a good idea to match the configuration of the primary server.
In addition to the online redo logs, you should create standby redo logs on both the standby and the primary database (in case of switchovers). The standby redo logs should be at least as big as the largest online redo log and there should be one extra group per thread compared the online redo logs. In my case, the following standby redo logs must be created on both servers.
Once this is complete, we can start the apply process.
Test Log Transport
On the primary server, check the latest archived redo log and force a log switch.
Check the new archived redo log has arrived at the standby server and been applied.
Backup Primary Database
If you are planning to use an active duplicate to create the standby database, then this step is unnecessary. For a backup-based duplicate, or a manual restore, take a backup of the primary database.
Подключение к виртуальной машине
Используйте следующую команду для создания сеанса SSH с виртуальной машиной. Замените IP-адрес общедоступным IP-адресом виртуальной машины (значение publicIpAddress ).
Protection Mode
There are three protection modes for the primary database:
- Maximum Availability: Transactions on the primary do not commit until redo information has been written to the online redo log and the standby redo logs of at least one standby location. If no standby location is available, it acts in the same manner as maximum performance mode until a standby becomes available again.
- Maximum Performance: Transactions on the primary commit as soon as redo information has been written to the online redo log. Transfer of redo information to the standby server is asynchronous, so it does not impact on performance of the primary.
- Maximum Protection: Transactions on the primary do not commit until redo information has been written to the online redo log and the standby redo logs of at least one standby location. If not suitable standby location is available, the primary database shuts down.
By default, for a newly created standby database, the primary database is in maximum performance mode.
The mode can be switched using the following commands. Note the alterations in the redo transport attributes.
Удаление виртуальной машины
Вы можете удалить ставшие ненужными группу ресурсов, виртуальную машину и все связанные с ней ресурсы, использовав следующую команду:
В блогах нашего сообщества вы можете найти приемы резервного копирования позволят защитить базу данных от неожиданных отказов дисков и прочих неполадок с оборудованием. Наличие хорошо спроектированной системы с зеркальным отображением дисков или сконфигурированным массивом RAID обеспечит достаточную степень избыточности для сохранения работоспособности базы данных после обычных аварий. Однако даже самые продуманные схемы резервного копирования не могут гарантировать высокой готовности системы. Любая серьезная авария способна легко вывести информационные ресурсы организации из строя и стать причиной длительных простоев в предоставлении услуг. Для защиты от подобных событий требуется иметь в распоряжении не только обычные системы резервного копирования, но и целую стратегию по обеспечению высокой готовности.
Настройка службы на myVM1 (основная)
Измените файл tnsnames.ora, расположенный в папке $ORACLE_HOME\network\admin, или создайте его.
Добавьте следующие записи:
Измените файл listener.ora, расположенный в папке $ORACLE_HOME\network\admin, или создайте его.
Добавьте следующие записи:
Включите брокер Data Guard:
Create Standby Controlfile and PFILE
Create a controlfile for the standby database by issuing the following command on the primary database.
Create a parameter file for the standby database.
Amend the PFILE making the entries relevant for the standby database. I'm making a replica of the original server, so in my case I only had to amend the following parameters.
Создание группы ресурсов
Создайте группу ресурсов с помощью команды az group create. Группа ресурсов Azure является логическим контейнером, в котором происходит развертывание ресурсов Azure и управление ими.
В следующем примере создается группа ресурсов с именем myResourceGroup в расположении westus :
Standby Server Setup (DUPLICATE)
Create Standby Redo Logs on Primary Server
The DUPLICATE command automatically creates the standby redo logs on the standby. To make sure the primary database is configured for switchover, we must create the standby redo logs on the primary server.
Failover
If the primary database is not available the standby database can be activated as a primary database using the following statements.
Since the standby database is now the primary database it should be backed up immediately.
The original primary database can now be configured as a standby. If Flashback Database was enabled on the primary database, then this can be done relatively easily (shown here). If not, the whole setup process must be followed, but this time using the original primary server as the standby.
Предположения
Чтобы установить Oracle Data Guard, необходимо создать две виртуальные машины Azure в одной группе доступности:
- На основной виртуальной машине (myVM1) выполняется экземпляр Oracle.
- На резервной виртуальной машине (myVM2) установлено только программное обеспечение Oracle.
Образ Marketplace, который вы будете использовать для создания виртуальных машин, — Oracle:Oracle-Database-Ee:12.1.0.2:latest.
Войдите в подписку Azure с помощью команды az login и следуйте инструкциям на экране.
Service Setup
Entries for the primary and standby databases are needed in the "$ORACLE_HOME/network/admin/tnsnames.ora" files on both servers. You can create these using the Network Configuration Utility (netca) or manually. The following entries were used during this setup.
Start Listener
When using active duplicate, the standby server requires static listener configuration in a "listener.ora" file. In this case I used the following configuration.
Make sure the listener is started on the standby server.
Copy Files
Create the necessary directories on the standby server.
Copy the files from the primary to the standby server.
Notice, the backups were copied across to the standby server as part of the FRA copy. If your backups are not held within the FRA, you must make sure you copy them to the standby server and make them available from the same path as used on the primary server.
"Создать группу доступности"
Создавать группу доступности необязательно, но мы рекомендуем это сделать. Дополнительные сведения см. в статье Рекомендации по группам доступности Azure для виртуальных машин Windows.
Технология 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 не предназначена для обеспечения минимального времени простоя. Она предназначения для усиления защиты данных и предоставления альтернативной базы данных во время проведения запланированного обслуживания производственной базы.
Создание базы данных на myVM1 (основная)
Программное обеспечение Oracle уже установлено в образе Marketplace, поэтому следующим шагом является установка базы данных.
Переключитесь на суперпользователя Oracle:
Создание базы данных
Результат должен выглядеть следующим образом:
Задайте переменные ORACLE_SID и ORACLE_HOME:
При необходимости можно добавить ORACLE_HOME и ORACLE_SID в файл /home/oracle/.bashrc, чтобы эти параметры сохранились для последующих входов в систему:
Переключение базы данных на виртуальной машине myVM2 (резервная)
Чтобы переключиться обратно, на виртуальной машине myVM2 выполните следующее:
Теперь вы снова имеете возможность подключиться к основной базе данных.
Вы завершили установку и настройку Data Guard на Oracle Linux.
Start Apply Process
Start the apply process on standby server.
If you need to cancel the apply process, issue the following command.
If you prefer, you can set a delay between the arrival of the archived redo log and it being applied on the standby server using the following commands.
Provided you have configured standby redo logs, you can start real-time apply using the following command.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
Logging
Check that the primary database is in archivelog mode.
If it is noarchivelog mode, switch is to archivelog mode.
Enabled forced logging by issuing the following command.
Системы с высокой готовностью
Система с высокой степенью готовности будет обеспечивать практически непрерывную доступность данных при возникновении аварий практически любого рода. Главным способом для обеспечения такой высокой степени готовности является применение нескольких систем данных с разными архитектурами. Oracle предлагает в этом отношении несколько вариантов.
Технология Oracle Data Guard и резервные базы данных часто применяются для обеспечения возможности восстановления после аварий, защиты данных и высокой степени готовности. Поэтому давайте вкратце рассмотрим, как они работают.
Создание виртуальной машины
Создайте виртуальную машину с помощью команды az vm create.
В следующем примере создаются две виртуальные машины — myVM1 и myVM2 , Также создаются ключи SSH, если они не существуют в расположении ключей по умолчанию. Чтобы использовать определенный набор ключей, используйте параметр --ssh-key-value .
Создайте myVM1 (основная):
После создания виртуальной машины в Azure CLI отображается информация следующего вида. Запишите значение publicIpAddress . Этот адрес используется для доступа к виртуальной машине.
Создайте myVM2 (резервная):
После создания виртуальной машины myVM2 запишите значение publicIpAddress .
Copy Files
Create the necessary directories on the standby server.
Copy the files from the primary to the standby server.
Настройка Data Guard
Открытие TCP-порта для возможности подключения
На этом шаге настраиваются внешние конечные точки, которые обеспечивают удаленный доступ к базе данных Oracle.
Откройте порт для myVM1:
Результат должен выглядеть следующим образом:
Откройте порт для myVM2:
Primary Server Setup
Restore Backup
Create the SPFILE form the amended PFILE.
Restore the backup files.
Настройка брокера Data Guard на myVM1 (основная)
Запустите диспетчер Data Guard и войдите, используя SYS и пароль. (Не используйте проверку подлинности на уровне операционной системы.) Выполните следующие действия:
Настройка Oracle Data Guard завершена. В следующем разделе показано, как проверить подключение и переключение.
Assumptions
- You have two servers (physical or VMs) with an operating system and Oracle installed on them. In this case I've used Oracle Linux 5.6 and Oracle Database 11.2.0.2.
- The primary server has a running instance.
- The standby server has a software only installation.
Включение режима журнала архивирования на myVM1 (основная)
Включите принудительное ведение журнала и убедитесь, что есть хотя бы один файл журнала:
При создании резервных журналов повторяемых операций их размер и количество должны совпадать с размером и количеством журналов повторяемых операций базы данных источника:
Включите переключение базы данных (Flashback) (что значительно упростит восстановление) и задайте для параметра STANDBY_FILE_MANAGEMENT значение AUTO. После этого выйдите из SQL*Plus.
Read-Only Standby and Active Data Guard
Once a standby database is configured, it can be opened in read-only mode to allow query access. This is often used to offload reporting to the standby server, thereby freeing up resources on the primary server. When open in read-only mode, archive log shipping continues, but managed recovery is stopped, so the standby database becomes increasingly out of date until managed recovery is resumed.
To switch the standby database into read-only mode, do the following.
To resume managed recovery, do the following.
In 11g, Oracle introduced the Active Data Guard feature. This allows the standby database to be open in read-only mode, but still apply redo information. This means a standby can be available for querying, yet still be up to date. There are licensing implications for this feature, but the following commands show how active data guard can be enabled.
Since managed recovery continues with active data guard, there is no need to switch back to managed recovery from read-only mode in this case.
Физические и логические резервные базы данных
Резервные базы данных бывают двух видов: физические и логические. Логическая база данных, несмотря на свое название, все равно является самой настоящей резервной базой данных. Обслуживание логических и физических резервных баз данных осуществляется одинаково: за счет передачи всех изменений из главной производственной базы данных резервной.
Физические резервные базы данных обновляются за счет применения принадлежащих главной базе данных архивных журналов повторного выполнения с помощью фонового процесса ARCH (процесс архивирования). Однако процесс LGWR тоже может использоваться для передачи данных журналов повторного выполнения из главной базы данных резервным. Физические резервные базы данных идентичны производственной базе. Для того чтобы соответствовать производственной базе данных, физическая резервная база данных должна подвергаться постоянному процессу восстановления.
Что касается логических резервных баз данных, то они предусматривают использование тех же самых архивных журналов для извлечения информации о транзакциях, которая применяется к ним с помощью операторов SQL.
Главное отличие между двумя этими видами резервных баз данных состоит в том, что физическую резервную базу данных нельзя использовать для генерации отчетов при выполнении для нее процедуры восстановления. К логической резервной базе данных можно постоянно получать доступ как для генерации отчетов, так и для отправки запросов, даже во время выполнения для нее процедуры восстановления. Всего в конфигурации Oracle Data Guard допускается иметь максимум девять логических и физических резервных баз данных.
И у логических, и у физических резервных баз данных имеются свои собственные преимущества и недостатки. Физическая резервная база данных является традиционным вариантом резервной базы данных Oracle и подразумевает применение журналов повторного выполнения с производственного сервера для выполнения восстановления. Никаких ограничений по данным нет — все типы DML и DDL могут передаваться механически с применением журналов повторного выполнения.
Standby Server Setup (Manual)
Подключение базы данных с клиентского компьютера
Обновите файл tnsnames.ora на клиентском компьютере или создайте его. Этот файл обычно находится в папке $ORACLE_HOME\network\admin.
Замените IP-адреса своими значениями publicIpAddress для myVM1 и myVM2:
Восстановление базы данных на myVM2 (резервная)
Создайте файл параметров /tmp/initcdb1_stby.ora со следующим содержимым:
Создайте файл пароля:
Запустите базу данных на myVM2:
Восстановите базу данных с помощью инструмента RMAN:
Выполните следующие команды в RMAN:
При необходимости можно добавить ORACLE_HOME и ORACLE_SID в файл /home/oracle/.bashrc, чтобы эти параметры сохранились для последующих входов в систему:
Включите брокер Data Guard:
Читайте также: