Меню

Пошаговое руководство по конфигурированию для аварийного восстановления

|

В этой статье Мухаммад Абдул Джамиль описывает шаги для конфигурирования сервера аварийного восстановления в формате резервной базы данных продуктивного сервера SAP в ландшафте SAP. В случае сбоя основной базы данных выполняется переход к резервной базе данных.

Ключевое понятие

После приобретения SAP ERP с Oracle компании могут загрузить Oracle на веб-сайте service.sap.com и использовать утилиту Data Guard. С помощью этого программного обеспечения/утилиты можно создать резервную базу данных для использования в случае сбоя продуктивной базы данных.

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

В статье показано, как сконфигурировать такой план аварийного восстановления. В этом сценарии инстанция основной базы данных расположена на первом хосте, который является продуктивным сервером. Его база данных работает в открытом режиме (open mode) и полностью доступна для всех пользователей SAP. Резервная инстанция базы данных работает на втором хосте в режиме монтажа (mount mode), и в нее постоянно перемещаются данные из основной инстанции.

Примечание.
Режим монтажа в базе данных Oracle означает, что база данных не является открытой.

Резервная база данных немедленно или с незначительной задержкой отражает все изменения данных в основной инстанции. Для этого файлы журнала изменений Oracle (offline redo log), созданные в системе основной базы данных, автоматически перемещаются из основной базы данных в резервную.

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

Все файлы журналов изменений резервного хоста уже применены, поэтому затратная повторная загрузка файлов не требуется. Может потребоваться вмешательство администратора SAP-базиса или базы данных Oracle в зависимости от типа изменений.
 

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

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

Предпосылки

Следует создать копию продуктивного сервера SAP. Дополнительная информация для этого содержится в статье данного автора Пошаговое руководство по обновлению системы на сервере обеспечения качества. (Дополнение к указанной выше статье: Уровни программного обеспечения и программных вставок Oracle должны быть идентичны на обоих серверах перед копированием файла данных SAP.) Кроме того, на сервере должна быть установлена база данных Oracle. Data Guard является частью этой базы данных.

Конфигурирование аварийного восстановления

В следующей конфигурации аварийного восстановления предусмотрено две системы. Одна система является исходной, это продуктивный сервер SAP (основная база данных), а вторая система является целевой, это сервер аварийного восстановления (резервная база данных). Этим системам присваиваются следующие IP-адреса:

Имя системы:
Исходная система: 172.20.0.1
Целевая система: 172.20.0.2

Имя базы данных:
Db_name: PRD
Db_name: PRD

Уникальные имена баз данных:
Db_unique_name= PRD
Db_unique_name= DRP

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

Теперь необходимо изменить параметры базы данных в исходной и целевой системах. Выполните вход в обе системы по очереди и внесите требуемые изменения. Выполните вход в базу данных целевой системы с помощью следующей команды 1. Run > sqlplus / sysdba
Команда 1 [вход в базу данных SQL]

Можно изменить параметр db_unique_name в целевой системе с помощью следующей команды 2.

SQL> alter system set db_unique_name=DRP Scope=spfile;
Команда 2 [изменение уникального имени базы данных]

Исходная система

В данном случае аварийное восстановление конфигурируется между исходной системой и целевой системой. Таким образом, необходимо установить параметры в исходной системе. Выполните вход в исходную систему и выполните следующие команды. (Можно проверить статус принудительной регистрации (force logging) с помощью команды 3.)

Режим принудительной регистрации относится к постоянным атрибутам базы данных. Если табличное пространство или таблица созданы или изменены в force logging, все изменения в табличном пространстве попадают в журналы изменений и используются при восстановлении.
[end note]

SQL>select force_logging from v$database;
Команда 3 [проверка статуса принудительной регистрации]

Если режим принудительной регистрации не активирован, его можно активировать посредством команды 4.

SQL>alter database force logging;
Команда 4 [активация принудительной регистрации]

Теперь следует присвоить уникальные имена баз данных в обеих системах (PRD и DRP), которые будут частью Data Guard. Это можно выполнить с помощью команды 5. Data Guard между PRD и DRP конфигурируется следующим образом:

SQL>alter system set log_archive_config='DG_CONFIG=(PRD,DRP)';
Команда 5 [конфигурирование указанных систем Data Guard]

Необходимо определить локальный путь архивных файлов, который будет действителен для всех журналов или ролей в PRD. Это можно настроить с помощью команды 6. К архивным файлам относятся файлы, которые переносятся из продуктивной системы в резервную систему.

SQL>alter system set log_archive_dest_1='LOCATION=G:\oracle\PRD\oraarch\PRDarch VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=PRD';
Команда 6 [настройка целевого адреса архива журналов для системы PRD]

Кроме того, следует настроить целевой адрес архива журналов для целевой системы. Для этого используется команда 7.

SQL>alter system set log_archive_dest_2='SERVICE=DRP ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=DRP';
Команда 7 [настройка целевого адреса архива журналов для системы DRP]

Теперь активируйте указанные выше параметры с помощью команд 8 и 9. Это параметры, установленные при выполнении команд 6 и 7.

SQL>alter system set log_archive_dest_state_1=ENABLE;
Команда 8 [активация целевого адреса архива журналов 1]

SQL>alter system set log_archive_dest_state_2=ENABLE;
Команда 9 [активация целевого адреса архива журналов 2]

В этой конфигурации система DRP является целевой системой, в которую будут перенесены архивы; она называется сервером переноса архивных журналов (FAL). . . Настройте сервер FAL с помощью команды 10.

SQL>alter system set FAL_SERVER='DRP';
Команда 10 [настройка сервера FAL]
 

Примечание.
Термин "настроить" означает установить значения параметров PRD и DRP.

Исходной системой является клиент FAL для целевой системы. Его можно настроить с помощью команды 11.

SQL>alter system set FAL_CLIENT='PRD';
Команда 11 [настройка клиента FAL]

Можно установить параметр инициализации LOG_ARCHIVE_MAX_PROCESSES для определения до 10 процессов ARCn (операция, в которой фоновый процесс ARCn копирует журналы изменений по автономным целевым адресам), которые будут запускаться при запуске инстанции.

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти