Oracle standby database - configure

Главная идея при создании standby экземпляра состоит в том, чтобы с помощью выполнения транзакций, сохраненных в оперативных или архивных журналах основной БД, поддерживать резервную БД в актуальном состоянии (такой механизм для Oracle называется Data Guard или Active Data Guard для случая если standby база открыта н чтение в режиме read only).

Требования к базе:

1. archivelog mode

2. pwdfile

3. force logging

Создание:

1. Перевод базы в режим ARCHIVELOG

SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

2.Проверяем наличие файла паролей

SQL> select * from v$pwfile_users;

Если поле sysdba не равно TRUE, или запрос не вернул данные, то

#orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID password=<ваш пароль> force=y

3. Переводим БД в force loging:

SQL> alter database force logging;

Создаем standby redo logs. Они нужны только на standby базе для записи данных, сохраняемых в redo logs на основной базе. На основной базе они нам понадобятся, когда мы будем переключать ее в режим standby и при этом использовать real-time apply redo. Файлы standby redo logs должны быть такого же размера как и online redo logs. Посмотреть размер online redo logs можно с помощью команды:

SQL> select bytes/1024/1024 from v$log;

Проверяем номера существующих групп:

SQL> select group# from v$logfile;

Добавляем по очереди еще столько же групп standby redo:

SQL> alter database add standby logfile group <следующий номер> '<папка с журналами>/stnbylog01.log' size 50m;

Создадим PFILE и внесем правки в него:

SQL> create pfile='<path>/pfileprod.ora' from spfile;

В сформированный файл внесем следующие строки

db_name='test' — это имя нашей базы (одинаковое для основного и standby экземпляра).

db_unique_name='testprod' — а это уникальное имя для каждого экземпляра, оно не будет изменяться при смене ролей со standby на production. log_archive_config='dg_config=(testprod,teststan)' — определяем имена экземпляров,

между которыми будет происходить обмен журналами.

log_archive_dest_1='SERVICE=stb LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name='teststan' – когда экземпляр является основной базой (PRIMARY_ROLE), мы будем передавать архивные журналы на standby сервер с помощью процесса LGWR. Параметр ASYNC указывает, что данные, сгенерированные транзакцией, не обязательно должны быть получены на standby до завершения транзакции – это не приведет к остановке основной базы, если нет связи со standby.

log_archive_dest_2='LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=testprod' – здесь мы указываем каталог, куда будут локально сохранятся архивные журналы (для основной базы) или куда будут складываться пришедшие с основной базы журналы

(для standby базы).

log_archive_dest_state_1=ENABLE – включаем запись архивных журналов в log_archive_dest_1. Пока мы не создали standby базу, этот параметр можно поставить в значение DEFER, если мы не хотим видеть лишние сообщения о недоступности standby базы в alert_log.

log_archive_dest_state_2=ENABLE – включаем запись архивных журналов в log_archive_dest_2.

fal_client='testprod' – этот параметр определяет, что когда экземпляр перейдет в режим standby, он будет являться клиентом для приема архивных журналов (fetch archive log).

fal_server='teststan' – определяет FAL (fetch archive log) сервер, с которого будет осуществляться передача архивных журналов. Параметры fal_client и fal_server работают только когда база запущена в standby режиме.

standby_file_management='AUTO' – задаем режим автоматического управления файлами в standby режиме. При таком значении параметра все создаваемые или удаляемые файлы основной базы будут автоматически создаваться или удаляться и на standby базе.

В случаи если необходимо разместить standby базу в иных каталогах, то: db_file_name_convert='/oradata_new/test','/oradata/test' – этот параметр указывает,

что в именах файлов данных, которые будут создаваться в standby базе (т.е. когда наш основной экземпляр начнет работать в режиме standby), необходимо изменить пути с '/oradata_new/test' на '/oradata/test'.

log_file_name_convert='/oradata_new/test/archive','/oradata/test/archive' – этот параметр указывает, что в именах журнальных файлов, которые будут создаваться в standby базе, необходимо изменить пути с '/oradata_new/test/archive' на '/oradata/test/archive'.

Перезапускаем базу с использованием данного файла параметров:

SQL> shutdown immediate;
SQL> startup nomount pfile='<path>/pfileprod.ora ';
SQL> create spfile from pfile='<path>/pfileprod.ora';
SQL> shutdown immediate;
SQL> startup;

Добавляем в tnsnames.ora запись о будущем standby сервер (что-то вроде):

TESTSTAN =

(DESCRIPTION = (ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))) (CONNECT_DATA =

(SERVICE_NAME = teststan) )

)

Настройка standby сервера.

На новом сервере устанавливаем туже версию Oracle со всеми патчами, только ПО.

Создаем структуру каталогов, аналогичную основному серверу. Создаем файлы конфигурации listener-а и net service names.

listener:

SID_LIST_LISTENER =

 (SID_LIST = (SID_DESC =

   (SID_NAME = PLSExtProc) (ORACLE_HOME = /oracle)

       (PROGRAM = extproc)

   )

   (SID_DESC = (GLOBAL_DBNAME = teststan)

       (ORACLE_HOME = /oracle)

           (SID_NAME = test)

   )

)

LISTENER =

    (DESCRIPTION_LIST =

        (DESCRIPTION =

              (ADDRESS = (PROTOCOL = TCP)

              (HOST = standbysrv)(PORT = 1521)

        )

(ADDRESS = (PROTOCOL = IPC)

   (KEY = EXTPROC0))

)

)

tnsname:

TEST =

(DESCRIPTION = (ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = standbysrv)(PORT = 1521))

)

(CONNECT_DATA = (SERVICE_NAME = teststan)

)

)

TESTPROD =

(DESCRIPTION = (ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(HOST = productionsrv)(PORT = 1521))

)

(CONNECT_DATA = (SID = test)

)

)

Рестартуем листенер

$ lsnrctl stop
$ lsnrctl start

На основе файла параметров с основной БД (pfileprod.ora) создаем файл параметров для standby базы со следующим содержимым:

db_name='test'

db_unique_name='teststan'

log_archive_config='dg_config=(testprod,teststan)'

log_archive_dest_1='SERVICE=testprod LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name='testprod'

log_archive_dest_2='LOCATION=/oradata/test/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) db_unique_name=teststan'

log_archive_dest_state_1=ENABLE

log_archive_dest_state_2=ENABLE

# эти параметры нам понадобятся для работы только в режиме STANDBY fal_client='teststan'

fal_server='testprod'

standby_file_management='AUTO'

При размещении standby базы в других каталогах также добавляем необходимые параметры:

db_file_name_convert='/oradata/test','/oradata_new/test' log_file_name_convert='/oradata/test/archive','/oradata_new/test/archive'

и сохраняем его с новым именем (например: pfilestand.ora)

Стартуем инстанс:

SQL> startup nomount pfile='<path>/pfilestand.ora';
SQL> create spfile from pfile='<path>/pfilestand.ora';
SQL> shutdown immediate;
SQL> startup nomount;

Разворачиваем standby. На основном сервер:

$ rman target /
rman> connect auxiliary sys@teststan;
rman> duplicate target database for standby nofilenamecheck dorecover;

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

Если все прошло успешно, то переводим систему в режим автоматического применения транзакций на standby базе.

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

SQL> alter system switch logfile;

System altered.

SQL> select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
205

Теперь переходим на standby сервер.

Проверяем состояние базы:

SQL> select name,open_mode,log_mode from v$database;
NAME OPEN_MODE LOG_MODE
--------- ---------- ------------
TEST MOUNTED ARCHIVELOG

SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
-----------------------
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
11 rows selected.

SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
202

Мы видим, что последний примененный лог на standby отстает от основной базы, а также, что процессы ARCH не работают.

Проверяем наличие standby redo logs:

SQL> select * from v$standby_log;

Если их нет – создаем:

SQL> alter database add standby logfile group <номер(тот же, что и на основной БД)> '<папка с журналами>/stnbylog01.log' size 50m;

Переводим standby базу в режим Real-time apply redo:

SQL> alter database recover managed standby database using current logfile disconnect;

Смотрим, что получилось:

SQL> select recovery_mode from v$archive_dest_status;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
MANAGED REAL TIME APPLY
11 rows selected.

SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
205

Все работает.

Если не хотим использовать режим Real-time apply redo, а хотим дожидаться когда будет закончено формирование очередного архивного журнала на основном сервере и он будет передан на standby для применения сохраненных в нем транзакций, то необходимо переводить standby базу в режим redo apply командой:

SQL> alter database recover managed standby database disconnect;

Если что-то пошло не так, то для решения проблемы в первую очередь необходимо остановить «накатку» логов:

SQL> alter database recover managed standby database cancel;

Возможно, что в процессе дуплицирования на standby сервер были переданы не все архивные журналы. Тогда их надо вручную скопировать на standby сервер (в нашем случае в каталог /oradata/test/archive), произвести ручную «накатку»:

SQL> recover standby database;

и после этого опять запустить режим Real-time apply redo:

SQL> alter database recover managed standby database using current logfile disconnect;