Резервное копирование SAP системы

Систему SAP можно представить в виде 3 компонент:

• бинарное SAP ядро,
• профили SAP системы и базы данных,
• файлы базы данных, где располагается бизнес-логика, состоящая из ABAP-программ и настроек (записи настроечных таблиц), и данные-пользователей.

Все компоненты работают на сервере под управлением одной из операционных систем, поддерживаемой компанией SAP AG. Кроме перечисленного есть еще бинарные файлы СУБД (RDBMS), которые обеспечивают доступ к данным, хранящимся в базе данных и осуществляют функции синхронизации, консистентности данных и т.п.

Компоненты SAP системы.

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

• бинарное ядро SAP системы обновляется только при обновлении SAP системы, в другое время в является неизменяемым набором данных,
• профили системы и базы данных изменяются редко, только при изменении параметров SAP системы или базы данных,
• база данных - наиболее динамично изменяющаяся часть системы.

Если не рассматривать уровень операционной системы, то для восстановления SAP системы в случае сбоя необходимо восстановление всех трех компонент. Это можно понять, если прочитать мой пост "Копирование SAP систем - I. Перенос/восстановление".

В зависимости от указанной выше частоты внесения изменений, можно выделить следующие шаги по резервному копированию системы:

• сохранение текущей версии бинарного SAP ядра после каждого обновления системы (которое включает обновление SAP ядра),
• сохранение файлов профилей SAP системы и базы данных после каждого изменения параметров системы. Профили SAP системы обычно загружаются в базу данных и изменяются через транзакцию RZ10. Поэтому копия их в базе данных существует. Но я рекомендую все таки делать копию отдельно. Можно просто в директорию на свою рабочую станцию. Благо файлы небольшого размера. 
• сохранение файлов базы данных я рассмотрю более детально.

База данных ORACLE состоит из нескольких важных частей:

• дата-файлы, в которых хранится вся информация. Располагаются в директориях /oracle/<SID>/sapdataX.
• онлайн-журналы работы базы данных. 4 группы по 2 копии каждого журнала. Директории /oracle/<SID>/origlog<A,B> и /oracle/<SID>/mirrlog<A,B>.
• оффлайн-журналы работы базы данных (если база данных работает в режиме ARCHIVE MODE). Директория /oracle/<SID>/oraarch.
• control-файлы, в которых содержится вся информация о структуре инстанции базы данных. Обычно 3 копии, которые распределены по поддиректориям директории /oracle/<SID>.

Процедура восстановления базы данных, упрощенно, выглядит следующим образом:

1. восстановление дата-файлов,
2. восстановление control-файлов,
3. применение оффлайн-журналов ORACLE (если необходимо).

Рекомендуемый компанией SAP AG цикл резервного копирования базы данных выглядит так:

Рекомендуемый цикл резервного копирования базы данных.

Цикл состоит из 28 дней.
Каждый день рекомендуется делать онлайн ("горячий") бэкап базы данных.
Каждый день необходимо делать две копии оффлайн-журналов ORACLE в разные директории/на разные ленты.
Раз в цикл необходимо делать хотя бы один оффлайн ("холодный") бэкап базы данных.
Раз в неделю обязательная логическая проверка базы данных и проверка одного созданного бэкапа на наличие ошибок чтения.

Для осуществления процедуры резервного копирования компания SAP поставляет набор утилит BR*TOOLs. В частности, brbackup - для резервного копирования дата-файлов, brarchive для копирования оффлайн-журналов ORACLE.
Конфигурационный файл данной утилиты - init<SID>.sap, который располагается в той же директории, что и профайлы ORACLE.

Можно использовать утилиту резервного копирования RMAN, которую предоставляет ORACLE. Или продукты сторонних производителей, например HP DataProtector.

Я всегда считал, что если есть возможно делать оффлайн бэкап базы данных каждый день, то почему бы не делать. И делал. Оффлай бэкап состоит из следующих шагов:

1. Останов базы данных. Сервер приложений SAP продолжает работать, но рабочие процессы теряют соединение с shadow-процессами базы данных.
2. Копия всех дата-файлов и control-файла.
3. Запуск базы данных. Рабочие процессы SAP инстанции восстанавливают соединение до процессов базы данных.

Онлайн бэкап проходит несколько иначе:

1. Первое табличное пространство переводится в специальный режим BEGIN BACKUP.
2. Производится копирование дата-файлов первого табличного пространства.
3. Первое табличное пространство переводится в нормальный режим работы.
4. Шаги 1-3 повторяются для всех табличных пространств базы данных.
5. Создается резервная копия оффлайн-журналов, которые были созданы во время процедуры онлайн бэкапа.

При создании онлайн резервной копии базы данных ORACLE пользователи могут работать с SAP системой, как обычно. При оффлайн - понятное дело, нет.

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

Исходя из этих рассуждений, мне кажется, что стоит следовать рекомендациям компании SAP AG и создавать ежедневные онлайн резервные копии. А оффлайн делать раз в неделю или реже (но минимум раз в цикл).

Подробности про резервное копирование можно найти в курсе SAP ADM505 - Database Administration (Oracle) - Unit 2.

Автор: Шиболов Вячеслав Анатольевич