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

В 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.


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

Ошибка в 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

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

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

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

Подружить кластер и brbackup/brarchive

Исходные данные:

• ленточная библиотека на 2 устройства записи на ленту,
• библиотека подключена по оптической сети (FC),
• система SAP работает в отказоустойчивом кластере (HP MC/ServiceGuard), состоящем из 2-х нод,
• бэкапы базы данных и журналов ORACLE делаются стандартными средствами SAP (brbackup/brarchive).

Вывод команды # ioscan -fnC tape на первой и второй ноде выдает несколько отличную картину:
первая нода кластера:

вторая нода кластера:

Программы brbackup/brarchive информацию для своей работы берут из профиля /oracle/<SID>/<ora_vers>/dbs/init<SID>.sap и из планировщика заданий в SAP - транзакции DB13. В профиле помимо всего прочего прописаны и файлы устройств ленточной библиотеки. Из выше показанных скриншотов видно, что необходимо создавать 2 профиля инстанции для каждой ноды. И обновлять содержимое профиля init<SID>.sap из этих профилей при переходе кластерного пакета на ту или иную ноду.

Есть более изящное решение. Создаем линки к файлам устройств на каждой ноде с одинаковыми именами. Прописываем их в профиль и всё. Профиль один на две ноды.

параметры профиля:

Здесь ltm и rtm - это left type и right tape. Названия выбраны для удобства использования и для несовпадения с возможными реальными.
Так, мне кажется, жить удобнее. :)

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

Файл блокировки brbackup/brarchive

Если для создания резервных копий базы данных используются стандартные утилиты системы SAP (brbackup/brarchive), то стоит учитывать, что при старте эти программы создают файл блокировки. Данный файл служит для защиты от одновременного запуска нескольких программ резервного копирования. Файл имеет имя .lock.brb или .lock.bra соответственно для блокировки brbackup и brarchive процессов. Располагается файл в директории, заданной параметром stage_root_dir или archive_stage_dir соответственно, по умолчанию, /oracle/<SID>/sapbackup.

После сбоя утилиты brbackup или brarchive файл блокировки может остаться в вышеуказанной директории и препятствовать последующему запуску процесса резервного копирования. В данной ситуации требуется ручное удаление файла блокировки администратором. Старайтесь не забывать об этом.

Подробности в SAP note # 153902 - Flexible processing of BR program locks.

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

Файл-пустышка

Хочу поделится одним трюком. Не помню кто и когда им поделился со мной, может быть сам придумал. Не суть. ;) Главное, что он помогает в работе администратора.

Я его использую так. Как Вы знаете, база данных ORACLE использует журналы. Журналы бывают онлайн и оффлайн. Если база данных работает в ARCHIVELOG режиме, то онлайн журналы, прежде чем СУБД сможет их использовать повторно, копируются в специальную директорию (saparch, oraarch). Если в NOARCHIVELOG режиме, то онлайн журналы просто перезаписываются. Нам интересен первый вариант, в котором работают все продуктивные системы.

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

Я использую такой приём: до попадания в такую ситуацию, создаю в этой директории файл-пустышку, размером примерно 1 Гб и называю его "remove.me":

Если переполняется директория saparch, я (или другой администратор системы) могу спокойно удалить этот файл, и система сразу начнет работать, выйдя из "подвешенного состояния". А я смогу спокойно решить вопрос, что делать с оффлайн журналами в директории. Скорее всего запущу процесс копирования их на магнитную ленту с удалением из директории. Этот простой прием позволяет не впадать в панику, судорожно удаляя оффлайн журналы, которые могут в будущем пригодиться, а потом держать скрещенным пальцы на ногах, молясь, чтобы система не упала до следующего оффлайн бэкапа. Всегда важно, как говорил Карлсон, "спокойствие, только спокойствие". :)

Если у Вас нет большого файла, в Unix-системах его легко создать из маленьких (из тех же оффлайн журналов ORACLE), используя команду cat и перенаправление результата в файл:

# touch remove.me

# cat small_file >> remove.me

Последнюю команду надо выполнять до тех пор, пока размер файла remove.me не достигнет нужного Вам размера.
А (с подсказки пользователя laskavy) можно сделать проще:

# dd if=/dev/zero of=remove.me bs=1024x1024 count=1024

В Windows системе Вы можете таким образом спрятать свой любимый порно-фильм. Это будет мотивировать Вас не доводить ситуацию до сбоя и усердно следить за директорией. :-D
Приём можно использовать не только для директории saparch (oraarch), а везде где это может быть актуально.

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