Сколько рабочих процессов в AS ABAP инстанции может быть?

Как я уже много раз упоминал в своих постах, рабочими лошадками в AS ABAP инстанции SAP системы являются рабочие процессы (work processes или WP). Управляет ими ABAP диспетчер, который запускает и останавливает рабочие процессы, а так же выдаёт каждому задачу из очереди запросов (рис. 1).

Рис. 1. Архитектура ABAP части системы SAP NetWeaver 7.1.

В ABAP инстанции трудятся рабочие процессы нескольких типов. 

Запросы от диалоговых пользователей обрабатывают диалоговые рабочие процессы (тип DIA), которых в системе обычно большинство. 

Как известно, ABAP программу можно запланировать как фоновое задание. За обработку фоновых заданий отвечают отдельные рабочие процессы типа BTC. Про фоновую работу в SAP системах у меня были отдельные посты, которые можно найти тут.

При отправке документа из SAP системы на печать включаются в работу специальные рабочие процессы спула (SPO). Подробности про настройку принтера в AS ABAP инстанции можно найти в серии постов. 

Если пользователь или фоновое задание изменяет данные в таблицах базы данных, то эти запросы обрабатывают процессы обновления. Причём их можно настроить два типа: UPD и UP2.

Дополнительно для поддержания целостности данных перед обновлением выполняется блокировка объектов на уровне сервера приложений. За это отвечает отдельный тип рабочих процессов - блокировки (ENQ). Правда, в последних версиях SAP систем этот процесс перекочевал в отдельный Enqueue Server, который вместе с Message Server входит в состав отдельной инстанции - ASCS. Про это я рассказывал в этом посте. Такое изменение в архитектуре SAP системы позволяет строить более надёжные и отказоустойчивые программные комплексы. 

Текущий состав рабочих процессов AS ABAP инстанции можно посмотреть в транзакциях мониторинга рабочих процессов - SM50 и SM66 (подробнее про эти транзакции). 

Изменение же количества рабочих процессов того или иного типа осуществляется через параметры SAP системы. Параметры, так или иначе влияющие на количество рабочих процессов, я объединил в таблицу (рис. 2).

Рис. 2. SAP параметры для настройки рабочих процессов ABAP инстанции.

В верхней части таблицы отображены параметры, через которые мы можем настроить количество рабочих процессов того или иного типа. Все эти параметры статические, поэтому для изменения количества рабочих процессов необходим рестарт ABAP инстанции. 

Для динамического же изменения количества рабочих процессов инстанции в SAP системе можно настроить режимы работы (operation modes). Благодаря этому механизму можно, не меняя общего количества рабочих процессов, менять их типы. Например, на ночь переводя часть рабочих процессов диалогового типа в фоновые, а утром возвращая обратно. 

Для настройки режимов работы используются транзакции RZ03/RZ04. Напоминаю, что в моём обучающем курсе SAPADM 2.0 (Пакет 2. Задание 1) можно поупражняться в их настройке в собственной учебной среде. 

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

• зарезервированные (stand-by) рабочие процессы,
• динамические рабочие процессы.

Зарезервированные (stand-by) рабочие процессы бывают только диалоговые (тип DIA). Они, как и другие рабочие процессы, запускаются при старте инстанции, но находятся в режиме Standby. В случае если ABAP диспетчер не может выделить запросу пользователя свободный диалоговый рабочий процесс, то есть в системе наблюдается критическая нехватка свободных диалоговых рабочих процессов, то система автоматически переводит зарезервированные рабочие процессы в рабочий режим. Количество рабочих процессов такого типа настраивается через значение параметра rdisp/wp_no_restricted. По умолчанию параметр равен нулю, то есть механизм зарезервированных рабочих процессов деактивирован.

Для временного решения проблем с нехваткой рабочих процессов диалога или спула система автоматически запускает динамические рабочие процессы. Их количество равно количеству, заданному в параметре rdisp/wp_max_no, минус общее количество статических рабочих процессов (включая зарезервированные рабочие процессы, если они настроены).

Динамические рабочие процессы в системе есть всегда и их количество, по умолчанию равно 5, так как параметр rdisp/wp_max_no рассчитывается по формуле: сумма всех статических рабочих процессов плюс пять. Менять значение параметра вручную стоит только в том случае, если вы планируется установить количество таких процессов больше 5 (рис. 3).

Рис. 3. Формула для расчёта значения параметра rdisp/wp_max_no.

Динамические рабочие процессы запускаются и останавливаются автоматически. Время жизни таких процессов после нормализации ситуации в системе можно задать через значение параметра rdisp/max_dynamic_wp_alive_time. По умолчанию, срок их жизни 5 минут (300 секунд).

Параметр rdisp/configurable_wp_no используется для настройки режимов работы (operation modes). Он показывает количество статических рабочих процессов системы. Благодаря ему при любом режиме работы в системе могут активироваться динамические рабочие процессы. Вручную изменять его значение, рассчитываемое по формуле (рис. 4), не рекомендуется (только в крайних случаях по рекомендации SAP).

Рис. 4. Формула для расчёта значения параметра rdisp/configurable_wp_no.

Количество зарезервированных и динамических рабочих процессов (если они вдруг запущены), также отображается в транзакции SM50.

Теперь вернёмся к вопросу заданному в заголовке: каковы крайние значения количества рабочих процессов в AS ABAP инстанции? 

Как видно из таблицы, минимальное количество в сферической ABAP инстанции в вакууме это 2 диалоговых рабочих процесса. Правда в реальности вы такое вряд ли увидите. Если только на выделенной дополнительной диалоговой инстанции. И даже в этом случае на ней диалоговых процессов будет больше двух. А после установки любой SAP системы, на единственной её инстанции всегда будут рабочие процессы всех типов. Ну кроме рабочего процесса блокировки по вышеупомянутой причине. Для всей SAP системы существуют следующие рекомендации и ограничения:

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

Максимальное же общее количество рабочих процессов инстанции (с учетом динамических и зарезервированных) может достигать 512 (для современных систем, включая ABAP Platform). Данный лимит актуален для систем, начиная с SAP BASIS 7.1 (с определённым пакетом поддержки), а до этого он был гораздо скромнее. Например, в SAP NetWeaver 7.0 рабочих процессов основных типов (кроме ENQ) может быть не больше 100 (рис. 5).

Рис. 5. Граничные значения диалоговых рабочих процессов в SAP NetWeaver 7.0.

Для систем на SAP NetWeaver 7.0 и ниже я встречал рекомендации, что при приближении общего количества рабочих процессов AS ABAP инстанции к 100, необходимо разворачивать дополнительную инстанцию. И, с учётом ограничений по параметрам, даже на очень крупных проектах вы вряд ли встретите больше 200 рабочих процессов на одну ABAP инстанцию.

А как определить, что количество рабочих процессов того или иного типа в вашей инстанции избыточно? Ведь каждый лишний рабочий процесс AS ABAP инстанции это процесс на уровне операционной системы. А каждый процесс на уровне операционной системы требует ресурсов (особенно памяти). Поэтому излишнее количество рабочих процессов может снижать производительность всей системы и увеличивать время обслуживания (запуск/останов/рестарт и так далее). Здесь может помочь просмотр актуального времени работы отдельных рабочих процессов в транзакции SM50 (я рассказывал об этом в этом посте). Но имейте ввиду, что этот способ работает только для систем, основанных на SAP NetWeaver версий ниже, чем 7.20. В более старших релизах SAP диспетчер распределяет нагрузку по существующим рабочим процессам более равномерно, вне зависимости от их количества. И так легко лишние процессы уже не вычислить.

Дополнительную информацию по этой теме можно найти в SAP notes:

• 9942 - Maximum number of work processes,
• 39412 - How many work processes should be configured?
• и документации на SAP Help Portal.

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

Ошибка ORA-28000: the account is locked

Вы не сталкивались с такой ошибкой? А я вот на днях столкнулся и хочу поделиться своей историей. Может быть эта информация поможет кому-то из вас быстрее разобраться в похожей ситуации.

Однажды, после окончания планового оффлайн бэкапа, система оказалась недоступна для работы. SAP GUI выдавал сообщение о том, что база данных системы недоступна. 

Первая мысль была: "Ну, наверное, по какой-то причине затянулся бэкап". Но переход на уровень операционной системы сервера показал, что база данных запущена, а процессов резервного копирования в операционной системе нет. Правда, со стороны Oracle работают только фоновые служебные процессы и нет ни одного shadow-процесса. 

Вы наверное знаете, что при оффлайн резервной копии базы данных (или как её ещё называют "холодный" бэкап) процессы ABAP инстанции не останавливаются, а остаются работать, потеряв коннект к базе данных. При этом рабочие процессы с настойчивостью и периодичностью пытаются открыть соединение к базе данных. Поэтому, как только база данных становится доступной для соединения, рабочие процессы открывают соединения, а Oracle запускает для каждого рабочего процесса SAP инстанции отдельный shadow-процесс. Подробнее о том, как рабочие процессы SAP системы подключаются к базе данных я описывал в статьях: "Как рабочие процессы SAP соединяются с базой данных Oracle - I" и "Как рабочие процессы SAP соединяются с базой данных Oracle - II". 

Так вот, shadow-процессов Oracle не наблюдалось. Я подключился к базе данных через SQLPlus, используя пользователя SYSTEM. Соединение установилось успешно. На всякий случай перестартовал базу данных. Проверил: shadow-процессов как не было, так и нет. При этом рабочие процессы SAP инстанции в списке процессов операционной системы висели.

Хорошо. Последний рестарт SAP системы был давно, вдруг что-то подглючило на уровне сервера приложений, подумал я. И решил перезапустить сервер приложений. Но скрипты запуска системы выдают: "База данных не запущена, будем запускать. Попытка запуска базы данных заканчивается ошибкой - "база данных недоступна". Стоит отметить, что скрипты запуска SAP системы для проверки доступности базы данных используют утилиту R3trans, входящую в состав SAP Kernel, запуская её с опцией "-d" (рис. 1 и 2).

Рис. 1. Пример успешной проверки соединения с базой данных.

Рис. 2. Пример безуспешной проверки соединения с базой данных.

Проверка переменных окружения пользователей, настроек Oracle client, процесса Listener ничего не дала. 

И только в третий раз просматривая журналы рабочих процессов SAP инстанции (файлы dev_w*), обратил внимание, что код ошибки при попытках коннекта к Oracle отличается от типичного. Когда база данных остановлена, выдаётся код ошибки 1034. 

Рис. 3. Пример кода ошибки соединения с остановленной базой данных.

А тут выдавался код 28000 (рис. 4). 

Рис. 4. Код ошибки при соединении с базой данных в текущем случае.

По коду ошибки удалось выяснить, что ошибка заключается не в недоступности Oracle, а в блокировке пользователя. Как вы уже знаете, из вышеупомянутых статей, что рабочие процессы SAP системы при подключении к Oracle используют пользователя владельца схемы в базе данных. В данном случае это пользователь SAPSR3. Так вот этот пользователь и оказался заблокированным. 

К блокировке пользователя привёл параметр базы данных Oracle - FAILED_LOGIN_ATTEMPTS. Начиная, с версий Oracle 10g значение данного параметра, по умолчанию, равно 10. В предыдущих версиях СУБД по умолчанию стоит значение UNLIMITED. Посмотреть значение в текущей базе данных можно запросом вида:

SQL> select LIMIT from DBA_PROFILES where PROFILE='DEFAULT' AND RESOURCE_NAME='FAILED_LOGIN_ATTEMPTS';

или

SQL> show parameter FAILED_LOGIN_ATTEMPTS;

Как вы помните из моего поста, при соединении с базой данных, до версии Oracle 11g в SAP системе использовался механизм хранения пароля пользователя владельца схемы в отдельной табличке OPS$<USER>.SAPUSER. Так как в момент оффлайн бэкапа база данных недоступна, то рабочий процесс не может получить к ней доступ и прочитать продуктивный пароль пользователя. И как видно из скриншота (рис. 3), каждый раз делается ещё и дополнительная попытка открыть соединение с дефолтным паролем, который зашит в коде ядра. Допускаю, что случилась такая ситуация, что в момент старта базы данных было сделано больше 10 попыток логина к базе данных со стороны SAP системы с этим стандартным паролем (который отличается от продуктивного пароля). В результате этого Oracle автоматически заблокировал пользователя (владельца схемы) и последующие попытки SAP системы присоединиться к базе данных проваливались уже по этой причине, вплоть до моего вмешательства. 

Разрешение ситуации: разблокировка пользователя. Разблокировать пользователя можно в SQLPlus командой вида:

SQL> alter user SAPSR3 account unlock;

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

SQL> alter profile default limit FAILED_LOGIN_ATTEMPTS 50;

Со стороны компании SAP ситуация описана в SAP note 951167 - ORA-28000: the account is locked.

P.S. Думаю, что описанная ситуация довольно таки редкая и возможна только в узком круге версий систем SAP и базы данных Oracle. Так как в современных версиях систем пароль хранится уже не в базе, а в файловой системе (подробнее) и попыток попасть в базу данных со стандартным (неверным) паролем не производится. Но в нашей жизни всё бывает и надо быть готовым ко всему.

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

Как рабочие процессы SAP соединяются с базой данных Oracle - II

В первой части статьи я описал как в SAP системе рабочий процесс, используя двух этапный механизм, определяет пароль владельца ABAP схемы (SAP<SCHEMA-ID>) и подключается с помощью этого пользователя к базе данных Oracle.

Такой механизм использовался до версии Oracle 11g. Но с выходом базы данных Oracle 11g оказалось, что это последняя версия СУБД от Oracle, которая поддерживает OPS$-механизм для удалённого соединения с ней. В связи с этим компания SAP также внесла поправки в работу своих приложений. И начиная с SAP kernel Release 7.20 (примерно с 100 пакета поддержки) представила новый метод для хранения пароля владельца базы данных и соединения с ней. В SAP kernel Release 7.20 зашифрованный пароль для пользователя базы данных может хранится не в базе данных, а на уровне файловой системы. Такой способ называется Secure Storage in File System (SSFS). 

И в этом случае рабочий процесс открывает соединение с базой данных в один шаг, читая контактную информацию и пароль пользователя из защищённого хранилища (рис. 1).

Рис. 1. Пример сообщений из журнала рабочего процесса при коннекте с базой данных новым способом.

Для того, чтобы рабочие процессы и внешние утилиты SAP (R3load, R3trans) использовали новый метод, необходимо в DEFAULT профиль SAP инстанции добавить ряд параметров (рис. 2). Про профили и параметры SAP системы я уже рассказывал в своё время в статьях (1, 2).

Одновременно должны быть установлены переменные окружения пользователя операционной системы <sid>adm (рис. 3).

Рис. 2. Параметры SAP инстанции, связанные с SSFS способом коннекта. 

Рис. 3. Переменные окружения пользователя ОС для SAP системы, связанные с SSFS способом коннекта. 

На уровне операционной системы в директории /usr/sap/<SID>/SYS/global/security созданы специальные директории и файлы со строгими правами на доступ (рис. 4). В файле SSFS_<SID>.DAT хранится как раз информация необходимая для соединения с базой данных, включая зашифрованный пароль владельца схемы.

Рис. 4. Список директорий и файлов, хранящих информацию для соединения с базой данных.

Для просмотра содержимого хранилища в SAP Kernel есть утилита rsecssfx. Набрав одноимённую команду, можно получить список всех записей (опция list) или содержимое отдельной записи (опция get). Содержимое записи с паролем зашифровано и не будет показано в целях безопасности (рис. 5).

Рис. 5. Пример использования команды rsecssfx.

Вот так работает новый механизм хранения владельца схемы, включая его пароль.

Для обратной совместимости, вплоть до версий SAP Kernel 7.38 и базы данных Oracle 11.2, поддерживается одновременно и старый, двух этапный, метод. Хотя SAP уже в этих версиях рекомендует переходить на новый метод хранения пароля на уровне файловой системы. Ведь сделать это можно даже в системах на базе SAP NetWeaver 7.0, так как эти программные продукты поддерживают SAP Kernel 7.20. Переход на это ядро я описывал в одноимённом посте.  

И стоит иметь в виду, что если в Oracle 11g установить параметры профиля REMOTE_OS_AUTHENT=TRUE, то при старте инстанции в терминале или в системном журнале можно увидеть сообщения об ошибке вида:

• ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance,
• ORA-32006: REMOTE_OS_AUTHENT initialization parameter has been deprecated.

Эти сообщения можно проигнорировать, так как не смотря на них старый механизм всё ещё будет работать. Необходим он, если в UNIX системах утилиты SAP BR*Tools и рабочие процессы SAP всё ещё используют OPS$-механизм, который и требует установки параметра REMOTE_OS_AUTHENT=TRUE. 

Ну а начиная с SAP Kernel 7.40 поддерживается только SSFS механизм хранения пароля пользователя SAP<SCHEMA-ID>.

Для смены пароля владельца схемы необходимо пользоваться SAP утилитами BR*Tools (версия не ниже 7.20 пакет поддержки 28). Команда вида:

> brconnect -u / -f chpass 

изменит пароль и в системных таблицах Oracle, и в защищенном SSFS хранилище.

Есть правда небольшой нюанс на переходных системах, там где возможна работа обоих методов. Такая команда при выполнении проверит есть ли таблица OPS$<USER>.SAPUSER. И если она ещё существует в базе данных, то пароль пользователя изменится в ней, а новое хранилище SSFS будет проигнорировано. Поэтому при переходе на новый метод необходимо эту таблицу удалить.

Либо в команде BRCONNECT можно использовать дополнительную опцию "-s|-secstore", где можно указать поменять пароль для коннекта рабочими процессами ABAP инстанции. Например, командой вида:

> brconnect -u / -c -f chpass -o SAPSR3 -p <new_password> -s abap 

При использовании этой опции пароль будет изменён именно в SSFS хранилище, а наличие таблицы OPS$<USER>.SAPUSER будет проигнорировано.


OPS$-механизм, который я описывал в прошлой части может быть использован не только для удалённого соединения, но и для локального. И даже в версиях Oracle 12c и выше локальное соединение с использованием OPS$-механизма всё еще поддерживается. Его могут использовать, например, утилиты BR*Tools или администратор при выполнении операций с базой данных (в утилите SQLPlus). 

Но если вы хотите от него отказаться окончательно, то можно его заменить на специального пользователя BRT$ADM, с помощью которого утилиты из набора BR*Tools и будут открывать соединение и  выполнять задачи по администрированию базы данных. После создания такого пользователя OPS$-пользователей из базы данных можно окончательно удалить. Подробности про этот переход и про работу BR*Tools, включая вопросы смены пароля владельца схемы в SSFS, можно найти в SAP note # 1764043 - Support for secure storage in BR*Tools.

Также на данную тему советую изучить SAP notes:

• 1611877 - Support for ABAP SSFS during database connect,
• 1622837 - Secure connection of AS ABAP to Oracle via SSFS,
• 1639578 - SSFS as password store for primary database connect.

В них детально описано как перевести систему на новый метод хранения пароля и соединения с базой данных. 

Стоит ещё отметить, что SSFS механизм хранения пароля владельца схемы используется не только при разворачивании системы на Oracle, но и при работе с Sybase ASE, SAP HANA и SAP MaxDB (см. SAP note 1639578).

А если хотите погрузиться в администрирование базы данных Oracle на практике, то добро пожаловать в мой авторский курс по SAP Basis. 

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

Как рабочие процессы SAP соединяются с базой данных Oracle - I

Как вы знаете, основными "рабочими лошадками" SAP инстанции являются рабочие процессы (SAP Work Processes или WP), которыми управляет диспетчер. В случае с AS ABAP это ABAP диспетчер. При использовании с SAP системой СУБД Oracle рабочие процессы SAP инстанции для корректной работы должны соединиться с базой данных. После открытия соединения каждому рабочему процессу SAP будет соответствовать один процесс на уровне СУБД, так называемый shadow-процесс.
При этом на сервере приложений SAP на уровне операционной системы рабочие процессы запускаются и работают под пользователем <sid>adm (в UNIX) или SAPService<SID> (в случае Windows). В свою очередь все таблицы и индексы в базе данных, которые используются текущей SAP системой, принадлежат одному пользователю базы данных. Этот пользователь называется владельцем схемы (которая объединяет все таблицы и индексы) и имеет имя SAP<SCHEMA-ID>. Стандартно в SAP инсталляциях имя владельца схемы - SAPSR3,  но иногда может быть SAP<SID>, а в старых системах пользователь носил имя - SAPR3 (до версии SAP Basis 4.6D). Владельца схемы в текущей инсталляции можно определить, если на начальном экране в системе выбрать пункт меню «Система -> Статус…» (рис. 1 и 2).

Рис. 1. Просмотр владельца схемы в базе данных.

Рис. 2. Пример владельца схемы в базе данных.

Для получения полного доступа к таблицам базы данных рабочие процессы SAP инстанции должны соединяться именно под этим пользователем. Данный пользователь на уровне Oracle (как и любой другой) защищён паролем. Но рабочие процессы SAP не знают этот пароль, так как это пользователь другого уровня, не уровня сервера приложений. Поэтому в своих решениях для рабочих процессов SAP использует механизм, который позволяет узнать пароль владельца схемы в процессе создания соединения. Об этом механизме я и хотел сегодня рассказать.

Данный механизм основан на сохранении пароля пользователя SAP<SCHEMA-ID> не только в системной таблице Oracle (в которой хранятся пароли всех пользователей на уровне базы данных), а еще и в специальной таблице. Специальная таблица имеет имя SAPUSER, и принадлежит схеме другого пользователя базы данных - OPS$<SID>ADM (в UNIX) или OPS$<DOMAIN>\<SID>ADM (в Windows). В Windows, к этой таблице также имеет доступ пользователь OPS$<DOMAIN>\SAPService<SID>, от которого и работают рабочие процессы SAP, как я написал выше.

Небольшое отступление про OPS$-пользователей (OPS$<USERS>) или OPS$-механизм базы данных Oracle. При разворачивании SAP системы, на этапе установки базы данных Oracle, программа установки спрашивает пароли для создаваемых пользователей: SYS, SYSTEM и SAP<SCHEMA-ID>. Это отдельные пользователи базы данных, которые создаются на уровне Oracle. Но помимо этих пользователей, программа установки создаёт отдельную группу пользователей, которые используют механизм Oracle, называемый "OS authentication". Эти пользователи имеют префикс "OPS$" и содержат имя пользователя операционной системы. Для UNIX систем это OPS$<SID>ADM, OPS$ORA<SID> и, в последних релизах Oracle, OPS$ORACLE. А для Windows соответственно OPS$<DOMAIN>\SAPService<SID> и OPS$<DOMAIN>\<SID>ADM. Заметьте, что в случае с Windows обязательное условие это добавление домена в имя OPS$-пользователя. Если сервер не в домене, то используется hostname сервера (рис. 3). 

Рис. 3. Пример списка пользователей базы данных Oracle, развернутой в ОС Linux.

OPS$-механизм разрешает пользователям операционной системы (для которых создан соответствующий OPS$<USER>) соединяться с базой данных без ввода пароля. То есть аутентификация пользователя переносится на уровень операционной системы, где и проводится проверка пароля.

Для активации OPS$-механизма необходима установка двух параметров инстанции Oracle:

• REMOTE_OS_AUTHENT=TRUE – разрешает удалённое соединение (OS authentication) для тех пользователей операционной системы UNIX, у которых в базе данных есть соответствующий OPS$-пользователь. То есть соединение возможно с любого компьютера в сети, с которого возможно открыть соединение с базой данных,
• OS_AUTHENT_PREFIX=OPS$ - начальный префикс для таких пользователей в базе данных. Для SAP систем значение по умолчанию "OPS$".

Теперь вернёмся к вопросам соединения рабочих процессов SAP инстанции к базе данных Oracle.

SAP инстанция может работать как на том же сервере, где работает сервер базы данных, так и на отдельном сервере. Поэтому при старте рабочего процесса он не знает: база данных доступна локально или удаленно. Следовательно в Oracle должен быть разрешён удаленный логин (параметр REMOTE_OS_AUTHENT). Стоит сразу обозначить, что в целях обеспечения безопасности права OPS$-пользователя ограничены. Он может лишь присоединиться к базе данных и прочитать запись только в таблице SAPUSER, так как эта таблица принадлежит ему. Читать, добавлять или изменять данные в других SAP таблицах (в основной схеме базы данных) ему запрещено.

Рис. 4. Схема соединения рабочих процессов SAP к базе данных Oracle.

Когда рабочий процесс SAP запускается и пытается соединиться с базой данных Oracle, он выполняет следующие шаги (рис. 4):

1. Рабочий процесс открывает коннект к базе данных как соответствующий OPS$-пользователь с аутентификацией на уровне операционной системы.
2. С помощью SQL-запроса SELECT к таблице SAPUSER рабочий процесс читает пароль пользователя SAP<SCHEMA-ID>.
3. Текущее соединение с базой данных Oracle закрывается.
4. Рабочий процесс открывает новое соединение с использованием уже пользователя SAP<SCHEMA-ID> и пароля, который он получил на предыдущем этапе из таблицы SAPUSER.

Если один из вышеуказанных шагов по какой-то причине не выполнен, то соединение не устанавливается и рабочий процесс на уровне операционной системы сервера останавливается с ошибкой.

А вот как этот процесс коннекта к базе данных выглядит на уровне сообщений журнала рабочего процесса SAP (рис. 5).

Рис. 5. Пример журнала рабочего процесса SAP.

Также стоить добавить, что такой двух этапный механизм коннекта к базе данных используют не только рабочие процессы, но и некоторые SAP утилиты. Например, R3trans или R3load. 

Для смены пароля владельца схемы (пользователь SAP<SCHEMA-ID>) нельзя использовать методы базы данных Oracle (например, команду password) (рис. 6). Так как в этом случае пароль изменится только в системных таблицах Oracle, а в таблице OPS$<USER>.SAPUSER останется старым и рабочие процессы не смогут соединиться с базой данных (рис. 7).

Рис. 6. Пример смены пароля владельца схемы методами Oracle.

Рис. 7. Пример ошибки при попытке рабочего процесса открыть соединение с базой данных.

Чтобы смена пароля не привела к ошибкам в работе системы, для этой операции необходимо использовать утилиты BR*Tools (в старых системах - SAPDBA). Про эти утилиты я писал в этой статье. Утилита от SAP изменит пароль владельца схемы не только в системных таблицах Oracle, но и таблице OPS$<USER>.SAPUSER. А это обеспечит корректную работу описанного выше механизма соединения рабочих процессов (рис. 8 и 9).

Рис. 8. Корректный способ смены пароля владельца схемы - 1.

Рис. 9. Корректный способ смены пароля владельца схемы - 2.

А если обратить внимание, что на нижнем уровне в brtools запускается утилита BRCONNECT, то пароль можно сменить, запустив эту программу напрямую одной командой вида:

> brconnect -u / -f chpass 

Хотя пароль владельца схемы в таблице SAPUSER и хранится в зашифрованном виде, рекомендую дополнительно ознакомиться с рекомендациями по организации более безопасной инфраструктуры, прочитав SAP note #157499 - OPS$ connect and security aspects. Там описано, например, как ограничить список IP-адресов машин, с которых возможен удалённый коннект к серверу базы данных, используя OPS$-механизм. 

А начиная с Oracle 11g была прекращена поддержка со стороны Oracle OPS$-механизма для удалённого подключения и, SAP (начиная с SAP Kernel 7.20) стал использовать новый механизм для организации соединения рабочих процессов SAP и базы данных. Но об этом я расскажу уже во второй части статьи. 

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

Фоновые задания в SAP системе - I

Сегодня я хотел бы поговорить про фоновую обработку в SAP системе. 

Как вы уже знаете (например, из этого поста), работа пользователей в ABAP-части SAP системы возможна в двух режимах - диалоговом и фоновом. 

Фоновый (background) режим работы используется для запуска долгих тяжелых отчетов или стандартных периодических заданий для обслуживания SAP системы (задания, собирающие различную статистику, проводящие чистку и тому подобное). Для работы ABAP-программы в фоновом режиме используются фоновые задания. Особенностью фоновых заданий является то, что они не требуют постоянного коннекта пользователя с системой посредством SAP GUI. То есть пользователь планирует задание после чего может выйти из системы, а программа запустится и отработает без него. Этот факт некоторым образом ограничивает тип запускаемой программы - не работают функции связанные с рабочей станцией пользователя. Например, Frontend печать или загрузка данных с компьютера пользователя. Но в остальных случаях фоновая обработка это удобно. 

Сразу отмечу тот момент, что в целом ABAP-программа в фоне работает не быстрее и  не медленнее, чем в диалоговом режиме. Но благодаря особенностям фоновой обработки мы можем запланировать выполнение программы без нашего участия в тот момент, когда нагрузка на систему минимальна. И в этом сила фоновой обработки. Есть ещё небольшие особенности в выделении памяти рабочему процессу и в фиксировании/откате изменений в базе данных. Но они не значительны.

Планирование фоновых заданий производится в транзакции SM36 (рис. 1). 

Рис. 1.Транзакция SM36: пример планирования фонового задания.

Данная транзакция обладает широкими возможностями по планированию. 

Сначала необходимо определить имя фонового задания. Указать его класс и цель выполнения (рис. 1: поля области 1). 

Цель выполнения это конкретная инстанция данной системы, у которой есть хотя бы один фоновый процесс. 

Ведь вы помните, что за обработку фоновых заданий в системе отвечают рабочие процессы специального типа - фоновые (тип BTC). Количество рабочих процессов данного типа настраивается через SAP параметр rdisp/wp_no_btc.

Заполнять поле "Цель выполнения" не обязательно. Можно оставить его пустым, тогда система сама выберет на какой инстанции выполнить обработку, используя механизмы балансировки нагрузки.

А ещё в качестве цели выполнения можно указать группу серверов фоновой обработки. Управление группами серверов для фоновой обработки осуществляется в  транзакции SM61. Ситуация аналогичная Logon Group для диалоговой обработки (транзакция SMLG). Создаёте группу и включаете в неё инстанции. Причём, для исключения какого-то сервера из обработки можно создать группу с именем SAP_DEFAULT_BTC. После этого включаете в неё все инстанции кроме той (тех), что хотите исключить. В результате, если при планировании поле "Цель выполнения" оставить пустым, то планировщик выберет инстанцию из тех, что включены в группу SAP_DEFAULT_BTC. Подробности можно найти в SAP note 786412 - Determining execution server of jobs w/o target server. 

Теперь про классы. Классов заданий в системе 3: A, B и C. Классы имеют разный приоритет. A - самый высокий, C - самый низкий. Имейте в виду, что приоритеты используются только при запуске задания. Если при выборе очередного задания для старта в очереди окажется несколько заданий, которые уже можно запустить, то планировщик будет выбирать и запускать задания основываясь на приоритете (рис. 2).

Рис. 2. Приоритет фоновых заданий, используемый при планировании запуска.

При этом важно запомнить, что на скорость выполнения конкретного задания, приоритет влияния не имеет. Только на планирование. 

Дополнительно существует возможность выделить часть фоновых рабочих процессов инстанции для выполнения только заданий класса A. Сделать это можно при активации и настройки режимов работы инстанции (транзакция RZ04). В этом случае при планировании фоновых заданий данные рабочие процессы не будут участвовать в обработке фоновых заданий классов B и С. Но злоупотреблять этой возможностью не рекомендуется, так как можно получить обратный эффект и снизить общее время выполнения всех фоновых заданий в системе. Потому что большинство заданий в системе (70% и более) имеют приоритет C. Даже стандартные фоновые задания или системные задания, планируемые в календаре транзакции DB13.

Далее при создании фонового задания необходимо задать шаги задания (рис. 1: кнопка 3). Шагов может быть несколько. В качестве шага задания может выступать ABAP-программа, внешняя команда или внешняя программа. Если ABAP-программа имеет экран выбора, то предварительно необходимо создать вариант с заполненными полями экрана. Этот вариант экрана указывается вместе с ABAP-программой при планировании. Про внешние команды операционной системы у меня был отдельный пост.

После указания шагов задания необходимо зафиксировать условия запуска задания (рис. 1: кнопка 2). Выбор достаточно широкий (рис. 3).

Рис. 3. Условия запуска фонового задания.

Можно запустить задание сразу же после окончания процесса создания (кнопка "Немедл-но"). А можно задать точные дату и время запуска (кнопка "Дата/Время"). 

При этом есть очень интересная функция - указать дату и время после которого задание не должно пытаться выполниться. Полезно это бывает вот когда. Например, ваше фоновое задание должно выполняться во время низкой нагрузки на систему, ночью. Вы указали время запуска на вечер. Но нет гарантии, что планировщик запланирует ваше задание точно в указанное время, так как фоновые процессы системы могут быть заняты или система может быть недоступна (офлайн бэкап). В итоге, может оказаться так, что задание провисит в очереди к запуску всю ночь и запустится только утром, резко снизив производительность системы для диалоговых пользователей в часы пик. Чтобы этого не произошло, необходимо указать при планировании крайнее время запуска в поле "Не запускать после".

Также в качестве условия запуска задания можно указать время окончания другого фонового задания (кнопка "ПослеЗдн"). Таким образом, можно выстроить цепочку фоновых заданий, которые будут выполняться друг за другом. Причём, можно анализировать статус (указывается дополнительно), с которым выполнилось предыдущее задание. В этом случае последующее задание запустится лишь в том случае, если предыдущее выполнилось успешно (с кодом 0).

Кому и этого мало, то можно указать в качестве условия запуска - системное событие или смену режима работы системы (настройка в транзакции RZ04).

Ещё один нюанс в планировании заданий - можно создавать периодические задания, нажав на кнопку "Значения периодов" и выбрав нужный период (рис. 3).

Ну и последний нюанс при создании фонового задания. Просмотреть результаты работы фонового задания можно после его окончания через систему спула. Причем, если вы хотите чтобы другой пользователь системы получил вывод работы задания в свой запрос спула, то это можно отдельно указать (рис. 1: кнопка 4).

Создать фоновое задание можно так, как я только что описал, а можно вызвать Ассистента по заданиям (кнопка на панели начального экрана транзакции SM36) и пройти все шаги с его помощью.

Еще есть возможность запуска транзакции в фоновом режиме прямо из самой транзакции. Это можно сделать только в том случае, если на начальном экране транзакции есть пункт меню "Программа -> Фоновое выполнение" (рис. 4). Выбрав этот пункт, вы запланируете фоновое задание, в котором автоматически с текущей программой будет добавлен вариант экрана с уже введёнными значениями в полях.

Рис. 4. Пример фонового выполнения диалоговой программы.

На сегодня это всё. Продолжение можно прочитать тут.

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

Саповские секретики - VII

Секретик 1.

Транзакция SM50 отображает список рабочих процессов, которые сконфигурированы в текущей SAP инстанции. Количество рабочих процессов разного назначения настраивается через набор SAP параметров вида rdisp/wp_no_*. Нехватка рабочих процессов, в зависимости от типа, приводит к увеличению заданий в очереди ABAP-диспетчера, "зависанию" во время диалоговой работы, задержкам при запуске фоновых заданий и т.п. При чрезмерном количестве рабочих процессов происходит не оптимальное использование ресурсов сервера. Для мониторинга при настройке оптимального количества рабочих процессов инстанции помогут возможности транзакции SM50. На основном экране транзакции на верхней панели есть кнопка "CPU" (рис. 1).

Рис. 1. Начальный экран транзакции SM50.

После нажатия на данную кнопку напротив каждого рабочего процесса появится время, в течении которого соответствующий процесс операционной системы реально использовал ресурсы центрального процессора (рис. 2).

Рис. 2. Отображение реального времени работы рабочего процесса.

Если данное число после 2-4 недель работы инстанции равно 0, значит ABAP-диспетчер ни разу не давал задания данному рабочему процессу. Если вы обнаружили много таких процессов одного типа, то часть из них можно смело удалить. 

Главное не принимайте такое решение на основании короткого времени работы инстанции. Особенно, если у вас есть редкие кратковременные пиковые дни работы системы, а инстанция не пережила такой день после своего старта.

В последних версиях SAP систем, после обновления транзакции SM50, данные временные значения отображаются постоянно.

Секретик 2.

В транзакции SM04 отображается список пользователей, которые выполнили вход в систему на текущей SAP инстанции. Дополнительно, используя данную транзакцию можно проводить мониторинг версии клиентского программного обеспечения SAP GUI, которое использовал пользователь, а так же IP адрес, с которого был выполнен вход в систему. Для этого на панели на основном экране транзакции необходимо войти в настройки варианта просмотра (рис. 3).

Рис. 3. Настройки варианта просмотра экрана в транзакции SM04.

В диалоговом окне добавить поля "Версия GUI" и "IP-адрес" и нажать кнопку "Скопировать" (рис. 4). 

Рис. 4. Настройка видимых полей транзакции SM04.

После этого в соответствующих полях отобразится информация по пользователям, выполнившим вход в систему (рис. 5).

Рис. 5. Информация по версиям SAP GUI и IP-адресам пользователей.

Секретик 3.

Если SAP система работает на операционной системе UNIX-like, Linux в том числе, то будет полезно знать, что у пользователя операционной системы <sid>adm есть ряд настроенных псевдонимов (aliases) для команд. Например,

• cdexe - переход в директорию с SAP Kernel.
• cdpro - переход в директорию с профилями SAP.
• cdDi - переход в директорию текущей инстанции.

Рис. 6. Пример использования alias для пользователя <sid>adm.

Все активные псевдонимы можно посмотреть выполнив команду alias (рис. 7).

Псевдонимы настраиваются в профайлах пользователя операционной системы. Найти их можно набрав команду в домашней директории пользователя:

grep alias .*

Хотите попробовать администрирование SAP системы в операционной системе Linux?
Посмотрите мои новые обучающие пакеты практических заданий.

Предыдущие выпуски:
- Саповские секретики - I,
- Саповские секретики - II,
- Саповские секретики - III,
- Саповские секретики - IV,
- Саповские секретики - V,
- Саповские секретики - VI.


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