Как настроить резервное копирование базы данных на магнитную ленту

В 2012 году я опубликовал пост "Резервное копирование SAP системы", в котором я представил SAP систему в виде трех компонент (рис. 1):

• бинарное SAP ядро,
• профили SAP системы и базы данных,
• файлы базы данных.

Рис. 1. Технические компоненты SAP системы.

Все компоненты важны для работы системы, а в случае сбоя необходимо их восстановление. Из всех трёх самой главной частью является база данных, в которой SAP сконцентрировал все данные, какие было возможно: данные системы, настройки, учетные записи пользователей, ABAP-программы и т.д. Остальные компоненты можно заменить: бинарное ядро скачать с сайта поддержки, профайлы восстановить, скопировав с соседней системы и внеся поправки. База данных же индивидуальна и хранится только у вас.

SAP система предоставляет набор утилит для администрирования базы данных. Этот набор утилит называется BR*Tools (ранее SAPDBA) (статьи на эту тему: часть 1, часть 2). Помимо прочего в набор входят 2 утилиты для создания резервных копий: brbackup и brarchive. Как можно догадаться из имен утилит, первая предназначена для резервирования файлов базы данных, а вторая для журнальных файлов Oracle (про журнальные файлы я писал тут и тут).

Файл настройки утилит администрирования базы данных с именем init<SID>.sap находится в директории /oracle/<SID>/<DB_vers>/dbs/ (для ОС Unix) и /oracle/<SID>/<DB_vers>/database/ (для ОС MS Windows).

Для создания резервных копий базы данных в промышленных системах наиболее популярное решение это использование магнитных лент. Плюсы их в том, что можно легко разделять бэкапы по лентам, маркировать их и содержать в отдельном несгораемом шкафу. Скорости записи и объемы сохраняемых данных постоянно растут, по надежности, я думаю, они не уступают жестким дискам.

Обычно ленты используются в виде пула (набора лент), отдельно для файлов данных, отдельно для оффлайн журналов Oracle. Чтобы работать с магнитными лентами, операционная система должна видеть ваши устройства для чтения/записи на ленты.

В файле настройки утилит базы данных от SAP важны следующие строки:

backup_mode = all  
# Описывает какие компоненты базы данных добавлять в резервную копию.

backup_type = offline 
# Как выполнять резервную копию: с остановом базы данных (offline) или нет (online). Подробности тут.

backup_dev_type = tape
# Указывается тип устройства для резервных копий, в данном случае, это лента.

compress = no
# Сжимать резервированные данные (yes) или нет (no), можно использовать аппаратное сжатие самой ленточной библиотеки (hardware) или утилиту brtools (brtools).

tape_copy_cmd = dd
# Какую команду использовать для копирования (cpio, cpio_gnu) или (dd, dd_gnu). Я предпочитаю dd.

cpio_flags = -ovB
cpio_in_flags = -iuvB
# Ключи для команды cpio, важны, если указана именно она в предыдущем параметре.

dd_flags = "obs=64k bs=64k"
dd_in_flags = "ibs=64k bs=64k"
# Входные и выходные ключи для команды dd. Отличаются для Windows и Unix. Про их настройку я писал тут.

tape_size = 100G
# Размер ленты. Если не угадать, то ленты будет не хватать, а процесс создания резервной копии будет прерываться. Рекомендуется указывать на 5-10 % меньше, чем есть на самом деле. Критичен для команды dd, которая не проверяет конец ленты. cpio отрабатывает событие 'конец ленты' корректнее.

tape_address = /dev/rmt/0mn
tape_address_rew = /dev/rmt/0m
# Имена устройств для ленточного устройства для утилиты brbackup. Зависит от ОС. Первый файл без автоматической перемотки после команды записи/чтения, второй с автоматической перемоткой ленты.

tape_address_arch = /dev/rmt/1mn
tape_address_rew_arch = /dev/rmt/1m
# Имена устройств для ленточного устройства для утилиты brarchive. Зависит от ОС. Первый файл без автоматической перемотки после команды записи/чтения, второй с автоматической перемоткой ленты. Используются, если используется ленточное устройство отличное от того, что для brbackup.

volume_archive = (EI7A01, EI7A02, EI7A03, EI7A04, EI7A05,
                  EI7A06, EI7A07, EI7A08, EI7A09, EI7A10,
                  EI7A11, EI7A12, EI7A13, EI7A14, EI7A15,
                  EI7A16, EI7A17, EI7A18, EI7A19, EI7A20,
                  EI7A21, EI7A22, EI7A23, EI7A24, EI7A25,
                  EI7A26, EI7A27, EI7A28, EI7A29, EI7A30)
# Указывается список заголовков лент, которые будут использоваться для созданий копий журналов Oracle посредством утилиты brarchive. Заголовок состоит из '<SID>' системы, буквы 'A' от слова archive и номера. Количество зависит от цикла бэкапа и количества лент в наличии. Ленты используются по кругу. Если указать вместо списка 'SCRATCH', то при копировании заголовок ленты будет игнорироваться.

volume_backup = (EI7B01, EI7B02, EI7B03, EI7B04, EI7B05,
                 EI7B06, EI7B07, EI7B08, EI7B09, EI7B10,
                 EI7B11, EI7B12, EI7B13, EI7B14, EI7B15,
                 EI7B16, EI7B17, EI7B18, EI7B19, EI7B20,
                 EI7B21, EI7B22, EI7B23, EI7B24, EI7B25,
                 EI7B26, EI7B27, EI7B28, EI7B29, EI7B30)
# Указывается список заголовков лент, которые будут использоваться для созданий копий файлов базы данных посредством утилиты brbackup. Заголовок состоит из '<SID>' системы, буквы 'B' от слова backup и номера. Количество зависит от цикла бэкапа и количества лент в наличии.  Ленты используются по кругу. Если указать вместо списка 'SCRATCH', то при копировании заголовок ленты будет игнорироваться.

expir_period = 30
# Указывается период в днях, в течении которого нельзя использовать ленту. Цифру необходимо согласовывать с количеством лент и частотой выполнения резервирования. Используется для исключения случайной перезаписи ленты с резервной копией.

tape_use_count = 100
# Счётчик, указывающий сколько раз можно использовать ленту для резервного копирования. После достижения этой цифры, утилита попросит заменить ленту. Нужен для исключения ситуации внезапного износа ленты и сбоя при восстановлении из резервной копии.


После внесения информации в файл настройки, необходимо подготовить магнитные ленты.
Чтобы записать заголовок на ленту необходимо на уровне ОС из под пользователя <sid>adm выполнить команду вида:

> brbackup -i force -v <tape_name> 
> brarchive -i force -v <tape_name> 

Первая команда для записи заголовка типа '<SID>B<XX>', вторая  - '<SID>A<XX>'. Заголовок пишется в файл (.tape.hdr0), который хранится в начале магнитной ленты. В него записывается заголовок ленты, дата последней записи резервной копии на эту ленту и счетчик использования.

Посмотреть эту информацию можно, использовав команды:

> brbackup -i show  
> brarchive -i show  

Запустить резервное копирование можно напрямую через команды на уровне ОС: brbackup, brarchive или утилиту brtools, либо выполнить разовое или периодическое планирование в транзакции DB13.

Дополнительно на тему можно почитать следующие посты:

- про блокировки, возникающие во время резервирования утилитами brbackup и brarchive,

- про файлы устройств в отказоустойчивом кластере.

В данном посте я описал минимальную настройку, необходимую для создания резервных копий базы данных на магнитную ленту средствами SAP. Можно настроить систему резервного копирования дальше. Использовать RMAN, например. А можно использовать сторонние утилиты, такие как HP Data Protector.


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

Процедура 'Check database' в DB13

Как вы знаете, для администрирования базы данных Oracle в SAP системе есть "Календарь планирования DBA". Доступ к нему осуществляется через транзакцию DB13 или транзакцию DBACOCKPIT (путь: Задания -> Календарь планирования АдминБД (DBA)) (рис. 1).

Рис. 1. Календарь планирования DBA.

В календаре можно запланировать набор стандартных фоновых заданий, которые используют те или иные утилиты из набора BR*Tools.

Среди данного набора есть задание "Check Database" (brconnect -u / -c -f check), которое выполняет проверку базы данных Oracle. Рекомендуется запускать данное задание минимум один раз в неделю и проверять отчет о выполнении не реже. :)

Стандартный набор проверок состоит из следующих частей:

• DBA - проверки структуры базы данных (наличие всех файлов, критичные пороги размеров файлов и файловых систем и т.п.),
• DBO - проверки выполнения резервных копий база данных и журнальных файлов Oracle,
• ORA - наличие ошибок Oracle в журнале базе данных,
• PROF - проверка значений параметров Oracle.

Набор проверок поставляется компанией SAP и хранится в таблице DBCHECKORA. Стандартный набор проверок можно загрузить посредством SQL-скрипта который хранится в SAP note # 403704 - BRCONNECT - Enhanced function for Oracle DBA.

Иногда бывает необходимо скорректировать проверки базы данных. Например, есть система, у которой нет необходимости использовать ARCHIVELOG MODE для базы данных. При выполнении задания "Check Database" в данной системе проверка на ARCHIVELOG MODE не проходит - выдает сообщение об ошибке (рис. 2).

Рис. 2. Предупреждение в отчете Check Database.

Доступ к проверкам, используемым этим отчетом, можно получить через транзакцию DB17 или DBACOCKPIT (путь Предупреждения -> Check Conditions). Запускаем транзакцию, находим условие для ARCHIVELOG MODE (рис. 3).

Рис. 3. Условия проверки базы данных.

Переходим в редактирование условия и отключаем проверку (рис. 4).

Рис. 4. Отключение проверки ARCHIVELOG MODE.

Сохраняем условие и выходим (рис. 5).

Рис. 5. Условия проверки базы данных с неактивной проверкой на ARCHIVELOG MODE.

После этого данная проверка в задании "Check Database" производится не будет (рис. 6).

Рис. 6. Отчет задания Check Database без проверки ARCHIVELOG MODE базы данных.

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

Напомню, что вернуть всё к стандартному набору можно через SQL-скрипт из SAP note # 403704 - BRCONNECT - Enhanced function for Oracle DBA.  

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

Default Temporary Tablespace PSAPTEMP

Начиная с версии SAP_BASIS 6.40 и базы данных Oracle 9i, рекомендуется в качестве табличного пространства по-умолчанию (Default Temporary Tablespace) использовать специальное табличное пространство PSAPTEMP. В предыдущих версиях SAP/Oracle использовалось табличное пространство SYSTEM.

В свое время данное решение было продиктовано соображениями безопасности. Иначе, на уровне базы данных мог быть создан пользователь, у которого временным табличным пространством было бы установлено SYSTEM, и которое при использовании в данном качестве, увеличивалось бы в размерах, оставаясь таким и после окончания использования. 

Утилита BRTools, начиная с версии 6.40, проверяет какое табличное пространство установлено в качестве Default Temporary Tablespace. Если это SYSTEM, то выдается сообщение об ошибке. Например, в отчете CheckDB в транзакции DB13 (рис. 1).

Рис. 1. Ошибка в отчете CheckDB.

На уровне SQLPlus проверить значение Default Temporary Tablespace можно следующим SQL-запросом (рис. 2 и 3).

Рис. 2.  Табличное пространство PSAPTEMP в качестве Default Temporary Tablespace.

Рис. 3. Табличное пространство SYSTEM в качестве Default Temporary Tablespace.

Если система выдает ошибку (рис. 1) и проверка на уровне SQLPlus показывает, что это так и есть (рис. 3), то необходимо переназначить значение Default Temporary Tablespace согласно рекомендациям SAP следующей SQL-командой (рис. 4).

Рис. 4. Изменение значения Default Temporary Tablespace на PSAPTEMP.

После этого можно проверить, что данное табличное пространство установлено для всех пользователей базы данных (рис. 5).

Рис. 5. Проверка, что для всех пользователей базы данных установлена PSAPTEMP.

Подробности в SAP note # 683075 - Oracle9i: Default Temporary Tablespace. Там же описано, как создать временное табличное пространство PSAPTEMP, если его нет.

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

Ошибка в BRTools 7.XX

Установив систему SAP NetWeaver 7.4 на платформу Linux/Oracle, обнаружил ошибку при выполнении любой программы из набора утилит BR*Tools (про данный инструментарий я писал тут).

Ошибка появляется как при работе через транзакцию DB13 (DBACOCKPIT) (рис. 1), так и при работе с утилитами на уровне операционной системы (рис. 2).

Рис. 1. Ошибка BR1301 в транзакции DB13.

Рис. 2. Ошибка BR1301 на уровне операционной системы.

По большому счету, это не ошибка, а предупреждение и на работу простых заданий ("Check Database", "Clean Up Logs", "Offline Complete DB Backup" и другие) не влияет. Однако, сообщение есть, глаза мозолит.

Решение проблемы: обновить BR*Tools.

Как видно из данного примера (рис. 1 и 2), здесь мы имеем дело с BR*Tools версии 7.40 с уровнем пакетов поддержки 1. При обновлении SAP ядра (после установки системы SAP ядро 740 с уровнем пакетов поддержки 12) до 37 уровня набор данных утилит не обновляется. Поэтому BR*Tools следует качать и обновлять отдельно.

Процедура похожа на процедуру обновления SAP ядра:

1. Заходим на сайт поддержки по быстрой ссылке вида: http://service.sap.com/swdc. Переходим по пути для выбора SAP ядра нашей версии:
   "My Company's Application Components -> My Company's Software -> SAP NETWEAVER -> SAP NETWEAVER 7.4 -> Entry by Component -> Application Server ABAP SAP -> KERNEL 7.40 64-BIT UNICODE". В разделе зависимых от Oracle частей ядра находим архив вида DBATL740*.SAR (рис. 3). Скачиваем обновления.



Рис. 3. Скачивание обновлений для утилит BR*Tools.



2. Распаковываем архив с помощью утилиты SAPCAR.
3. Останавливаем SAP систему.
4. Делаем копию директории со старым SAP ядром (/usr/sap/ET4/SYS/exe/uc/linuxx86_64).
5. Копируем с заменой файлы из архива в директорию с SAP ядром
   (/usr/sap/ET4/SYS/exe/uc/linuxx86_64).
6. Выполняем из под пользователя root скрипт, выставляющий корректные полномочия для исполняемых файлов ядра:
   

   # /usr/sap/ET4/SYS/exe/uc/linuxx86_64/saproot.sh <SID>

7. Запускам систему SAP.

После обновления (в данном примере на BR*Tools версии 7.40 с уровнем пакета поддержки 5) операции выполняются без предупреждений и ошибок (рис. 4).

Рис. 4. Журнал операции в транзакции DB13 после обновления.

Такая ошибка может встречаться в BR*Tools не только версии 7.40, но и в предыдущих.

Подробности по данной теме:
- SAP note # 912969 - BR*Tools 7.00 fails due to license problems,
- SAP note # 12741 - Current versions of BR*Tools.

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

BRTOOLS как архиватор

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

Как вы знаете, при организации бэкап-стратегии для создания резервных копий базы данных можно использовать набор утилит BR*Tools (утилиты BRBACKUP и BRARCHIVE). Данные утилиты позволяют создавать резервные копии базы данных на магнитную ленту или жесткий диск. Настройка вышеуказанных утилит осуществляется через конфигурационный файл init<SID>.sap.

При создании резервной копии, чтобы экономить пространство на носителе, дата-файлы базы данных можно сжимать. До недавнего времени для этих целей использовались небольшие утилиты MKSZIP и UNCOMPRESS, которые SAP поставлял в составе SAP kernel.

Для настройки сжатия в конфигурационном файле были параметры вида:

compress = yes
compress_cmd = "E:\usr\sap\<SID>\SYS\exe\uc\NTAMD64\mkszip -c $ > $"
uncompress_cmd = "E:\usr\sap\<SID>\SYS\exe\uc\NTAMD64\uncompress -c $ > $"

Теперь же в BR*Tools 7.10/7.20 утилиты сжатия были исключены из состава SAP kernel, а за сжатие теперь отвечает сами утилиты SAP BR*Tools. Настройка сжатия при создания резервных копий тепервыглядит так:

compress = brtools

Работает такой вид сжатия только в SAP системах установленных на операционной системе MS Windows. Так же в этой операционной системе утилиты BR*Tools заменили собой утилиты записи на магнитную ленту.
Подробности можно прочитать в SAP note # 1173119 - New function in BR*Tools to replace MKS tools.

Расширение сжатых файлов сменилось с *.Z на *.K.

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

Утилиты для администрирования ORACLE в SAP. Часть II.

В первой части статьи я провел обзор утилит (BR* утилиты), входящих в состав SAP ядра и помогающих администрировать базу данных ORACLE.

К сожалению, программа BR*Tools (в девичестве SAPDBA) является консольной утилитой и, следовально имеет свои плюсы и минусы. В частности, не очень удобный интерфейс взаимодействия с администратором. 

Но это легко устранить установкой отдельного графического интерфейса для утилиты BR*Tools. Графический интерфейс называется BrGui. На момент написания статьи существовало две версии утилиты:

• BrGui 6.30: позволяет получить графический интерфейс к утилитам BR*Tools 6.20 (с патча 126) и BR*Tools 6.40 (с 11 патча),
• BrGui 6.40: позволяет получить графический интерфейс к утилитам BR*Tools версии 7.00 и выше. Хотя поддерживает и утилиты, которые поддерживала версия 6.30.

Версию BrGui 6.40 с последним патчем можно найти в SAP note # 769159 - Corrections in BrGui 6.40. Для установки утилиты необходимо скачать ZIP-архив из вышеуказанной ноты и скопировать его на сервер, где установлена SAP система. Распаковать архив. В архиве находится файл readme.txt, где указана информация по установке и запуску утилиты. Содержимое архива можно скопировать, например, в директорию /usr/sap/.

BrGui это Java приложение, поэтому для корректной работы необходимо, чтобы была указана переменная окружения JAVA_HOME. Запуск осуществляется через выполнения файла brgui.bat (Windows NT) или скрипта brgui (Unix). В операционной системе MS Windows есть возможность создать ярлык на выполнение. Для этого следует прописать строку запуска:

cmd /c start /B %JAVA_HOME%\bin\javaw.exe -classpath E:\usr\sap\brgui\lib\sap.com~tc~bl~brgui~impl.jar com.sap.gui.brgui.BrGui

Рабочая директория иконки должна быть "E:\usr\sap\brgui". В качестве иконки можно указать файл E:\usr\sap\brgui\brgui.ico (рис. 1).

Рис. 1. Иконка запуска BrGui в MS Windows.

Перед запуском утилиты можно открыть конфигурационный файл brgui.properties, который располагается в основной директории BrGui. В данном файле необходимо настроить соединение до системы, заменив строку

  brgui.remote-0=<alias> (<remote>) <profile>

на строку, вида:

  brgui.remote-0=SME (localhost)

где, первое - SID SAP система, а в скобках - тип соединения. В данном случае мы коннектимся к локальному хосту.

При запуске утилиты появится окно логина к утилите BR*Tools (рис. 2). При нажатии на кнопку "Logon" мы попадем в основное окно утилиты BR*Tools только в графическом исполнении (рис. 3).

Рис. 2. Окно логона BrGui.

Рис. 3. Графический интерфейс BrGui 6.40.

Через графический интерфейс можно делать все то же, что и через консольный. Вот, например, как выглядит окно раздела "Show instance status" (рис. 4).

Рис. 4. Show instance status.

Последние версии утилиты работают вполне стабильно и чаще быстрее, чем консольный вариант.

Дополнительную информацию можно почерпнуть из SAP note # 611493 - BrGui: Graphical user interface for BR*Tools.

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

Утилиты для администрирования ORACLE в SAP. Часть I.

В статье про ПО SAP на сайте Луркоморья написано: "... В европейском идеале, базисник занимается исключительно сервером приложений и базовой логикой системы — безопасностью, производительностью, управлением изменениями и др. В реальности, этот человек отвечает за СУБД, ОС и даже за железо ...". И, к сожалению, это правда. Но, к счастью, компания SAP AG думает и об этом и предоставляет SAP Basis администратору утилиты для администрирования базы данных ORACLE.

Данные утилиты входят в состав ядра SAP системы, в следствии чего, представляют собой бинарные файлы, и начинаются на BR*. Для удобного доступа к данным утилитам используется программа, которая представляет собой интерактивное меню для выполнения тех или иных операций с базой данных ORACLE. В старых версиях систем (в SAP R/3 4.6C и ORACLE 8i) использовалась программа SAPDBA (рис. 1). В новых версиях систем (с WAS 6.20 и выше) была заменена утилитой BR*TOOLS (рис. 2).

Рис. 1. Утилита SAPDBA.

Рис. 2. Утилита BR*TOOLS.

Кроме изменения дизайна в новой версии, была применена другая концепция перерисовки экрана. Это немного усложнило удобство использования, но позволило отслеживать на экране всю последовательность действий. То есть предыдущий экран утилиты теперь не перерисовывается, как в старой версии, а сохраняется на экране. Всегда можно прокрутить вверх окно терминала и посмотреть действия и команды. Можно сохранить в текстовый файл для последующего анализа или наглядного примера.

Запуск утилиты, как вы уже поняли, осуществляется из командной строки путем ввода команды:

> sapdba

или

> brtools

Версию используемой программы можно узнать, указав ключик "-V".
Запускать следует из под пользователя ora<sid> в Unix системах или <sid>adm в MS Windows.

Для соединения к базе данных используется OPS$ user, так как он не требует пароля с уровня ОС. В утилитах это указывается через параметр "-u /".

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

• BRBACKUP - осуществляет бэкап базы данных. Журналы работы хранятся в директории /oracle/<SID>/sapbackup.
• BRARCHIVE - создает копии оффлайн журналов ORACLE (offline redo logs). Журналы работы можно найти в директории /oracle/<SID>/saparch.
• BRCONNECT - отвечает за различные административные задачи, такие как сбор статистики ORACLE или проверка базы данных. Журналы работы стоит искать в директории /oracle/<SID>/sapcheck.
• BRRESTORE - восстановление из резервных копий базы данных. Логи в директории /oracle/<SID>/sapbackup.
• BRRECOVER - новая утилита (с версии 6.20 и выше) восстановления базы данных. Журналы в /oracle/<SID>/sapbackup.
• BRSPACE - утилита для реорганизации базы данных целиком или по частям. Журналы находятся в директории - /oracle/<SID>/sapreorg.

Для работы используются параметры из профайлов:

• /oracle/<SID>/<DB_vers>/dbs/init<SID>.sap,
• /oracle/<SID>/<DB_vers>/dbs/init<SID>.dba.

Данный путь верен для Unix, в Windows надо dbs заменить на database.

При выполнении или планировании операций с базой данных из таких SAP транзакций, как DBACOCKPIT, DB13, DB02, DB14 и т.д, используются эти же утилиты. Правда запуск происходит из под пользователя <sid>adm в Unix и SAPService<SID> в MS Windows.

Старые журналы работы утилит можно удалить с помощью опции "-f cleanup" программы BRCONNECT или, запланировав соответствующее задание в транзакции DB13. По-умолчанию, удаляются журналы старше 30 дней. Период регулируется параметрами cleanup_* в вышеуказанных профилях.

Если возникли ошибки в работе вышеуказанных утилит и, решение не было найдено в базе SAP notes, то можно написать сообщение в службу поддержки, указав компонент BC-DB-ORA-DBA.

За дополнительной информацией можно обратиться к следующим нотам:
- SAP note # 651812 - FAQ: BR*TOOLS and SAPDBA
- SAP note # 12741 - Current versions of BR*Tools and SAPDBA

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

Журнальные файлы Oracle и archivelog mode. Часть II.

В первой части поста я остановился на онлайн журнальных файлах. Продолжим.

Онлайн журнальные файлы используются по кругу (рис. 1).

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

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

• ARCHIVELOG MODE,
• NOARCHIVELOG MODE,

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

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