Блокировки в SAP системе - I

Это первая часть статьи про блокировки в SAP системе. Для начала рассмотрим концепцию SAP блокировок и реализацию механизма в SAP системе.

Концепция

Транзакции базы данных должны удовлетворять концепции LUW (Logical Unit of Work). Понятием LUW обозначают минимальный набор операций изменения данных (SQL-запросы INSERT, MODIFY, UPDATE, DELETE), который переводит базу данных из одного непротиворечивого состояния (consistent state) в другое непротиворечивое состояние. Транзакцию завершает COMMIT, который и вносит изменения в таблицы базы данных. Если во время выполнения LUW происходит сбой, то выполняется откат (ROLLBACK) всех изменений, вносимых текущей LUW. После чего база данных возвращается в предыдущее непротиворечивое состояние.

Если говорить о классических базах данных (исключим SAP HANA), то можно сказать, что система SAP использует базу данных только как хранилище данных. В SAP системе параллельно с базой данных ведётся свой собственный словарь данных. Об этом я рассказывал в этом посте. Этим обеспечивается независимость большинства программных решений компании SAP от платформы, в данном случае, от базы данных.

На уровне сервера приложений SAP существует своё понятие LUW (Logical Unit of Work). Так как SAP система оперирует не отдельными записями, а бизнес-объектами, то SAP транзакция, удовлетворяющая принципам LUW, является более широким понятием, чем транзакция базы данных. Понять разницу поможет следующая схема (рис. 1):

Рис. 1. Концепция блокировки в SAP системе.

   

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

Для обеспечения выполнения транзакций, изменяющих данные, на уровне SAP (LUW уровня сервера приложений) в AS ABAP реализован отдельный механизм блокировок (SAP locks). SAP блокировка работает на уровне бизнес-объектов и может блокировать на уровне базы данных одну или несколько записей в одной или нескольких таблицах. SAP блокировка устанавливается на начальном этапе выполнения SAP транзакции, а удаляется только после успешного или неудачного завершения всей SAP транзакции. В первом случае (согласно концепции LUW) система переходит в следующее непротиворечивое состояние, а во втором возвращается в предыдущее, выполнив откат всех изменений (ROLLBACK).

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

Реализация

Основным компонентом механизма блокировок в SAP системе является специальный сервер блокировок (Enqueue Server или Lock Server). В классической конфигурации сервер блокировок реализуется в виде рабочего процесса блокировки (ENQ) AS ABAP инстанции. Данный рабочий процесс настраивается только на одной AS ABAP инстанции, которая называется центральной (CI или PAS, по новой терминологии) (рис. 2). На других инстанциях, входящих в SAP систему, этого процесса быть не должно. Активация рабочего процесса блокировки производится через параметр инстанции - rdisp/wp_no_enq = 1.

Рис. 2. Рабочий процесс блокировки на центральной инстанции.

В свежих релизах SAP систем сервер блокировок инсталлируется в составе отдельной инстанции центральных сервисов (ASCS instance). В данном случае параметр rdisp/wp_no_enq на всех диалоговых инстанциях должен быть установлен в 0, а параметр enque/process_location = REMOTESA. Все параметры инстанции необходимые для установки в случае использования отдельного сервера блокировок можно найти на этой странице SAP Help Portal.

Сервер блокировок получает запросы на блокировку от рабочих процессов. Чаще всего это диалоговый (DIA) или фоновый (BTC) рабочий процесс. После получения запроса сервер блокировок проверяет существующие записи блокировок и, если пересечений нет, то устанавливает новую блокировку. Затем управление передаётся рабочему процессу инициировавшему блокировку (рис. 1). Стоит дополнительно отметить, что механизм несколько сложнее, чем описан мной. Например, существует несколько режимов блокировки (по частоте использования: E - Exclusive lock, S - Shared lock, X - eXclusive lock и O - Optimistic lock) и коллизии в зависимости от режимов блокирования решаются по-разному. Подробности можно найти на страницах SAP Help Portal, например, тут. 

Блокировки на уровне сервера приложений SAP хранятся в виде записей таблицы блокировок (lock table) в оперативной памяти того же сервера, где настроен сервер блокировок. Параллельно ведётся резервный файл блокировок. Имя файла настраивается через параметр инстанции enque/backup_file. Обычно это файл с именем ENQBCK, лежащий в log директории инстанции. Записи из файла помогают восстановить таблицу блокировок в памяти при рестарте сервера блокировок по той или иной причине.

Мониторинг

Для мониторинга и управления блокировками в SAP системе используется транзакция SM12 (пункт меню «Меню SAP –> Инструменты -> Администрирование -> Монитор –> Записи блокирования»). Транзакция позволяет просматривать таблицу блокировок, анализировать отдельные записи и, в случае необходимости, удалять блокировки вручную.

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

• имя таблицы, записи которой блокированы;
• аргументы блокирования; 
• мандант системы;
• имя пользователя, установившего блокировку (владельца блокировки). 

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

После нажатия на панели кнопки "Список" система отобразит текущее содержимое таблицы блокировок (рис. 4).

Рис. 4. Пример списка блокировок системы SAP.

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

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

Продолжение во второй части.

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