Систему 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>.
Процедура восстановления базы данных, упрощенно, выглядит следующим образом:
- восстановление дата-файлов,
- восстановление control-файлов,
- применение оффлайн-журналов ORACLE (если необходимо).
Рекомендуемый компанией SAP AG
цикл резервного копирования базы данных выглядит так:
 |
Рекомендуемый цикл резервного копирования базы данных. |
Цикл состоит из 28 дней.
Каждый день рекомендуется делать онлайн ("горячий") бэкап базы данных.
Каждый день необходимо делать две копии оффлайн-журналов ORACLE в разные директории/на разные ленты.
Раз в цикл необходимо делать хотя бы один оффлайн ("холодный") бэкап базы данных.
Раз в неделю обязательная логическая проверка базы данных и проверка одного созданного бэкапа на наличие ошибок чтения.
Для осуществления процедуры резервного копирования компания SAP поставляет набор утилит
BR*TOOLs. В частности,
brbackup - для резервного копирования дата-файлов,
brarchive для копирования оффлайн-журналов ORACLE.
Конфигурационный файл данной утилиты -
init<SID>.sap, который располагается в той же директории, что и профайлы ORACLE.
Можно использовать утилиту резервного копирования RMAN, которую предоставляет ORACLE. Или продукты сторонних производителей, например HP DataProtector.
Я всегда считал, что если есть возможно делать оффлайн бэкап базы данных каждый день, то почему бы не делать. И делал. Оффлай бэкап состоит из следующих шагов:
- Останов базы данных. Сервер приложений SAP продолжает работать, но рабочие процессы теряют соединение с shadow-процессами базы данных.
- Копия всех дата-файлов и control-файла.
- Запуск базы данных. Рабочие процессы SAP инстанции восстанавливают соединение до процессов базы данных.
Онлайн бэкап проходит несколько иначе:
- Первое табличное пространство переводится в специальный режим BEGIN BACKUP.
- Производится копирование дата-файлов первого табличного пространства.
- Первое табличное пространство переводится в нормальный режим работы.
- Шаги 1-3 повторяются для всех табличных пространств базы данных.
- Создается резервная копия оффлайн-журналов, которые были созданы во время процедуры онлайн бэкапа.
При создании онлайн резервной копии базы данных ORACLE пользователи могут работать с SAP системой, как обычно. При оффлайн - понятное дело, нет.
Но недавно я понял, что при создании оффлайн резервной копии базы данных происходит обнуление буферов ORACLE, так как база данных останавливается. И каждое утро, после ночной резервной копии происходит
провал производительности системы до того момента, пока база данных не заполнит буферы данными. Чем больше инстанция и больше буферы, тем больше провал производительности, так как
буферы базы данных играют существенную роль.
Исходя из этих рассуждений, мне кажется, что стоит следовать рекомендациям компании SAP AG и создавать ежедневные онлайн резервные копии. А оффлайн делать раз в неделю или реже (но минимум раз в цикл).
Подробности про резервное копирование можно найти в курсе SAP
ADM505 - Database Administration (Oracle) - Unit 2.
Автор:
Шиболов Вячеслав Анатольевич