В структуре базы данных ORACLE, которая представлена на Рис.1, можно выделить 3 крупные части:

• процессы,
• области в оперативной памяти,
• файлы на жестком диске.

Рис. 1. Структура СУБД ORACLE.

Выделяют 2 вида процессов. Первый - это фоновые процессы, которые запускаются всегда при запуске экземпляра (инстанции) и выполняют огромное количество операций по обслуживанию базы данных, очистки, журналированию, восстановлению и так далее. Второй тип - это, так называемые, "shadow processes", которые создаются в количестве равном количеству рабочих процессов SAP инстанций, работающих с этим экземпляром базы данных. Они-то и обрабатывают SQL запросы к базе данных со стороны SAP системы.

Также еще есть, отдельно стоящий, процесс сетевого слушателя (ORACLE Listener), который "слушает" определенный сетевой порт (в случае SAP системы, по умолчанию это 1527) и обеспечивает соединение к экземпляру базы данных извне.

Области в оперативной памяти являются буферами того или иного назначения и обеспечивают приемлемый уровень быстродействия при работе с базой данных.

Ну и наконец, файлы базы данных:

• Профиль - это файл, который используется для инициализации экземпляра базы данных при запуске. Содержит набор параметров и указатели на важные директории базы данных.
  Хранится в файле: /oracle/<SID>/<ora_version>/database/SPFILE<SID>.ORA.

• Контрольный файл базы данных, который содержит структуру базы данных. Очень важен для целостности экземпляра, поэтому хранится в 3 экземплярах. Одну копию можно обнаружить тут - /oracle/<SID>/origlogA/cntrl/CNTRL<SID>.DBF.

• Самый большой объем занимают файлы с данными, которые логично распределены между табличными пространствами экземпляра. По-умолчанию, расположены в директориях вида /oracle/<SID>/sapdataX.

• Журнальные файлы ORACLE делятся на онлайн и оффлайн. Остановимся на них подробнее.

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

По-умолчанию, при создании экземпляра базы данных для SAP системы организуется 4 группы журнальных файлов размером по 50 Мб с дублированием (зеркалированием) каждого. Онлайн журнальные файлы распределены по 4 директориям:

/oracle/<SID>/origlogA/
             LOG_G11M1.DBF
             LOG_G13M1.DBF
/oracle/<SID>/origlogB/
             LOG_G12M1.DBF
             LOG_G14M1.DBF
/oracle/<SID>/mirrlogA/
             LOG_G11M2.DBF
             LOG_G13M2.DBF
/oracle/<SID>/mirrlogB/
             LOG_G12M2.DBF
             LOG_G14M2.DBF

Здесь видно 4 группы G11, G12, G13, G14 с двумя копиями M1 и M2 в каждой.

Данные директории рекомендуется распределять по разным файловым системам с RAID1 или RAID1+0  для приемлемого уровня отказоустойчивости и быстродействия.

Запись вонлайн журнальные файлы производится по кругу (Рис. 2).

Рис. 2. Запись в онлайн журнальные файлы ORACLE.

После того, как будет полностью заполнен онлайн журнал группы G11, начинается запись в журнал группы G12 и так далее, пока не дойдет до группы G14. После использования последней группы, процесс записи должен переключиться на первый журнал и начать запись в него. И тут есть 2 варианта. Дело в том, что экземпляр ORACLE может работать в двух режимах:

• ARCHIVELOG MODE,
• NOARCHIVELOG MODE,

В первом случае, если база данных находится в режиме ARCHIVELOG. Прежде чем процесс записи в онлайн журналы сможет удалить данные и начать писать в журнал, журнальный файл должен быть сохранен в специальную директорию. По-умолчанию, это директория /oracle/<SID>/oraarch (до версии базы данных ORACLE 9i это была директория /oracle/<SID>/saparch). Сохраненные файлы имеют порядковый номер и называются оффлайн журнальными файлами ORACLE. Имеют следующий вид:

<SID>ARCHARC04761_0696002781.001

Это и есть некая история операций с данными во временном срезе, с помощью которой можно проводить восстановление