Буферы ORACLE

Продуктивная система SAP R/3 4.6C с ORACLE 8.1.7.4.0 в качестве СУБД. В системе ежедневно порядка 600 активно работающих пользователей. Размер базы данных около 400 Гб. Были проблемы с производительностью. Среднее время отклика системы в среднем по диалоговым инстанциям стало 3000 мс. На наиболее загруженных серверах приложений доходило до 13000 мс!
После анализа ситуации было решено увеличить параметры памяти ORACLE (профайл init<SID>.ora):

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

• было:

• стало:

Первый график (синяя кривая) - загрузка дисков в процентах. Второй график (красная кривая) - время ожидания запросов в очереди к дискам в мс. Графики взяты за рабочий день с высокой нагрузкой.

Среднее время отклика системы в среднем по диалоговым инстанциям стало 1000-1200 мс, уменьшение произошло за счет "Времени БД". На наиболее загруженных серверах приложений доходит лишь до 1500-2000 мс.

Увеличение параметров происходило в 2 этапа. Это видно на первом скриншоте. Второй этап имел меньшую эффективность, поэтому дальнейшее увеличение параметров пока не планируется.

Начиная с версии ORACLE 9.2 параметры немного изменились, их стало меньше.

Полезная SAP note на эту тему:
Note # 789011 - FAQ: Oracle memory areas.

Вывод: не зажимайте ORACLE, дайте ему тоже поработать.

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

Spool в системе SAP R/3 4.6C и поддержка со стороны SAP

Имеем систему - SAP R/3 4.6C, Oracle - 8.1.7.4.0, SAP_BASIS - SAPKB46C57, sap kernel 46D - 2364 patch level.
Система, мягко говоря, не первой свежести, но я думаю, что используется такая версия еще часто. Так вот, после 01.2008 sap kernel 46D не поддерживается компанией SAP и обновления для ядра не выпускаются. Предлагается переход на ядра 46D_EXT или 46D_EX2, которые требуют версию ORACLE не ниже 9.2. На днях на ландшафте клиента было обнаружено, что запросов в spool хранится больше, чем обычно. Разбор полетов показал, что стандартное фоновое задание SAP_REORG_SPOOL работает в холостую и ни одного запроса в spool не удаляет.

Данное задание запускает в фоне программу RSPO0041 (SAP note # 41547) с вариантом SAP&001. Вариант представляет из себя следующее:

То есть фоновое задание запускается ежедневно и удаляет "Устаревшие запросы в спул". У каждого запроса в spool (spool request) есть "Дата удаления" (Delete data), которая формируется по формуле: дата создания + 8. Число 8 берется из параметра инстанции rspo/req_lifetime, который можно установить в значения от 1 до 8. Анализ запросов в spool показал, что совершенно у всех запросов в поле "Дата удаления" стоит - 01.01.2100!
Была найдена SAP note # 1422843 - Wrong deletion date in spool request, в которой описана проблема, возникающая после 23.12.2009. Данная проблема исправляется ручными манипуляциями + установкой новой версии sap kernel. Но так как в данной системе без апдейта ORACLE обновление sap kernel невозможно, решено было удалить фоновое задание SAP_REORG_SPOOL и запланировать периодическое (ежедневно) выполнение программы RSPO0041 со следующими опциями:

"Пора-пора делать upgrade...", - шепчет компания SAP на ушко своим клиентам. ;)

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

Установка SAP ERP 6.0 SR3, опять в картинках

Ну вот дошла очередь и до третьей системы в великолепной команде на подопытном сервере, который я собрал своими мозолистыми руками в кризисном, 2009, году. Ей стала SAP ERP 6.0 SR3. Скачал последние версии установочных дисков для системы на Windows/ORACLE x64 с SAP Support Portal. Инструкции по установке взял тут.

Как всегда, стараясь для будущих поколений SAP администраторов, сделал инструкцию по установке. База данных после установки, апдейта и начальной настройки занимает - 100 Гб.

Смело качаем инструкцию по установке SAP ERP 6.0 SR3 (zip-архив, 1813 Кб) и используем во благо. :)

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

Файл блокировки 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.

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

Процессы SAP, ORACLE, HP-UX

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

• DIA - диалоговые процессы, которые выделяются для работы пользователей с системой в режиме диалога;
• BTC - фоновые процессы, которые обрабатывают запланированные фоновые задания системы и пользователей;
• ENQ - процесс блокировки, всегда один и всегда на центральной инстанции;
• UPD(VB), UP2 - процессы обновления данных в базе данных;
• SPO - процессы спула, которые обрабатывают запросы на печать.

Количество тех или иных процессов задается параметрами в профиле инстанции. Посмотреть что и в каком количестве сконфигурировано в системе можно в транзакции SM50. У "пчелок" есть "матка" - диспетчер. Данный процесс системы организует очередь к рабочим процессам, раздает им задания, управляет их запуском и остановкой. Рабочие процессы являются дочерними процессами родительского процесса диспетчера на уровне ОС Unix. Таким образом, стоит понимать, что рабочий процесс системы SAP это отдельный процесс на уровне ОС. Каждому рабочему процессу SAP соответствует shadow-процесс ORACLE, который в свою очередь представляет отдельный процесс на уровне ОС Unix (на платформе Windows ситуация несколько иная).
Любой процесс требует определенный набор ресурсов (оперативная память, такты процессора, место в таблице процессов и т.д.). Поэтому держать неограниченное количество процессов, что со стороны SAP, что со стороны ORACLE или UNIX, не целесообразно. Есть определенный ряд параметров, которые ограничивают количество процессов, прежде всего максимальное. И чтобы SAP, ORACLE и UNIX не вели себя как лебедь, рак и щука, необходимо учитывать эти параметры и согласовывать между собой их значения.
И так, есть общее количество рабочих процессов системы SAP. При этом, если установлены дополнительные сервера приложений, то количество рабочих процессов дополнительных серверов приложений надо учитывать. Количество рабочих процессов SAP задаётся параметрами rdisp/wp_no_* в профиле инстанции системы. В профайле ORACLE (init<SID>.ora) есть 2 параметра: PROCESSES и SESSIONS.
Формулы расчета можно найти в SAP note # 384839 (пункт 2)(для ORACLE версий 8i и 9i) или SAP note # 830576 (для ORACLE версий 10i). В наиболее общем виде формулы выглядят так:

• PROCESSES = #ABAP work processes * 2 + #J2EE server processes * <max-connections> + PARALLEL_MAX_SERVERS + 40
• SESSIONS = 2 * PROCESSES

Если установлена только ABAP-часть, то формула очень проста - удвоенное количество рабочих процессов SAP плюс запас для служебных процессов ORACLE. Например, в системе сконфигурировано 50 рабочих процессов SAP, следовательно, надо выставить PROCESSES = 140, SESSIONS = 280.
На уровне HP-UX есть параметр ядра nfile. Этот параметр задается формулой, которая зависит от параметров nproc и max_users. Если в системе много процессов ORACLE, которые работают с большой базой данных (состоящей из большого количества дата файлов), то можно "схлопотать" ошибку ОС:

Error: 23: File table overflow

Чтобы такого "безобразия" не было. Необходимо чтобы параметр nfile удовлетворял условию:

• nfile > #File descriptors = #Data files * PROCESSES

Для подробной информации стоит заглянуть в SAP notes # 546006 и # 172747. Для установки параметра в HP-UX используйте команду kmtune (kctune) или SAM.

Вышесказанное поможет добавить дополнительный сервер приложений, дополнительные рабочие процессы в систему SAP и при этом согласовать работу базы данных ORACLE и ОС HP-UX, не получив лишних проблем. ;)

А еще у меня есть вопрос знатокам. ;) Почему в формуле расчета параметра PROCESSES для ORACLE количество рабочих процессов SAP умножается на 2? В документации говорится, что одному рабочему процессу SAP соответствует один рабочий процесс ORACLE. Зачем брать ИМЕННО двойное количество. Кто знает - отпишитесь в комментариях. Очень интересно. :)

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

Команды для просмотра журналов в UNIX

Для просмотра журналов (логов) различных процессов в UNIX системах я пользуюсь следующим набором команд:

• # more log.log - позволяет просматривать журнал постранично с начала файла. Переход на следующую страницу по нажатии клавиш "Пробел" или "F". Переход на страницу назад - клавиша "B". Можно просматривать построчно вперед - клавиша "Enter". Выход из просмотра лога - "Q".
• # tail -n log.log - просмотреть последние "n" строк журнала. Если количество необходимых строк больше размера страницы, то удобно использовать так: # tail -n log.log | more. Клавиши управления - такие же, как у команды more.
• # tail -f log.log - выводить строки журнала по мере их появления в реальном времени. Эта команда очень помогает, когда необходимо мониторить процесс загрузки/установки и так далее. Или держать такой экранчик в фоне, чтобы всегда быть в курсе событий. Выход - "Ctrl + C".

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

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

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

Я его использую так. Как Вы знаете, база данных 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), а везде где это может быть актуально.

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