вторник, 17 июля 2012 г.

Резервное копирование 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.

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


2 комментария:

  1. Привет! Для системы на которой помимо ABAP-стека крутится Java, такого резервного копирования недостаточно. SAP документация рекомендует сохранять некоторые директории и файлы помимо перечисленных, например, / и /usr/sap//JC.../bootstrap + еще несколько. Релевантная статья на help.sap.com называется "Backup and Recovery of the SAP Web Application Server (Java)"

    ОтветитьУдалить
    Ответы
    1. Добрый день!
      Да, это для ABAP стека. С Java стеком глубокого опыта продуктивной работы нет, поэтому большое спасибо за ремарку. :)

      Удалить