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

Примеры создания копий контрольных файлов. БД должна быть смонтирована и открыта для выполнения этой операции.

Идентичная копия в двоичный файл

alter database backup controlfile to 'd: \ora_bck\ctrl_bck.ctl'

Копия в файл трассировки, имя файла дается по умолчанию, расположение –? \admin\orcl9\udump

alter database backup controlfile to trace noresetlogs;

Копия в файл трассировки, имя файла задается вручную, более компактен и удобен.

alter database backup controlfile to trace

as 'd: \ora_bck\ctrl_bck_trc.trc' noresetlogs

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

Получить список файлов, нуждающиеся в восстановлении

COL df# FORMAT 999

COL df_name FORMAT a20

COL tbsp_name FORMAT a10

COL status FORMAT a7

COL error FORMAT a10

SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name,

d.STATUS, r.ERROR, r.CHANGE#, r.TIME

FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t

WHERE t.TS# = d.TS#

AND d.FILE# = r.FILE#

/

Минимальное время простоя. Наибыстрейшее восстановление.

Некоторые рекомендации:

§ Чаще делать резервные копии (использовать горячее резервное копирование);

§ Четко представлять, что пострадало в БД и не делать полное восстановление БД, когда можно восстановить файл или ТП;

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

§ Использовать параллельное восстановление;

§ Используйте все возможные методы резервирования для выбора наиболее быстрого (комбинировать физическое и логическое РКВ).

Повреждение активных журналов повтора

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

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

- Если потеряны журналы повтора неактивной группы, можно использовать команду ALTER DATABASE CLEAR LOGFILE, для пересоздания потерянных журналов. Последние транзакции не теряются.

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

Горячее резервное копирование БД

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

Хотя горячее резервное копирование и можно выполнять в рабочее время, лучше запланировать его на время наименьшей активности пользователей. На это имеются две причины. Во-первых, для резервного копирования физических фай­лов используются команды операционной системы, а они потребляют большую часть доступных системных ресурсов ввода/вывода (что снижает производитель­ность системы для интерактивных пользователей). Во-вторых, во время резервно­го копирования табличных пространств изменяется способ записи транзакций в архивные файлы журналов повторов. При переводе табличного пространства в режим " горячего резервного копирования" процесс DBWR записывает все блоки в кэш данных, принадлежащий любому файлу, который является частью этого таб­личного пространства на диске. Когда блоки считываются в память, а затем изме­няются, они копируются в буфер журнала при их первоначальном изменении. Пока они остаются в кэше буфера, их не копируют повторно в оперативный файл журналов повторов. Это потребует гораздо больше места в каталоге назначения архивированного файла журнала повторов.

Сценарий горячего резервного копирования включает:

1. Резервное копирование файлов данных по табличным пространствам, которое, в свою очередь, включает:

a. Переключение табличного пространства в состояние резервного копи­рования;

б. Резервное копирование файлов данных табличного пространства с помощью команд ОС;

в. Возвращение табличного пространства в его нормальное состояние;

2. Резервное копирование архивных файлов журналов повторов, включающее:

a. Регистрацию файлов, находящихся в каталоге назначения архивных файлов журналов повторов;

b. Резервное копирование архивных файлов журналов повторов, а затем (при желании) их сжатие или удаление

3. Резервное копирование управляющих файлов с помощью команды alter database backup controlfile.

Простейший скрипт выполнения горячего резервного копирования. Создается список команд в файл, который потом выполняется.

set serveroutput on

set trimspool on

set line 500

set head off

set feed off

spool backup.cmd

declare

copy_cmnd constant varchar2(30): = 'cp'; -- Use " ocopy" for NT

copy_dest constant varchar2(30): = '/ora/ora_bck1'; -- C: \BACKUP\ for NT

copy_arc_dest constant varchar2(30): = '/ora/ora_bck1/archive';

dbname varchar2(30);

logmode varchar2(30);

begin

dbms_output.enable(4000);

select name, log_mode

into dbname, logmode

from sys.v_$database;

if logmode < > 'ARCHIVELOG' then

raise_application_error(-20000,

'ERROR: Database must be in ARCHIVELOG mode!!! ');

return;

end if;

dbms_output.put_line('spool backup.'||dbname||'.'||

to_char(sysdate, 'ddMonyy')||'.log');

-- Loop through tablespaces

for c1 in (select tablespace_name ts

from sys.dba_tablespaces)

loop

dbms_output.put_line('alter tablespace '||c1.ts||' begin backup; ');

-- Loop through tablespaces' data files

for c2 in (select file_name fil

from sys.dba_data_files

where tablespace_name = c1.ts)

loop

dbms_output.put_line('HOST '||copy_cmnd||' '||c2.fil||' '||copy_dest);

end loop;

dbms_output.put_line('alter tablespace '||c1.ts||' end backup; ');

end loop;

-- Backup controlfile and switch logfiles

dbms_output.put_line('alter database backup controlfile to trace; ');

dbms_output.put_line('alter database backup controlfile to '||''''||

copy_dest||'control.'||dbname||'.'||

to_char(sysdate, 'DDMonYYHH24MI')||''''||'; ');

dbms_output.put_line('alter system switch logfile; ');

-- Backup archived logs

for c3 in (select name from v$archived_log where dest_id = 1) loop

dbms_output.put_line('HOST '||copy_cmnd||' '||c3.name||' '||copy_arc_dest);

end loop;

dbms_output.put_line('spool off');

end;

/

spool off

set head on

set feed on

set serveroutput off

--и запустить его сразу на выполнение

@backup.cmd

Восстанавление из горячей копии:

- Восстановить файлы данных и архивные логи

- Восстановить управляющий файл, хорошо, если есть двоичная копия

- Смонтировать БД

- Alter database recover using backup controlfile

- Восстановление из архивных логов до упора. Если нет активных журналов повтора, то открыть с опцией RESETLOGS.

Пример восстановления БД

Дано:

§ был создан холодный бэкап БД, работающей в режиме ARCHIVELOG. Потом в БД были сделаны изменения, приведшие к генерации новых архивных журналов повтора;

§ далее были утеряны все файлы данных, кроме активных и архивных журналов повтора;

Дальнейшие действия:

§ Резервируется все, что уцелело, чтобы не усугубить ситуацию;

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

§ при попытке открытия БД получаем:

ERROR at line 1:

ORA-00314: log 2 of thread 1, expected sequence# 1 doesn't match 31

ORA-00312: online log 2 thread 1: 'E: \ORACLE\ORADATA\ORCL9\REDO02.LOG

SQL> archive log list

Database log mode Archive Mode

Automatic archival Enabled

Archive destination E: \oracle\oradata\orcl9\archive2\

Oldest online log sequence 0

Next log sequence to archive 1

Current log sequence 1

Т.е. у нас есть информация в контрольных файлах о последовательности 1 sequence# 1, которая на деле не соответствует действительности, ибо текущие уцелевшие активные журналы повтора указывают на 31-ю последовательность. В данной ситуации можно осуществить полное восстановление данных, т.к. у нас есть в наличии холодная физическая копия, все архивные и активные журналы повтора.

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

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

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

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

ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS ‘имя_файла_бэкапа_контрола’

Трэйс-файл представляет собой скриптик, в котором выполняется команда CREATE CONTROLFILE и команды восстановления. Типа такого:

# Below are two sets of SQL statements, each of which creates a new

# control file and uses it to open the database. The first set opens

# the database with the NORESETLOGS option and should be used only if

# the current versions of all online logs are available. The second

# set opens the database with the RESETLOGS option and should be used

# if online logs are unavailable.

# The appropriate set of statements can be copied from the trace into

# a script file, edited as necessary, and executed when there is a

# need to re-create the control file.

#

# Set #1. NORESETLOGS case

#

# The following commands will create a new control file and use it

# to open the database.

# Data used by the recovery manager will be lost. Additional logs may

# be required for media recovery of offline data files. Use this

# only if the current version of all online logs are available.

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE " MTS" NORESETLOGS ARCHIVELOG

-- SET STANDBY TO MAXIMIZE PERFORMANCE

MAXLOGFILES 5

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 1

MAXLOGHISTORY 226

LOGFILE

GROUP 1 'D: \ORACLE\ORADATA\MTS\REDO01.LOG' SIZE 20M,

GROUP 2 'D: \ORACLE\ORADATA\MTS\REDO02.LOG' SIZE 20M,

GROUP 3 'D: \ORACLE\ORADATA\MTS\REDO03.LOG' SIZE 20M

-- STANDBY LOGFILE

DATAFILE

'D: \ORACLE\ORADATA\MTS\SYSTEM01.DBF',

'D: \ORACLE\ORADATA\MTS\UNDOTBS01.DBF',

'D: \ORACLE\ORADATA\MTS\EXAMPLE01.DBF',

'D: \ORACLE\ORADATA\MTS\TOOLS01.DBF',

'D: \ORACLE\ORADATA\MTS\USERS01.DBF'

CHARACTER SET CL8MSWIN1251

;

# Recovery is required if any of the datafiles are restored backups,

# or if the last shutdown was not normal or immediate.

RECOVER DATABASE

# All logs need archiving and a log switch is needed.

ALTER SYSTEM ARCHIVE LOG ALL;

# Database can now be opened normally.

ALTER DATABASE OPEN;

# Commands to add tempfiles to temporary tablespaces.

# Online tempfiles have complete space information.

# Other tempfiles may require adjustment.

ALTER TABLESPACE TEMP2 ADD TEMPFILE 'D: \ORACLE\ORADATA\MTS\TEMP02.DBF'

SIZE 209715200 REUSE AUTOEXTEND OFF;

# End of tempfile additions.

#

# Set #2. RESETLOGS case

#

# The following commands will create a new control file and use it

# to open the database.

# The contents of online logs will be lost and all backups will

# be invalidated. Use this only if online logs are damaged.

STARTUP NOMOUNT

CREATE CONTROLFILE REUSE DATABASE " MTS" RESETLOGS ARCHIVELOG

-- SET STANDBY TO MAXIMIZE PERFORMANCE

MAXLOGFILES 5

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 1

MAXLOGHISTORY 226

LOGFILE

GROUP 1 'D: \ORACLE\ORADATA\MTS\REDO01.LOG' SIZE 20M,

GROUP 2 'D: \ORACLE\ORADATA\MTS\REDO02.LOG' SIZE 20M,

GROUP 3 'D: \ORACLE\ORADATA\MTS\REDO03.LOG' SIZE 20M

-- STANDBY LOGFILE

DATAFILE

'D: \ORACLE\ORADATA\MTS\SYSTEM01.DBF',

'D: \ORACLE\ORADATA\MTS\UNDOTBS01.DBF',

'D: \ORACLE\ORADATA\MTS\EXAMPLE01.DBF',

'D: \ORACLE\ORADATA\MTS\TOOLS01.DBF',

'D: \ORACLE\ORADATA\MTS\USERS01.DBF'

CHARACTER SET CL8MSWIN1251

;

# Recovery is required if any of the datafiles are restored backups,

# or if the last shutdown was not normal or immediate.

RECOVER DATABASE USING BACKUP CONTROLFILE

# Database can now be opened zeroing the online logs.

ALTER DATABASE OPEN RESETLOGS;

# Commands to add tempfiles to temporary tablespaces.

# Online tempfiles have complete space information.

# Other tempfiles may require adjustment.

ALTER TABLESPACE TEMP2 ADD TEMPFILE 'D: \ORACLE\ORADATA\MTS\TEMP02.DBF'

SIZE 209715200 REUSE AUTOEXTEND OFF;

# End of tempfile additions.

#

Теперь куда-нибудь переносим текущие контрольные файлы, которые нас не устраивают.

Это мы получим при попытке отрыть БД без контрольных файлов:

ORA-00205: error in identifying controlfile, check alert log for more info

А это запись по этому поводу в алерт логе:

ALTER DATABASE MOUNT

Mon Sep 06 12: 17: 58 2004

ORA-00202: Message 202 not found; No message file for product=RDBMS, facility=ORA; arguments: [D: \oracle\oradata\mts\control01.ctl]

ORA-27041: Message 27041 not found; No message file for product=RDBMS, facility=ORA

OSD-04002: unable to open file

O/S-Error: (OS 2) Не удается найти указанный файл.

А потом из ‘имя_файла_бэкапа_контрола’ и пересоздаем контрольные файлы.

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

SQL> startup nomount

ORACLE instance started.

Total System Global Area 101785252 bytes

Fixed Size 454308 bytes

Variable Size 75497472 bytes

Database Buffers 25165824 bytes

Redo Buffers 667648 bytes

SQL>

Теперь из файла вытягиваем команду CREATE CONTROLFILE, все необходимые файлы (в первую очередь самые последние архивные журналы повтора) должны лежать уже на своих местах.

CREATE CONTROLFILE REUSE DATABASE " MTS" RESETLOGS ARCHIVELOG

-- SET STANDBY TO MAXIMIZE PERFORMANCE

MAXLOGFILES 5

MAXLOGMEMBERS 3

MAXDATAFILES 100

MAXINSTANCES 1

MAXLOGHISTORY 226

LOGFILE

GROUP 1 'D: \ORACLE\ORADATA\MTS\REDO01.LOG' SIZE 20M,

GROUP 2 'D: \ORACLE\ORADATA\MTS\REDO02.LOG' SIZE 20M,

GROUP 3 'D: \ORACLE\ORADATA\MTS\REDO03.LOG' SIZE 20M

-- STANDBY LOGFILE

DATAFILE

'D: \ORACLE\ORADATA\MTS\SYSTEM01.DBF',

'D: \ORACLE\ORADATA\MTS\UNDOTBS01.DBF',

'D: \ORACLE\ORADATA\MTS\EXAMPLE01.DBF',

'D: \ORACLE\ORADATA\MTS\TOOLS01.DBF',

'D: \ORACLE\ORADATA\MTS\USERS01.DBF'

CHARACTER SET CL8MSWIN1251

;

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

Последующее восстановление в данной ситуации происходит стандартным образом. После успешного пересоздания контрольных файлов БД уже будет находиться в монтированном состоянии.

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01113: file 1 needs media recovery

ORA-01110: data file 1: 'D: \ORACLE\ORADATA\MTS\SYSTEM01.DBF'

Восстановление БД:

SQL> recover database

ORA-00279: change 26831467 generated at 09/09/2004 12: 51: 18 needed for thread 1

ORA-00289: suggestion: D: \ORACLE\ORADATA\MTS\ARCHIVE\ARC00010.001

ORA-00280: change 26831467 for thread 1 is in sequence #10

Specify log: {< RET> =suggested | filename | AUTO | CANCEL}

auto

ORA-00279: change 26831677 generated at 09/09/2004 13: 45: 23 needed for thread 1

ORA-00289: suggestion: D: \ORACLE\ORADATA\MTS\ARCHIVE\ARC00011.001

ORA-00280: change 26831677 for thread 1 is in sequence #11

ORA-00278: log file 'D: \ORACLE\ORADATA\MTS\ARCHIVE\ARC00010.001' no longer

needed for this recovery

Log applied.

Media recovery complete.

SQL> alter database open;

Database altered.

Восстановление завершено.

Утилита экспорта

Утилита импорта