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

С одной стороны администратор – это человек которому ничего не говорят транзакции и объекты бизнес-процессов, а с другой стороны консультанты и пользователи ничего не смыслят в базисе и программировании.

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

Самое главное – это выбрать достаточно точные шаги по многоразовому воспроизведению проблемы.

Один из основных – это динамический анализ (транзакция SE30).

 

Указываем нужную транзакцию и нажимаем “Выполнить”. Затем проходим нужные шаги, где обнаруживается проблема производительности.

Если программа хорошо “повисела” для анализа, то можно и скинуть её через меню окна:

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

Затем заходим снова в транзакцию SE30, и уже в нижней части окна смотрим на образовавшийся журнал:

Нажимаем кнопку “Анализ” и смотрим на диаграмму:

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

Затем щёлкаем по иконке рангового списка и получаем развёрнутый анализ:

И вот на этом этапе уже нужно “включать мозги” и анализировать.

Данный пример очень простой:  “Нетто” одной операции занимает всё основное время работы (247 206 049 микросекунд = 247 секунд):

Здесь и кроется проблема – проблема в выборке из таблицы MSEG.

Выделяем строку, нажимаем кнопку “Просмотреть исходный текст” и попадаем на нужный кусок программы:

В данном случае мы видим, что данный оператор выполнялся как минимум 247 секунд, что является недопустимым.

Если копнуть в эту таблицу, то можно обнаружить что:

• MSEG – важная таблица модуля MM (документы материалов)
• В таблице хранятся миллионы записей
• К таблице привёрнуто недавно два Z-индекса

Можно включить отладку, можно посмотреть индексы данной таблицы – здесь уже начинаются вариации на каждый конкретный случай. А можно сразу обратиться к администраторам или разработчикам для решения этой проблемы – локализация проблемы выполнена почти полностью.

Базисники или разработчики разбираются с проблемой, после этого проверяется решение и делаются выводы – может быть необходим ещё один шаг трассировки производительности.

PS. О трассировке SQL и других мелких полезняшках может расскажу как-нибудь потом при подвернувшемся случае.