Настройка оракула защиты данных

Обновлено: 02.07.2024

Data Guard — это решение Oracle для резервной базы данных, используемое для аварийного восстановления и обеспечения высокой доступности. Эта статья содержит опубликованную здесь обновленную версию метода установки физического резерва 9i.

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

Если вы уже знакомы с Data Guard и хотите быстро настроить демонстрационную среду с помощью VirtualBox и Vagrant, следуйте инструкциям в моем репозитории GitHub здесь.

Предположения

У вас есть два сервера (физические или виртуальные машины) с установленной на них операционной системой и Oracle. В данном случае я использовал Oracle Linux 5.6 и Oracle Database 11.2.0.2.
На первичном сервере есть работающий экземпляр.
На резервном сервере установлено только программное обеспечение.

Настройка основного сервера

Ведение журнала

Убедитесь, что основная база данных находится в режиме архивного журнала.

Если это режим без архивного журнала, переключитесь в режим архивного журнала.

Включил принудительное ведение журнала, выполнив следующую команду.

Параметры инициализации

Проверьте настройку параметров DB_NAME и DB_UNIQUE_NAME. В этом случае для них обоих установлено значение "DB11G" в первичной базе данных.

Имя DB_NAME резервной базы данных будет таким же, как и у основной, но у него должно быть другое значение DB_UNIQUE_NAME. Значения DB_UNIQUE_NAME основной и резервной баз данных должны использоваться в настройке DG_CONFIG параметра LOG_ARCHIVE_CONFIG. В этом примере резервная база данных будет иметь значение "DB11G_STBY".

Установите подходящие места назначения журнала удаленного архива. В этом случае я использую область быстрого восстановления для локального местоположения, но вы можете указать местоположение явно, если хотите. Обратите внимание, что SERVICE и DB_UNIQUE_NAME для удаленного расположения ссылаются на резервное расположение.

Для параметров LOG_ARCHIVE_FORMAT и LOG_ARCHIVE_MAX_PROCESSES должны быть установлены соответствующие значения, а для REMOTE_LOGIN_PASSWORDFILE должно быть задано монопольное значение.

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

Помните, что некоторые параметры нельзя изменить, поэтому базу данных необходимо будет перезапустить, прежде чем они вступят в силу.

Настройка службы

Записи для основной и резервной баз данных необходимы в файлах "$ORACLE_HOME/network/admin/tnsnames.ora" на обоих серверах. Вы можете создать их с помощью утилиты настройки сети (netca) или вручную. Во время этой установки использовались следующие записи.

Резервное копирование основной базы данных

Если вы планируете использовать активный дубликат для создания резервной базы данных, этот шаг не нужен. Для дубликата на основе резервной копии или восстановления вручную сделайте резервную копию первичной базы данных.

Создать резервный управляющий файл и PFILE

Создайте управляющий файл для резервной базы данных, выполнив следующую команду для основной базы данных.

Создайте файл параметров для резервной базы данных.

Измените PFILE, сделав записи релевантными для резервной базы данных. Я делаю реплику исходного сервера, поэтому в моем случае мне нужно было изменить только следующие параметры.

Настройка резервного сервера (вручную)

Копировать файлы

Создайте необходимые каталоги на резервном сервере.

Скопируйте файлы с основного сервера на резервный.

Обратите внимание, резервные копии были скопированы на резервный сервер как часть копии FRA. Если ваши резервные копии не хранятся в рамках FRA, вы должны убедиться, что вы скопировали их на резервный сервер и сделали их доступными по тому же пути, что и на основном сервере.

Запустить прослушиватель

Убедитесь, что прослушиватель запущен на резервном сервере.

Восстановить резервную копию

Создайте SPFILE из измененного PFILE.

Восстановите файлы резервной копии.

Создание журналов повторов

Создайте оперативные журналы повторов для резервного сервера. Рекомендуется совпадать с конфигурацией основного сервера.

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

После этого мы можем начать процесс подачи заявки.

Настройка резервного сервера (ДУБЛИКАТ)

Копировать файлы

Создайте необходимые каталоги на резервном сервере.

Скопируйте файлы с основного сервера на резервный.

Запустить прослушиватель

При использовании активного дубликата резервному серверу требуется статическая конфигурация прослушивателя в файле «listener.ora». В этом случае я использовал следующую конфигурацию.

Убедитесь, что прослушиватель запущен на резервном сервере.

Создание резервных журналов повторов на основном сервере

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

Создать режим ожидания с помощью DUPLICATE

Запустите вспомогательный экземпляр на резервном сервере, запустив его с помощью временного файла "init.ora".

Подключиться к RMAN, указав полную строку подключения как для ЦЕЛЕВОГО, так и для ДОПОЛНИТЕЛЬНОГО экземпляров. НЕ пытайтесь использовать аутентификацию ОС.

Теперь введите следующую команду DUPLICATE.

FOR STANDBY : указывает, что команда DUPLICATE должна использоваться для резервного сервера, поэтому она не будет принудительно изменять DBID.
ИЗ АКТИВНОЙ БАЗЫ ДАННЫХ: ДУБЛИКАТ будет создан непосредственно из исходного файла данных без дополнительного шага резервного копирования.
DORECOVER : DUPLICATE будет включать в себя этап восстановления, приводящий резервную копию к текущему моменту времени.
SPFILE: позволяет нам сбросить значения в spfile, когда он копируется с исходного сервера.
NOFILENAMECHECK : расположения файлов назначения не проверяются.

После завершения команды мы можем начать процесс применения.

Начать процесс подачи заявки

Запустите процесс применения на резервном сервере.

Если вам нужно отменить процесс применения, введите следующую команду.

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

При условии, что вы настроили резервные журналы повторов, вы можете запустить применение в реальном времени с помощью следующей команды.

ИЗМЕНИТЬ БАЗА ДАННЫХ ВОССТАНОВИТЬ УПРАВЛЯЕМУЮ РЕЗЕРВНУЮ БАЗУ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ ТЕКУЩЕГО ФАЙЛА ЖУРНАЛА;

Проверить перенос журнала

На основном сервере проверьте последний архивный журнал повторов и принудительно переключите журнал.

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

Режим защиты

Для основной базы данных существует три режима защиты:

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

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

Режим можно переключать с помощью следующих команд. Обратите внимание на изменения в атрибутах повторного транспорта.

Переключение базы данных

База данных может находиться в одном из двух взаимоисключающих режимов (основной или резервный). Эти роли можно изменить во время выполнения без потери данных или сброса журналов повторного выполнения. Этот процесс известен как Switchover и может быть выполнен с помощью следующих операторов.

В исходной резервной базе данных введите следующие команды.

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

Отказ

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

Поскольку резервная база данных теперь является основной базой данных, ее необходимо немедленно создать резервную копию.

Исходную первичную базу данных теперь можно настроить как резервную. Если для основной базы данных была включена база данных Flashback, то это можно сделать относительно легко (показано здесь). В противном случае необходимо выполнить весь процесс установки, но на этот раз с использованием исходного основного сервера в качестве резервного.

База данных воспоминаний

Это уже упоминалось в предыдущем разделе, но стоит еще раз обратить ваше внимание на базу данных Flashback. Хотя переключение/обратное переключение безопасно как для первичной, так и для резервной базы данных, при отказе исходная первичная база данных становится бесполезной для преобразования в резервную базу данных.Если ретроспективная база данных не включена, исходную первичную базу данных необходимо удалить и создать заново в качестве резервной базы данных.

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

Ожидание только для чтения и активная защита данных

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

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

Чтобы возобновить управляемое восстановление, выполните следующие действия.

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

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

Ожидание моментального снимка

Появившийся в версии 11g резервный моментальный снимок позволяет открывать резервную базу данных в режиме чтения-записи. При переключении обратно в режим ожидания все изменения, сделанные в режиме чтения-записи, теряются. Это достигается с помощью базы данных ретроспективного анализа, но для резервной базы данных не требуется, чтобы база данных ретроспективного анализа была явно включена, чтобы воспользоваться этой функцией, хотя она работает точно так же, если это так.

Если вы используете RAC, отключите все экземпляры RAC, кроме одного. Убедитесь, что экземпляр находится в режиме MOUNT.

Убедитесь, что управляемое восстановление отключено.

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

Теперь вы можете обращаться с резервной базой данных как с любой базой данных для чтения и записи.

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

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

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

Рекомендации по работе с Oracle Data Guard основаны на рекомендациях, описанных в главе 5 "Настройка базы данных Oracle".

Эта глава содержит следующие темы:

9.1 Рекомендации по настройке Oracle Data Guard

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

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

Data Guard не предназначен для использования в качестве полнофункционального решения для репликации. Oracle GoldenGate — это решение, рекомендованное для расширенных требований к репликации, таких как репликация с несколькими мастерами, гранулярная репликация подмножества базы данных, топологии репликации «многие к одному» и интеграция данных. Oracle GoldenGate также предоставляет дополнительные возможности для сокращения времени простоя в связи с плановым обслуживанием и миграцией разнородных платформ.

В зависимости от ваших требований наиболее эффективным решением может быть использование только Data Guard, использование Data Guard с Oracle GoldenGate в качестве дополнения или просто использование Oracle GoldenGate.

Дополнительную информацию о Data Guard и Oracle GoldenGate см. в Техническом описании продукта Oracle Active Data Guard и Oracle GoldenGate по адресу

Таблица 9-1 содержит сводку вариантов развертывания Data Guard, которые подходят в зависимости от ваших требований. Два или более вариантов могут использоваться в комбинации для удовлетворения нескольких требований. В этой главе также представлены рекомендации по реализации каждого варианта.

Таблица 9-1 Требования и варианты развертывания Data Guard

Нулевая защита от потери данных и доступность для Oracle Database

Максимальная защита или максимальная доступность Data Guard (транспорт SYNC) и повторное применение (физический резерв)

Практически нулевая потеря данных (однозначное число секунд) и доступность для Oracle Database

Максимальная производительность Data Guard (транспорт ASYNC) и повторное применение

Защита нескольких площадок, включая топологию с локальным резервом с нулевой потерей данных для высокой доступности и удаленным асинхронным резервом для географического аварийного восстановления для базы данных Oracle

Конфигурация Data Guard с несколькими резервами и повторное применение

Самое быстрое переключение базы данных при сбое

Data Guard Fast-Start Failover с брокером Oracle Data Guard для автоматического обнаружения сбоев и аварийного переключения базы данных. Автоматическое переключение сопутствующих клиентских приложений на новую производственную базу данных реализовано с помощью Oracle Fast Application Notification (FAN) и Oracle Client Failover Best Practices.

Дополнительную информацию см. в официальном документе MAA "Рекомендации по аварийному переключению клиентов для Data Guard 11g, выпуск 2" в разделе "Рекомендации MAA для базы данных Oracle" по адресу

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

Активная защита данных. Active Data Guard можно приобрести одним из следующих способов: (1) отдельно в качестве дополнительной лицензии для Oracle Database Enterprise Edition или (2) в составе лицензии Oracle GoldenGate.

Ожидание моментального снимка. Резервный моментальный снимок — это физическая резервная база данных, которая временно открыта для чтения и записи для тестирования и других операций чтения и записи, не зависящих от транзакций первичной базы данных. Резервный моментальный снимок легко преобразуется обратно в синхронизированную резервную базу данных после завершения тестирования. Snapshot Standby — это встроенная функция Data Guard Redo Apply, которая идеально дополняет Oracle Real Application Testing.

Плановое техническое обслуживание: миграция определенных платформ, например с Windows на Linux, перемещение центра обработки данных, исправление и обновление системного программного обеспечения или базы данных Oracle

Переключение Data Guard, запланированная смена ролей с использованием Redo Apply. Redo Apply и Standby-First Patch Применить для соответствующих исправлений, начиная с 11.2.0.1. Последовательные обновления базы данных SQL Apply и Data Guard (начиная с версии 10.1). Data Guard Transient Logical Standby (упрощенное обновление) начиная с версии 11.1.0.7.

Дополнительную информацию см. в официальном документе MAA "Последовательное обновление базы данных, упрощенное благодаря использованию физической резервной базы данных Data Guard" в области рекомендаций MAA для Oracle Database по адресу

Защита данных для данных, находящихся за пределами базы данных Oracle

По возможности переместите данные файловой системы операционной системы в базу данных Oracle с помощью файловой системы базы данных Oracle (DBFS). Data Guard защищает данные DBFS так же, как и любые другие данные Oracle.

Данные, которые должны оставаться в файлах операционной системы, можно защитить с помощью Oracle ASM Cluster File System (Oracle ACFS) или зеркального отображения хранилища и Data Guard.

Standby-First Patch позволяет сначала применить исправление к физической резервной базе данных, в то время как основная база данных остается с предыдущим выпуском программного обеспечения (это относится к определенным типам исправлений и не применяется к наборам исправлений Oracle и основным обновлениям выпуска; используйте метод временного логического ожидания Data Guard для наборов исправлений и основных выпусков). Как только вы удовлетворены изменением, вы выполняете переключение на резервную базу данных. Резервный вариант — переключить обратно, если это необходимо. Дополнительную информацию см. в разделе «Oracle Patch Assurance — Data Guard Standby-First Patch Apply» в примечании службы поддержки My Oracle 1265700.1 по адресу

Обзор Oracle Database High Availability для описания решений высокой доступности и преимуществ, предоставляемых Oracle Data Guard и резервными базами данных

Концепции и администрирование Oracle Data Guard содержат полную информацию об Oracle Data Guard

Oracle Data Guard Broker для получения информации об интерфейсе командной строки DGMGRL

9.2 Определение режима защиты и транспорта Data Guard

Защита Oracle Data Guard Zero Data Loss обеспечивает как гарантию защиты данных, так и простейшее восстановление. По этим причинам рекомендуется режим защиты Zero Data Loss, максимальная защита Oracle Data Guard или максимальная доступность. Хотя в обоих режимах по умолчанию используется синхронный повторный транспорт Oracle Data Guard, существуют различия в наборах правил, используемых для управления поведением во время отработки отказа, которые необходимо учитывать, как описано ниже. Однако синхронный повторный транспорт Oracle Data Guard может повлиять на производительность первичной базы данных, если сетевая задержка при обмене данными между первичной и резервной базами данных слишком велика (задержка зависит от расстояния и степени «чистоты» сети).Если это так (проверить несложно, администратор баз данных может динамически изменять режимы защиты и методы транспортировки), используйте Oracle Data Guard Maximum Performance. Максимальная производительность использует асинхронные транспортные службы Oracle Data Guard и не оказывает никакого влияния на производительность основной базы данных независимо от сетевой задержки. В среде с пропускной способностью, достаточной для размещения объема повторов, потенциальная потеря данных измеряется одноразрядными секундами при использовании максимальной производительности.

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

Рекомендации по использованию режима защиты:

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

Режим максимальной доступности гарантирует отсутствие потери данных в тех случаях, когда первичная база данных испытывает первый сбой, влияющий на конфигурацию. В отличие от предыдущего режима защиты, максимальная доступность будет ожидать подтверждения от резервной базы данных не более NET_TIMEOUT секунд, после чего будет сообщать приложению об успешной фиксации и переходить к следующей транзакции. На доступность первичной базы данных (отсюда и название режима защиты) не влияет невозможность связи с резервной базой данных (например, из-за сбоев в работе резервной базы данных или сети). Oracle Data Guard будет продолжать пинговать резервную базу данных и автоматически восстанавливать соединение и повторно синхронизировать резервную базу данных, когда это возможно, но в период, когда основная и резервная базы данных расходятся, данные могут быть потеряны, если второй сбой затронет первичную базу данных. По этой причине рекомендуется отслеживать уровень защиты (это легко сделать с помощью Enterprise Manager Grid Control) и быстро устранять любые нарушения связи между основным и резервным сервером до того, как может произойти второй сбой.

Режим максимальной производительности (режим по умолчанию) обеспечивает максимально возможный уровень защиты данных, не влияя на производительность или доступность первичной базы данных. Это достигается путем фиксации транзакции, как только данные повторного выполнения, необходимые для восстановления этой транзакции, записываются в локальный оперативный журнал повторного выполнения в первичной базе данных (такое же поведение, как если бы резервной базы данных не было). Oracle Data Guard передает данные повторного выполнения в резервную базу данных непосредственно из основного буфера журнала асинхронно с записью в локальный оперативный журнал повторного выполнения. Никогда не нужно ждать подтверждения ожидания. Как и в случае с максимальной доступностью, рекомендуется отслеживать уровень защиты (это легко сделать с помощью Enterprise Manager Grid Control) и быстро устранять любые нарушения связи между основным и резервным сервером до того, как может произойти второй сбой.

Концепции и администрирование Oracle Data Guard для получения информации о режимах защиты Data Guard

9.2.1. Использование рекомендаций Redo Transport Services

В общих чертах передовой опыт Redo Transport для планирования и внедрения сервисов повторного транспорта для Oracle Data Guard выглядит следующим образом:

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

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

Оптимизируйте пропускную способность сети, следуя рекомендациям, описанным в Разделе 9.2.2, "Оценка производительности с помощью предлагаемой конфигурации сети".

9.2.2 Оценка производительности с предлагаемой конфигурацией сети

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

Достаточная пропускная способность для обеспечения максимальной скорости генерации повторов

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

Несколько сетевых путей для резервирования сети

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

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

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

Пошаговая настройка физической резервной копии Oracle 12c Data Guard

В этой статье мы рассмотрим создание резервной базы данных 12.1.0.2.0 с помощью rman.

Сведения о среде: - Конфигурации на стороне основного сервера: -

Шаг 1. Измените режим архивного журнала

[oracle@primary ~]$ sqlplus '/as sysdba'
SQL*Plus: выпуск 12.1.0.2.0, производство вторник, 12 июня, 05:10:47 2018
Авторское право (c) 1982 , 2014, Оракул. Все права защищены.
Подключение к:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 — 64-разрядная рабочая версия
С параметрами секционирования, OLAP, расширенной аналитики и тестирования реальных приложений

SQL> список архивных журналов
Режим журнала базы данных Без режима архива
Автоматическое архивирование Отключено
Целевое расположение архива USE_DB_RECOVERY_FILE_DEST
Самая старая последовательность оперативного журнала 2
Текущая последовательность журнала 4 SQL> закрыть немедленно
База данных закрыта.
База данных размонтирована.
Экземпляр ORACLE отключен.
SQL> стартовое монтирование
экземпляр ORACLE запущен.
Общая глобальная область системы 1660944384 байт
Фиксированный размер 2925072 байт
Переменный размер 1056968176 байт
Буферы базы данных 587202560 байт
Буферы повторного выполнения 13848576 байт
База данных смонтирована.
SQL> изменить архивный журнал базы данных;
База данных изменена.

SQL> изменить базу данных открыть;
База данных изменена.

Шаг 2. Измените режим принудительного ведения журнала

SQL> ALTER DATABASE FORCE LOGGING;
База данных изменена.

SQL> выберите FORCE_LOGGING,log_mode из базы данных v$;
FORCE_LOGGING LOG_MODE
———— ————
ДА АРХИВИРОВАНИЕ

Шаг 3. Добавление Redologfile для резервной базы данных

SQL> изменить базу данных, добавить резервную группу файлов журнала 4 ‘/u01/app/oracle/oradata/PRIME/onlinelog/redo04.log’ размер 50m;
База данных изменена.

SQL> изменить базу данных, добавить резервную группу файлов журнала 5 ‘/u01/app/oracle/oradata/PRIME/onlinelog/redo05.log’ размер 50m;
База данных изменена.

SQL> изменить базу данных добавить резервную группу файлов журнала 6 ‘/u01/app/oracle/oradata/PRIME/onlinelog/redo06.log’ размер 50m;
База данных изменена.

Шаг 4. Добавление сетевой записи на основной и резервный серверы (оба сервера)

Запись Tnsnames:-
**************
PRIME =
(DESCRIPTION =
(ADDRESS_LIST =
( АДРЕС = (ПРОТОКОЛ = TCP)(ХОСТ = основной)(ПОРТ = 1539))
)
(CONNECT_DATA =
(СЕРВЕР = ВЫДЕЛЕННЫЙ)
(ИМЯ_СЛУЖБЫ = основной)
)
)
STAND =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = standby)(PORT = 1539) )
)
(CONNECT_DATA =
(SERVICE_NAME = stand)
)
)
Запись слушателя:-
****** ******
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = prime)
(ORACLE_HOME = /u01/app/oracle/product /12.1.0.2/db_1)
(SID_NAME = prime)
)
(SID_DESC =
(GLOBAL_DBNAME = stand)
(ORACLE_HOME = /u01/app/oracle /product/12.1.0.2/db_1)
(SID_NAME = стенд)
)
)

Вывод, как показано ниже

[oracle@primary admin]$ tnsping prime
Утилита TNS Ping для Linux: версия 12.1.0.2.0 – Производство 12-JUN-2018 05:54:29
Авторское право (c) 1997, 2014, Oracle. Все права защищены.
Используемые файлы параметров:
/u01/app/oracle/product/12.1.0.2/db_1/network/admin/sqlnet.ora
Используется адаптер TNSNAMES для разрешения псевдонима
Попытка для контакта (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.24)(PORT = 1539))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = prime)))
OK (0 мс)

[oracle@primary admin]$ tnsping stand
Утилита TNS Ping для Linux: версия 12.1.0.2.0 — производство 12 июня 2018 г., 05:54:34
Авторское право (c) 1997 , 2014, Оракул. Все права защищены.
Используемые файлы параметров:
/u01/app/oracle/product/12.1.0.2/db_1/network/admin/sqlnet.ora
Используется адаптер TNSNAMES для разрешения псевдонима
Попытка к контакту (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.25)(PORT=1539)))(CONNECT_DATA=(SERVICE_NAME=stand)))
ОК (0 мс)

Шаг 5: - Изменение параметров в первичной базе данных

SQL> ALTER SYSTEM SET db_unique_name=’PRIME’ SCOPE=SPFILE;
Система изменена.

SQL> ALTER SYSTEM SET log_archive_config=’dg_config=(prime,stand)’ SCOPE=SPFILE;
Система изменена.

SQL> ALTER SYSTEM SET log_archive_dest_1=’location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) db_unique_name=prime’ SCOPE=SPFILE;
Система изменена.

SQL> ALTER SYSTEM SET log_archive_dest_2=’service=stand async valid_for=(online_logfiles,primary_role) db_unique_name=stand’ SCOPE=SPFILE;
Система изменена.

SQL> ALTER SYSTEM SET fal_server=’STAND’ SCOPE=SPFILE;
Система изменена.

SQL> ALTER SYSTEM SET fal_client=’PRIME’ SCOPE=SPFILE;
Система изменена.

SQL> ALTER SYSTEM SET standby_file_management=’AUTO’ SCOPE=SPFILE;
Система изменена.

SQL> ALTER SYSTEM SET db_file_name_convert=’/u01/app/oracle/oradata/STAND/datafile’,’/u01/app/oracle/oradata/PRIME/datafile’ SCOPE=SPFILE;
Система изменена.

SQL> ALTER SYSTEM SET log_file_name_convert=’/u01/app/oracle/oradata/STAND/onlinelog’,’/u01/app/oracle/oradata/PRIME/onlinelog’ SCOPE=SPFILE;
Система изменена.

Конфигурации на стороне резервного сервера: -

Шаг 1. Создание файла паролей

скопируйте файл пароля удаленного входа (orapwprime) с основного сервера базы данных в каталог $ORACLE_HOME/dbs на
резервном сервере базы данных, переименовав его в orapwstand.

[oracle@primary dbs]$ scp orapwprime oracle@192.168.1.25:$ORACLE_HOME/dbs
Пароль oracle@192.168.1.25:
orapwprime 100% 7680 7,5 КБ/с 00:00

oracle@standby dbs]$ mv orapwprime orapwstand

Шаг 2. Изменение параметров в резервной базе данных

В каталоге $ORACLE_HOME/dbs резервной системы создайте файл параметров инициализации с именем initstand.ora,
содержащий один параметр: DB_NAME=prime

[oracle@standby admin]$ cd $ORACLE_HOME/dbs
[oracle@standby dbs]$ cat initstand.ora
db_name=prime

Шаг 3. Создание структуры каталогов в резервной базе данных

[oracle@standby dbs]$ cd $ORACLE_BASE/admin/
[oracle@standby admin]$ mkdir stand
[oracle@standby admin]$ cd stand
[oracle@standby stand]$ mkdir adump pfile dpdump
[oracle@standby standby]$ mkdir -p /u01/app/oracle/oradata/STAND/onlinelog
[oracle@standby standby]$ mkdir -p /u01/ приложение/oracle/oradata/STAND/файл данных

Шаг 4. Запустите резервную базу данных с помощью pfile

[oracle@standby dbs]$ export ORACLE_SID=stand
[oracle@standby dbs]$ sqlplus '/as sysdba'
SQL*Plus: выпуск 12.1.0.2.0, производство, вторник, 12 июня 06:03:47 2018
Авторское право (c) 1982, 2014, Oracle. Все права защищены.
Подключено к бездействующему экземпляру.
SQL> startup pfile=’initstand.ora’ nomount
экземпляр ORACLE запущен.
Общая глобальная область системы 218103808 байт
Фиксированный размер 2922712 байт
Переменный размер 159385384 байт
Буферы базы данных 50331648 байт
Буферы повторного выполнения 5464064 байт

Шаг 5: подключитесь к rman

[oracle@standby dbs]$ export ORACLE_SID=prime
[oracle@standby dbs]$ rman target sys/oracle@prime
Recovery Manager: выпуск 12.1.0.2.0 — производство во вторник июня 12 06:28:27 2018
Авторское право (c) 1982, 2014, Oracle и/или ее дочерние компании. Все права защищены.
подключен к целевой базе данных: PRIME (DBID=2055869989)
RMAN> подключите вспомогательную систему sys/oracle@stand
подключен к вспомогательной базе данных: STAND (не смонтирован)
RMAN> запустите <
выделить канал p1 типа диска;
выделить канал типа p2 диска;
выделить канал типа p3 диска;
выделить канал типа p4 диска;
выделить вспомогательный канал типа s1 диска;
дублировать целевую базу данных для резервной из активной базы данных
spfile
parameter_value_convert ‘prime’,’stand’

set db_name='prime'
set db_unique_name='stand'
set db_file_name_convert='/u01/app/oracle/oradata/PRIME/datafile/','/u01/app/oracle/ oradata/STAND/datafile/'
set log_file_name_convert='/u01/app/oracle/oradata/PRIME/onlinelog/','/u01/app/oracle/oradata/STAND/onlinelog/'
set control_files='/u01/app/oracle/oradata/STAND/onlinelog/standby1.ctl'
set log_archive_max_processes='5'
set fal_client='stand'
set fal_server='prime'
установить standby_file_management='AUTO'
установить log_archive_config='dg_config=(prime,stand)'
установить совместимый='12.1.0.2.0'
установить memory_target='500m'
проверка имени файла;
>
2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22 > 23>
использование управляющего файла целевой базы данных вместо каталога восстановления
выделенный канал: p1
канал p1: SID=54 тип устройства=DISK
выделенный канал: p2
канал p2: SID=42 тип устройства=DISK
выделенный канал: p3
канал p3: SID=53 тип устройства=DISK
выделенный канал: p4
канал p4: SID=50 тип устройства=DISK
выделенный канал: s1
канал s1: SID=23 тип устройства=DISK
Начало дублирования базы данных 12-JUN-18
содержимое сценария памяти:
/> резервное копирование как повторное использование копии
targetfile '/u01/app/oracle/product/12.1.0.2/db_1/dbs/orapwprime' вспомогательный формат
'/u01/app/oracle/product/12.1.0.2 /db_1/dbs/orapwstand' целевой файл
'/u01/app/oracle/product/12.1.0.2/db_1/dbs/spfileprime.ora' вспомогательный формат
'/u01/app/oracle/product/ 12.1.0.2/db_1/dbs/spfilestand.ora';
sql clone "изменить системный набор spfile= "/u01/app/oracle/product/12.1.0.2/db_1/dbs/spfilestand.ora"";
>
выполнение сценария памяти
Начало резервного копирования 12-JUN-18
Завершение резервного копирования 12-JUN-18
оператор sql: alter system set spfile= ”/ u01/app/oracle/product/12.1.0.2/db_1/dbs/spfilestand.ora»
содержимое сценария памяти:
sql clone «alter system set audit_file_dest =
»/u01/app /oracle/admin/stand/adump” comment=
””scope=spfile”;
sql clone «изменить системный набор диспетчеров =
»(ПРОТОКОЛ=TCP) (SERVICE=standXDB)» comment=
»»scope=spfile»;
sql clone "изменить системный набор log_archive_dest_1 =
"location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) db_unique_name=stand" comment=
""scope=spfile";
sql clone "изменить системный набор db_unique_name =
"stand" comment=
""scope=spfile";
sql clone «изменить системный набор db_file_name_convert =
»/u01/app/oracle/oradata/PRIME/datafile/», «/u01/app/oracle/oradata/STAND/datafile/» comment= ””scope=spfile”;
sql clone «изменить системный набор log_file_name_convert =
»/u01/app/oracle/oradata/PRIME/onlinelog/», «/u01/app/oracle/oradata/STAND/onlinelog/» comment= ””scope=spfile”;
sql clone «изменить системный набор control_files =
»/u01/app/oracle/oradata/STAND/onlinelog/standby1.ctl» comment=
»» scope=spfile»;
sql clone «изменить системный набор log_archive_max_processes =
5 comment=
»» scope=spfile»;
sql clone "изменить системный набор fal_client =
"stand" comment=
""scope=spfile";
sql clone «изменить системный набор fal_server =
»prime» comment=
»»scope=spfile»;
sql clone "изменить системный набор standby_file_management =
"AUTO" comment=
""scope=spfile";
sql clone «изменить системный набор log_archive_config =
»dg_config=(prime,stand)» comment=
»»scope=spfile»;
sql clone "изменить системный набор, совместимый =
"12.1.0.2.0" comment=
""scope=spfile";
sql clone "изменить системный набор memory_target =
500m comment=
""scope=spfile";
немедленное выключение клона;
начальный клон nomount;
>
выполнение сценария памяти
оператор sql: alter system set audit_file_dest = ”/u01/app/oracle/admin/stand/adump” comment= ”” scope=spfile
sql Оператор: изменить системный набор диспетчеров = ”(ПРОТОКОЛ=TCP) (СЕРВИС=standXDB)” комментарий= ”” Область=spfile
оператор sql: изменить системный набор log_archive_dest_1 = ”location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) db_unique_name =stand” comment= ”” scope=spfile
оператор sql: alter system set db_unique_name = ”stand” comment= ”” scope=spfile
оператор sql: alter system set db_file_name_convert = ”/u01/app/ oracle/oradata/PRIME/datafile/», ”/u01/app/oracle/oradata/STAND/datafile/” comment= ”” scope=spfile
оператор sql: alter system set log_file_name_convert = ”/u01/app/ oracle/oradata/PRIME/onlinelog/», ”/u01/app/oracle/oradata/STAND/onlinelog/” comment= ”” scope=spfile
оператор sql: alter system set control_files = ”/u01/app/ oracle/oradata/STAND/onlinelog/standby1.ctl” comment= ”” scope=spfile
оператор sql: изменить набор систем log_archive_max_processes = 5 comment= ”” scope=spfile
оператор sql: изменить набор system fal_client = ”stand” comment= ”” scope= spfile
оператор sql: изменить системный набор fal_server = ”prime” comment= ”” scope=spfile
оператор sql: изменить системный набор standby_file_management = ”AUTO” comment= ”” scope=spfile
sql оператор: изменить системный набор log_archive_config = ”dg_config=(prime,stand)” comment= ”” scope=spfile
оператор sql: изменить системный набор совместимый = “12.1.0.2.0” comment= ”” scope=spfile оператор sql: alter system set memory_target = 500m comment= ”” scope=spfile
экземпляр Oracle закрыт
подключен к вспомогательной базе данных (не запущен)
экземпляр Oracle запущен
Общая глобальная область системы 524288000 байт
Фиксированный размер 2926320 байт
Переменный размер 444598544 байт
Буферы базы данных 71303168 байт
Буферы повторного выполнения 5459968 байт
выделенный канал: s1
/>канал s1: SID=22 тип устройства=ДИСК
содержимое сценария памяти:
резервное копирование в виде копии текущего управляющего файла для резервного вспомогательного формата '/u01/app/oracle/oradata/STAND/onlinelog/standby1. ctl';
>
выполнение сценария памяти
Начало резервного копирования 12-JUN-18
канал p1: запуск копирования файла данных
копирование резервного управляющего файла
имя выходного файла= /u01/app/oracle/product/12.1.0.2/db_1/dbs/snapcf_prime.f tag=TAG20180612T064910
канал p1: копирование файла данных завершено, истекшее время: 00:00:01
Резервное копирование завершено в 12 -JUN-18
содержимое сценария памяти:
клон sql 'изменить резервную базу данных монтирования базы данных';
>
выполнение сценария памяти
оператор sql: изменить резервную базу данных при монтировании базы данных
содержимое сценария памяти:
установить новое имя для временного файла 1 на
“/u01 /app/oracle/oradata/STAND/datafile/o1_mf_temp_fkxw4qob_.tmp»;
переключить клонировать все временные файлы;
задайте для файла данных 1 новое имя
“/u01/app/oracle/oradata/STAND/datafile/o1_mf_system_fkxw1toz_.dbf”;
установите для файла данных 3 новое имя
“/u01/app/oracle/oradata/STAND/datafile/o1_mf_sysaux_fkxw0fh2_.dbf”;
установите для файла данных 4 новое имя
“/u01/app/oracle/oradata/STAND/datafile/o1_mf_undotbs1_fkxw3m3q_.dbf”;
задайте для файла данных 6 новое имя
“/u01/app/oracle/oradata/STAND/datafile/o1_mf_users_fkxw3kvr_.dbf”;
резервное копирование как повторное использование копии
вспомогательный формат файла данных 1
файл данных «/u01/app/oracle/oradata/STAND/datafile/o1_mf_system_fkxw1toz_.dbf»
вспомогательный формат 3
«/u01/app/oracle/oradata/STAND/datafile/o1_mf_sysaux_fkxw0fh2_.dbf» файл данных
4 вспомогательный формат
«/u01/app/oracle/oradata/STAND/datafile/o1_mf_undotbs1_fkxw3m3q_.dbf» файл данных 6 вспомогательный формат
“/u01/app/oracle/oradata/STAND/datafile/o1_mf_users_fkxw3kvr_.dbf” ;
sql ‘изменить текущий журнал системного архива’;
>
выполнение сценария памяти
выполнение команды: SET NEWNAME
переименование временного файла 1 в /u01/app/oracle/oradata/STAND/datafile/o1_mf_temp_fkxw4qob_.tmp в управляющем файле
/>выполнение команды: SET NEWNAME
выполнение команды: SET NEWNAME
выполнение команды: SET NEWNAME
выполнение команды: SET NEWNAME
Начало резервного копирования 12-JUN-18
канал p1: начальное копирование файла данных
номер входного файла данных=00001 name=/u01/app/oracle/oradata/PRIME/datafile/o1_mf_system_fkxw1toz_.dbf
канал p2: начальное копирование файла данных
входной файл данных номер файла=00003 name=/u01/app/oracle/oradata/PRIME/datafile/o1_mf_sysaux_fkxw0fh2_.dbf
канал p3: начальное копирование файла данных
номер входного файла данных=00004 name=/u01/app/oracle /oradata/PRIME/datafile/o1_mf_undotbs1_fkxw3m3q_.dbf
канал p4: начало копирования файла данных
номер входного файла данных = 00006 name=/u01/app/oracle/oradata/PRIME/datafile/o1_mf_users_fkxw3kvr_.dbf
имя выходного файла=/u01/a pp/oracle/oradata/STAND/datafile/o1_mf_undotbs1_fkxw3m3q_.dbf tag=TAG20180612T064916
канал p3: копирование файла данных завершено, истекшее время: 00:00:03
имя выходного файла=/u01/app/oracle/ oradata/STAND/datafile/o1_mf_users_fkxw3kvr_.dbf tag=TAG20180612T064916
канал p4: копирование файла данных завершено, истекшее время: 00:00:03
имя выходного файла=/u01/app/oracle/oradata/STAND/ datafile/o1_mf_sysaux_fkxw0fh2_.dbf tag=TAG20180612T064916
канал p2: копирование файла данных завершено, истекшее время: 00:00:56
имя выходного файла=/u01/app/oracle/oradata/STAND/datafile/o1_mf_system_fkxw1toz_. dbf tag=TAG20180612T064916
канал p1: копирование файла данных завершено, прошедшее время: 00:01:07
Резервное копирование завершено 12-JUN-18
оператор sql: изменить текущий системный архив
содержимое сценария памяти:
переключать клонировать файл данных все;
>
выполнение сценария памяти
файл данных 1 переключился на копирование файла данных
копирование входного файла данных RECID=1 STAMP=978589826 имя файла=/u01/app/oracle/oradata/STAND/datafile /o1_mf_system_fkxw1toz_.dbf
файл данных 3 переключен на копирование файла данных
копия входного файла данных RECID=2 STAMP=978589826 имя файла=/u01/app/oracle/oradata/STAND/datafile/o1_mf_sysaux_fkxw0fh2_.dbf
файл данных 4 переключен в копию файла данных
введите копию файла данных RECID=3 STAMP=978589826 имя файла=/u01/app/oracle/oradata/STAND/datafile/o1_mf_undotbs1_fkxw3m3q_.dbf
файл данных 6 переключен на копию файла данных
ввод копия файла данных RECID=4 STAMP=978589826 имя файла=/u01/app/oracle/oradata/STAND/datafile/o1_mf_users_fkxw3kvr_.dbf
Завершенный дубликат базы данных 12-JUN-18
выпущен канал: p1
освобожденный канал: p2
освобожденный канал: p3
освобожденный канал: p4
освобожденный канал: s1

Шаг 6: подключитесь к резервной базе данных

[oracle@standby dbs]$ export ORACLE_SID=stand
[oracle@standby dbs]$ sqlplus '/as sysdba'
SQL*Plus: выпуск 12.1.0.2.0, производство, вторник, 12 июня 06:35:29 2018
Авторское право (c) 1982, 2014, Oracle. Все права защищены.
Подключение к:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 — 64-разрядная рабочая версия
С параметрами секционирования, OLAP, расширенной аналитики и тестирования реальных приложений

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

Шаг 7. Физическая резервная база данных работает правильно

Арун Кумар

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

Мы предполагаем, что на первичном сервере запущена и работает база данных (SID=ip7). Резервная база данных имеет установку Oracle 12cR2, выполненную в том же домашнем расположении оракула, что и основная

Обзор конфигурации

Изменения в основной базе данных

Primary должен работать в режиме архивного журнала. Проверьте режим архивного журнала

Если он не работает в режиме архивного журнала, включите его

Включить принудительное ведение журнала на основном сервере. В Oracle пользователи могут ограничить повторную генерацию для SQL с помощью предложения NOLOGGING. Эта транзакция NOLOGGING будет проблемой для физического резерва. Следовательно, мы принудительно ведем журнал, поэтому даже пользователь использует предложение NOLOGGING, каждый SQL будет входить в систему для повторного выполнения

Управление резервными файлами: мы должны убедиться, что всякий раз, когда мы добавляем/удаляем файл данных в основной базе данных, эти файлы также добавляются/удаляются в резервной базе данных

Создать резервные файлы журнала. Резервные файлы журнала необходимо создать на основном сервере. Эти файлы используются резервной базой данных для хранения повторных операций, полученных из первичной базы данных.

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

Добавьте резервные файлы журналов, убедитесь, что номер группы относится к другой серии, например, в этом случае мы решили начать с 11 и выше. Это помогает легко различать.

Проверьте резервные файлы журнала с помощью приведенного ниже запроса

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

Проверьте параметр уникального имени БД в первичной базе данных. Убедитесь, что в вашей первичной базе данных установлен параметр DB_UNIQUE_NAME для согласованности. Если он не установлен правильно, используйте команду ALTER SYSTEM SET

Создать файл паролей для режима ожидания: это необходимо для целей клонирования. Даже если в папке $ORACLE_HOME/dbs есть один файл паролей, создайте новый с резервным SID

Настроить сеть

Добавить ниже запись tns как для основного, так и для резервного сервера

Обратите внимание на использование SID, а не SERVICE_NAME в записях. Это важно, так как брокеру необходимо будет подключиться к базам данных, когда они не работают, поэтому сервисы не будут доступны

Настроить прослушиватель в основной базе данных: поскольку брокеру необходимо будет подключиться к базе данных, когда она не работает, мы не можем полагаться на автоматическую регистрацию в прослушивателе, поэтому явная запись для базы данных

Настроить прослушиватель в режиме ожидания: поскольку брокеру необходимо будет подключиться к базе данных, когда он не работает, мы не можем полагаться на автоматическую регистрацию в прослушивателе, поэтому явная запись для базы данных

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