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

Темы, предлагаемые к рассмотрению

На сегодняшний день Oracle позволяет реализовать 4 варианта резервирования:
- Backup
- Failover
- StandBy
- Remote Mirroring

3 варианта обеспечения отказоустойчивости системы:
- Real Application Cluster
- Oracle Fail Safe (Cold Failover Cluster)
- Standby Data Guard

Ну что, господа админы? Go Ahead! ?

Добавлено (08.04.2010, 12:03)
---------------------------------------------
Backup
Бэкап представляет собой периодическое копирование файлов, составляющих физическую структуру БД. Предпочтительно хранить полученные копии на отдельном хранилище, удаленном сервере, в крайнем случае - на отдельном диске сервера БД. Суть данной рекомендации очевидна: при крахе сервера, выходе из строя оборудования и пр., наличие копии на независимом хранилище позволяет избежать потери данных.
Существенный недостаток метода - возможность восстановления данных на момент последней резервной копии. Естественно, чем чаще бэкап создается, тем лучше, однако его создание напрямую связано с изменением регламента работы БД.
Содание бэкапа возможно осуществить:
1. Средствами ОС
2. Утилитой Recovery Manager (RMAN) (входит в состав Standart и Enterprise Edition)
3. Утилитами экспорта/импорта данных - DataPump (Oracle10g, Oracle11g) или exp/imp для более ранних версий (входит в состав Standart и Enterprise Edition)
4. Oracle Secure Backup. (Приобретается опционно)

Бэкап средствами ОС
Необходимо скопировать следующие файлы
1. Файлы табличных пространств.
2. Управляющие файлы.
3. Файлы журналов транзакций.
4. Файлы конфигурации.

Давайте теперь их найдем, эти файлы?

Добавлено (08.04.2010, 14:26)
---------------------------------------------
коннектимся с правами sysdba
demo-zone1.oracle: ~> sqlplus sys/*** as sysdba (для примера БД на Solaris10)

SQL*Plus: Release 10.2.0.1.0 - Production on Thu Apr 8 12:55:46 2010
Copyright © 1982, 2005, Oracle. All rights reserved.

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning and Data Mining options

SQL>

Нас интересуют собственно только файлы и пути к ним. Поэтому делаем следующее
Для файлов данных:

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/data/mndemo/IDX/idx01.dbf
/data/mndemo/IDX/idx02.dbf
/data/mndemo/IDX/idx03.dbf
/data/mndemo/IDX/idx04.dbf
/data/mndemo/IDX/idx05.dbf
/data/mndemo/users02.dbf
/data/mndemo/users03.dbf
/data/mndemo/users04.dbf
/data/mndemo/users05.dbf
/u/oracle/data1/mndemo/part01.dbf
/u/oracle/data1/mndemo/sysaux.dbf
/u/oracle/data1/mndemo/system01.dbf
/u/oracle/data1/mndemo/undotbs01.dbf
/u/oracle/data1/mndemo/users01.dbf

14 rows selected.

Для Windows(далее виндовский вариант будет выделяться серым)эти пути могут выглядеть так
NAME
--------------------------------------------------------------------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\MNADMIN\DATAFI LE\O1_MF_SYSTEM.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\MNADMIN\DATAFILE\O1_MF_UNDOTBS1.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\MNADMIN\DATAFILE \O1_MF_SYSAUX.DBF
D:\ORACLE\PRODUCT\10.2.0\ORADATA\MNADMIN\DATAFILE\O1_MF_CATTBS.DBF

Для управляющих файлов

Добавлено (08.04.2010, 14:32)
---------------------------------------------
SQL> select name from v$controlfile;

NAME
--------------------------------------------------------------------------------
/u/oracle/data1/mndemo/control01.ctl
/data/mndemo/control02.ctl
/data/mndemo/control03.ctl

А можно и так

SQL> SELECT value FROM v$parameter
WHERE name = 'control_files';

VALUE
--------------------------------------------------------------------------------
/u/oracle/data1/mndemo/control01.ctl, /data/mndemo/control02.ctl, /data/mndemo/c
ontrol03.ctl

NAME
-------------------------------------------------------------------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\MNADMIN\CONTROLFILE\ O1_MF.CTL

Для файлов журналов (журналы повторного выполнения redo log)

SQL> select member from v$logfile;

MEMBER
--------------------------------------------------------------------------------
/u/oracle/data1/mndemo/red01a.log
/u/oracle/data1/mndemo/red01b.log
/u/oracle/data1/mndemo/red02a.log
/u/oracle/data1/mndemo/red02b.log
/u/oracle/data1/mndemo/red03a.log
/u/oracle/data1/mndemo/red03b.log

6 rows selected.

MEMBER
-----------------------------------------------------------------------------
D:\ORACLE\PRODUCT\10.2.0\ORADATA\MNADMIN\ONLINELOG\O1 _MF_1_5RX2212X_.LOG
D:\ORACLE\PRODUCT\10.2.0\ORADATA\MNADMIN\ONLINELOG\O1_MF_2_5RX222VT_.LOG
D:\ORACLE\PRODUCT\10.2.0\ORADATA\MNADMIN\ONLI NELOG\O1_MF_3_5RX224SW_.LOG

Примечание: рассматривается ситуация, когда база работает в режиме NO ARCHIVELOG. Про ARCHIVELOG поговорим чуть позже

Добавлено (08.04.2010, 14:56)
---------------------------------------------
Конфигурационные файлы
Параметры инициализации.
Файл: Init.ora
.../admin/%SID%/pfile/init.ora
Сетевые настройки.
Файлы: listener.ora, tnsnames.ora, sqlnet.ora.
.../%HOME_DIR%/%SID%/NETWORK/ADMIN/
• Файлы паролей.
.../%HOME_DIR%/%SID%/dbs/

Добавлено (08.04.2010, 15:45)
---------------------------------------------
Вроде все нашли. Теперь можно приступать к копированию. Вот тут мы и сталкиваемся с главным минусом такого бэкапа: Бд необходимо погасить
Поэтому подобный бэкап делается строго регламентированно и неприменим для БД, которые должны постоянно находиться on-line

И тем не мене. Гасим БД:
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>

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

Прежде чем продолжить, давайте все-таки переведем базу в режим архивации журналов повторного выполнения. А что такое эти журналы? Ну тут следует просто процитировать гуру (кто еще не знает, так это Том Кайт http://ru.wikipedia.org/wiki/Кайт,_Том )

Файлы журнала повторного выполнения

Файлы журнала повторного выполнения принципиально важны для базы данных Oracle. Это журналы транзакций базы данных. Они используются только для восстановления при сбое экземпляра или носителя или при поддержке резервной базы данных на случай сбоев. Если на сервере, где работает СУБД, отключится питание и вследствие этого произойдет сбой экземпляра, для восстановления системы в состояние, непосредственно предшествующее отключению питания, сервер Oracle при повторном запуске будет использовать оперативные журналы повторного выполнения. Если диск, содержащий файлы данных, полностью выйдет из строя, для восстановления резервной копии этого диска на соответствующий момент времени сервер Oracle, помимо оперативных журналов повторного выполнения, будет использовать также архивные. Кроме того, при случайном удалении таблицы или какой-то принципиально важной информации, если эта операция зафиксирована, с помощью оперативных и архивных журналов повторного выполнения можно восстановить данные из резервной копии на момент времени, непосредственно предшествующий удалению.

Практически каждое действие, выполняемое в СУБД Oracle, генерирует определенные данные повторного выполнения, которые надо записать в оперативные файлы журнала повторного выполнения. При вставке строки в таблицу конечный результат этой операции записывается в журналы повторного выполнения. При удалении строки записывается факт удаления. При удалении таблицы в журнал повторного выполнения записываются последствия этого удаления. Данные из удаленной таблицы не записываются, но рекурсивные SQL-операторы, выполняемые сервером Oracle при удалении таблицы, генерируют определенные данные повторного выполнения. Например, при этом сервер Oracle удалит строку из таблицы SYS.OBJ$, и это удаление будет отражено в журнале.

Некоторые операции могут выполняться в режиме с минимальной генерацией данных повторного выполнения. Например, можно создать индекс с атрибутом NOLOGGING. Это означает, что первоначальное создание этого индекса не будет записываться в журнал, но любые инициированные при этом рекурсивные SQL-операторы, выполняемые сервером Oracle, — будут. Например, вставка в таблицу SYS.OBJ$ строки, соответствующей индексу, в журнал записываться не будет. Однако последующие изменения индекса при выполнении SQL-операторов INSERT, UPDATE и DELETE, будут записываться в журнал.

Добавлено (12.04.2010, 10:34)
---------------------------------------------
Переход в режим ARCHIVELOG
Прежде всего на всякий случай убедимся, что режим ARCHIVELOG не активирован (мало ли :D). Как мы помним, база была погашена. Запустим ее в обычном режиме:
SQL> startup
ORACLE instance started.

Total System Global Area 876609536 bytes
Fixed Size 2024720 bytes
Variable Size 331352816 bytes
Database Buffers 536870912 bytes
Redo Buffers 6361088 bytes
Database mounted.
Database opened.

Проверяем режим работы
SQL> select log_mode from v$database;

LOG_MODE
------------
NOARCHIVELOG

Снова гасим БД. Вносим необходимые правки в init.ora

log_archive_dest_1 = "location=/data/mndemo/arch" - путь к файлам архива (можно указать до 10 разных путей)
log_archive_dest_state_1 = enable - состояние направления архивирования (открыто/закрыто)
log_archive_format = arch_mndemo_%t_%s_%r.arc - формат файлов архива

Теперь запускаем экземпляр, монтируем базу, но не открываем ее:

SQL> startup mount
ORACLE instance started.
Total System Global Area 876609536 bytes
Fixed Size 2024720 bytes
Variable Size 331352816 bytes
Database Buffers 536870912 bytes
Redo Buffers 6361088 bytes
Database mounted.

Переводим базу в режим архивирования файлов журналов повторного выполнения

SQL> alter database archivelog;
Database altered.

Производим проверку состояния

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /data/mndemo/arch
Oldest online log sequence 257
Next log sequence to archive 259
Current log sequence 259

Открываем базу для дальнейшей работы

SQL> alter database open
Database altered.