Oracle mechanics

26.01.2009

Standby для Oracle Standard Edition с использованием rman

Filed under: Backup and Recovery,Oracle — Игорь Усольцев @ 18:48
Tags: , ,

Практическая реализации рекомендаций документа 333749.1 Alternative for standby/dataguard in standard edition.

Основная БД Oracle Standard Edition 10.2.0.4, 2-node RAC, archivelog, Oracle Enterprise Linux 5.1 x86_64, ASM, SAN, резервная (standby) некластерная бд установлена на сервере с локальным расположение файлов (не-ASM).

Резервное копирование производится следующим образом:

  • ежененедельное резервное копирование файлов данных (full backup)
RMAN>backup full filesperset 4 format '/FULL_%d_%u/';
  • +ежедневное резервное копирование архивированных логов (archivelog backup) с последующим удалением
RMAN> backup filesperset 20 archivelog all delete all input;

Далее приводятся сценарии создания, инкрементального восстановления (наката лог-файлов) и активации резервной БД командами RMAN без использования recovery catalog. Oracle той же версии устанавливается на резервном сервере, без использования ASM, восстанавливать файлы данных планируется на файловую систему linux ext3.

Полное восстановление (без «наката» лог-файлов)

$ rman target / cmdfile restore.rcv trace restore.trc

#restore.rcv
startup nomount;
set dbid=123456789;
run {
set controlfile autobackup format for device type 'SBT_TAPE' to '...';
allocate channel t1 type 'SBT_TAPE' PARMS 'ENV=(...)';
restore controlfile from autobackup;
alter database mount;
}
run {
allocate channel t1 type 'SBT_TAPE' PARMS 'ENV=(...)';
set newname for datafile 1 to  '/u01/oradata/stby/system01.dbf';
...
restore database;
switch datafile all;
}

При необходимости автоматического формирования такого скрипта список файлов данных для формирования команд set newname for datafile… можно получить из восстановленного controlfile сразу после монтирования бд (команда alter database mount) запросом

SQL> select file#, name from v$datafile;

После выполнения любого из скриптов восстановления БД остаётся в состоянии mounted

Инкрементальное восстановление БД («накат» лог-файлов)

Скрипт recover.sh для периодического (по мере готовности инкрементальных бэкапов — backup archivelog all) запуска процедуры наката лог-файлов , запускается по cron

#!/bin/sh
# recover.sh
. /home/oracle/.bash_profile
cd /home/oracle/rman
rman target / cmdfile shutdown.rcv
rman target / cmdfile recover_ctl.rcv trace recover_ctl.trc
sqlplus / as sysdba @make_recover_script.sql
rman target / cmdfile recover_df.rcv trace recover_df.trc

1. Останавливаем бд, находящуюся в состоянии mounted после полного восстановления или очередного наката

#shutdown.rcv
shutdown immediate;

2. Восстанавливаем controlfile из autobackup, монтируем бд, переименовываем файлы данных в controlfile

#recover_ctl.rcv
startup nomount;
set dbid=123456789;
run {
set controlfile autobackup format for device type 'SBT_TAPE' to '/.../';
allocate channel t1 type 'SBT_TAPE' PARMS 'ENV=(...)';
restore controlfile from autobackup;
alter database mount;
sql "begin execute immediate''
alter database rename file
''''+ASM_DISK_GROUP/dbse/datafile/system.256.000''''
to ''''/u01/oradata/stby/system01.dbf'''' '';
exception when others then null; end; ";
...
}

Конструкция sql «begin… появилась из-за Oracle Bug 7207932 — OERI [kgeade_is_0] when renaming a file from ASM to a filesystem, ORA-600 возникает при использовании ALTER DATABASE RENAME FILE, исправлен в версии Oracle 11g. Баг безобидный в том смысле, что несмотря на ошибку операция переименования файла проходит, поэтому в файле PL/SQL блоке ошибки можно проигнорировать.

3. С использованием SQL запроса из восстановленного controlfile готовим скрипт наката до последних архивированных лог-файлов (из v$backup_archivelog_details) для исключения ошибок при автоматическом накате

# make_recover_script.sql
SET NEWPAGE 0
SET SPACE 0
SET LINESIZE 80
SET PAGESIZE 0
SET ECHO OFF
SET FEEDBACK OFF
SET VERIFY OFF
SET HEADING OFF
SET MARKUP HTML OFF SPOOL OFF
set serveroutput on
spool recover_df.rcv
exec dbms_output.put_line('run {');
exec dbms_output.put_line('allocate channel t1 type ''SBT_TAPE'' PARMS ''ENV=(...)'';');
select'
SET UNTIL SEQUENCE = '||max(sequence#)||' THREAD = '||thread#||';'
from v$backup_archivelog_details group by thread#;
exec dbms_output.put_line('recover database DELETE ARCHIVELOG;');
exec dbms_output.put_line('}');
spool off
exit

4. Получившийся скрипт инкрементального восстановления бд восстанавливает файлы данных до состояния на момент последнего бэкапа

# recover_df.rcv
run {allocate channel t1 type 'SBT_TAPE' PARMS 'ENV=(...)';
SET UNTIL SEQUENCE = 12345 THREAD = 1;
SET UNTIL SEQUENCE = 12345 THREAD = 2;
recover database DELETE ARCHIVELOG;
}

Для экономии дискового пространства пробовал использовать опцию MAXSIZE

RMAN> recover database DELETE ARCHIVELOG MAXSIZE 3G;
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 01/22/2009 17:37:27
RMAN-06561: available space must be larger than 3071870 kb

ошибка показалась странной, по моему обращению специалисты поддержки Oracle дали следующий комментарий

For RAC databases we will need space to accomodate recovering using all threads. From the RMAN debug trace we see the size of the logs in thread 1 … (1887390208) is added to the size of the archivelogs for thread 2 (1887389184), and that adds up to (3775779392 = 3687284K). Since current maxsize was set to 3G which is 3145728K, then we still need 541556 Kbytes.

Т.е. при восстановлении кластерной бд требуется дисковое пространство, достаточное для размещения всех лог файлов всех кластерных нодов, что делает использование опции MAXSIZE команды recover database delete archivelog бесполезной в смысле экономии места на диске

Открытие БД в режиме чтения-записи

$ rman target / cmdfile shutdown.rcv
$ rman target / cmdfile open_resetlogs.rcv

скрипт open_resetlogs.rcv, кроме прочего, пересоздаёт online redolog файлы и временное табличное пространство

# open_resetlogs.rcv
startup mount;
sql "begin for reco in (select group# from v$log)
loop execute immediate ''ALTER DATABASE DROP LOGFILE GROUP ''
||reco.group#; end loop; end;";
sql "ALTER DATABASE ADD LOGFILE GROUP 1 size 100M";
...
alter database open resetlogs;
sql "create temporary tablespace TEMP_STBY
tempfile ''/u01/oradata/stby/temp.dbf'' size 50M autoextend on maxsize 4G";
sql "alter database default temporary tablespace TEMP_STBY";

После открытия в каталоге bdump появляются трейсы типа stby_dbw0_1234.trc

2009-02-02: [ OCROSD]utgdv:2:ocr loc file cannot be opened
2009-02-02: [ OCROSD]utopen:1: Couldnt find ocr,[ocrmirror] location in config file
2009-02-02: [ OCRRAW]proprinit: Could not open raw device
2009-02-02: [ default]a_init:7!: Backend init unsuccessful : [33]
2009-02-02: [ CSSCLNT]clsssinit: error(33 ) in OCR initialization kgxgncin: CLSS init failed with status 21

Сообщения вызваны Oracle Bug 5938326 CLUSTER STACK ERRORS THROWN IN NON-CLUSTER ENVIRONMENT. Из разъяснений специалистов Oracle Support

This is because queries against the v$ASM_* views and running dbms_stats.gather_fixed_objects_stats() will trigger the rdbms to execute ASM related functions to see if it can talk to ASM.
ASM needs CSS and if CSS is not running then these warnings and trace files will be generated.
The bug will be fixed in release in 10.2.0.5 patchset & release 11.1.

Cистемные обзоры V$_ASM_* при этом пустые :(

SQL> select * from v$asm_diskgroup;
no rows selected

Естественно, что после операции OPEN RESETLOGS для продолжения использования бд в качестве STANDBY (с накатом лог-файлов) потребуется восстановить файлы фанных заново (см. Полное восстановление)

Открытие БД в режиме только чтения (READ ONLY)

$ rman target / cmdfile shutdown.rcv
$ rman target / cmdfile open_readonly.rcv

Может быть использован для тестирования целостности БД, отчётности и т.д. После этой операции можно продолжать накат лог-файлов БД (скрипт recover.sh), восстановления БД не требуется.

# open_readonly.rcv
startup mount;
SQL "alter database open read only";
Дополнение. Проверка состояния восстановленной бд

Кроме логов выполнения скриптов restore.rcv и recover.sh, для проверки статуса восстановления резервной бд можно использовать следующие запросы

Проверка CHECKPOINT_CHANGE и FUZZY-состояния* в заголовках файлов данных

SQL> col cc format a20
SQL> col name format a40
SQL> select file#, name, to_char(CHECKPOINT_CHANGE#) cc, fuzzy
from v$datafile_header;
FILE# NAME                           CC         FUZZY
-----------------------------------------------------
 1    /u01/oradata/stby/system01.dbf 1234567890 NO

Проверка информации о CHECKPOINT_CHANGE файлов данных в control file

SQL> select file#, name, to_char(CHECKPOINT_CHANGE#) cc
from v$datafile;
FILE# NAME                           CC
--------------------------------------------------
 1    /u01/oradata/stby/system01.dbf 1234567899

Проверка на отсутствие файлов данных в статусе BACKUP (STATUS=ACTIVE)

SQL> SELECT DISTINCT (STATUS) FROM V$BACKUP;
STATUS
------------------
NOT ACTIVE

Проверка, требуется ли при следующем открытии бд операция OPEN RESETLOGS, в нашем случае OPEN_RESETLOGS=REQUIRED — правильный ответ

SQL> select OPEN_RESETLOGS from V$DATABASE;
OPEN_RESETL
-----------
REQUIRED

*) «fuzzy file — файл данных, содержащий блоки с SCN (system change number) больше SCN заголовка файла данных (v$datafile_header.checkpoint_change#). Fuzzy files возможны, поскольку процесс database writer не обновляет SCN в заголовке файла данных при каждой записи блока. Например, такое происходит, когда Oracle обновляет файл данных, находящийся в backup mode. Восстановленный fuzzy file всегда требует операции восстановления (media recovery

Tanel Poder: FUZZY bit в заголовке файла данных означает, что могли быть записи в файл данных после последней операции checkpoint… Поэтому любой online read-write файл данных должен быть fuzzy, поскольку в нём могут изменяться блоки. Это первая вещь, которая проверяется при открытии файлов данных и, если файл данных fuzzy, смотрим значение checkpoint_change# и получаем SCN начиная с которого нужно делать восстановление (applying redo).

Механизм incremental checkpointing (Checkpoint Process (CKPT) записывает SCN не реже, чем раз в 3 секунды в control file, но не в заголовки файлов данных — для скорости) оптимизирует процесс восстановления — при наличии current controlfile, данные об SCN файлов данных могут быть считаны из controlfile (v$datafile.checkpoint_change#) и процесс восстановления может быть начат от этих данных — уменьшая время восстановления.

Добавить комментарий »

Комментариев нет.

RSS feed for comments on this post. TrackBack URI

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Создайте бесплатный сайт или блог на WordPress.com.

%d такие блоггеры, как: