Оптимизация Z-транзакций модуля ТОРО с целью повышения скорости обработки данных

Предпосылки

После любого внедрения системы SAP наступает не менее важный процесс ее сопровождения и последующего развития. Зачастую команда поддержки сталкивается с тем, что при создании Z-транзакций (ABAP-разработок) не учтено влияние роста объёма исторических данных на время выполнения этих транзакций.

В связи с этим команда поддержки (сопровождения) систем сталкивается, в том числе, и с необходимостью оптимизации внедрённого Z-функционала.

Рассматриваемая проблема

Рассмотрим один из подходов, который был использован при оптимизации Z-функционала, относящегося к бизнес-процессу планирования и выполнения ТОРО.

У заказчика в течение нескольких лет существования системы росло число заказов на технические обслуживание:

  • 2007 г. 90.265 шт.
  • 2008 г. 118.860 шт.
  • 2009 г. 194.208 шт.
  • 2010 г. 323.490 шт.
  • 2011 г. 357.074 шт.
  • 2012 г. 364.935 шт.
  • 2013 г. 406.250 шт.
  • 2014 г. 486.742 шт.

Разработанная в рамках внедрения основная рабочая Z-транзакция пользователя, вследствие накопления большого количества данных, перестала удовлетворять бизнес в части производительности. Попытка запуска транзакции с целью получить консолидированные данные за квартал по нескольким подразделениям компании заказчика часто заканчивалась дампом по тайм-ауту (2 часа). При этом накопительные отчеты за полугодие или год однозначно переставали работать.

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

При запуске с использованием таких же параметров стандартные транзакции SAP (IW39) также не обеспечивали необходимой скорости обработки и не могли послужить альтернативой.

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

Был выполнен анализ работы программы, определены узкие места и предложено решение, которое позволило увеличить быстродействие транзакции почти в 3 раза.

Решение по оптимизации:

Теперь расскажу несколько подробнее о том, как выполнялась оптимизация.

Шаг 1

Определены наиболее часто используемые параметры, с которыми шла запускаемая программа:

  • завод «WERK»
  • периоды (базисный срок начала «GSTRP», базисный срок конца «GLTRP»)

Шаг 2

Выполнена трассировка и анализ «узких» мест работы программы (Табл. 1).

Таб. 1. Анализ узких мест программы

Селект

Замечания

  SELECT caufv~aufnr
             caufv~ktext
             caufv~bukrs
             caufv~werks
             caufv~objnr
             caufv~prctr
             caufv~pspel
             caufv~zz_doknr
             caufv~zz_lifnr
             caufv~zz_dokar
             caufv~zz_ei
             caufv~zz_kolvo AS zz_kolvo_c
             caufv~zz_kolvo_f AS zz_kolvo_fc
             caufv~zz_ncomp
             caufv~zz_sposob
             caufv~zz_out_number
             caufv~zz_fin_number
             caufv~zz_o_data
             caufv~zz_f_data
             caufv~zz_quality
             caufv~func_area
             caufv~gltrp
             caufv~gstrp
             caufv~aufpl
             caufv~vaplz
             caufv~maufnr
             caufv~zz_idifp AS zidifp
        APPENDING CORRESPONDING FIELDS OF TABLE lt_caufv[]
        FROM caufv JOIN fmzuob ON fmzuob~objnr = caufv~objnr
        FOR ALL entries IN _t_so_params
        WHERE caufv~auart         = _t_so_params-auart AND
              caufv~autyp         = '30'         AND
              caufv~werks         = _t_so_params-werks AND
              caufv~prctr         IN so_prktr    AND
              caufv~pspel         IN so_proid    AND
              caufv~pspel         <> ' '         AND
              caufv~func_area     IN so_fa       AND
              caufv~zz_doknr      IN so_doknr    AND
              caufv~zz_lifnr      IN so_lifnr    AND
              caufv~zz_sposob     IN so_sv       AND
              caufv~zz_out_number IN so_onum     AND
              caufv~zz_fin_number IN so_fnum     AND
              caufv~zz_quality    IN so_q        AND
              caufv~gltrp         IN so_gltrp    AND
              caufv~gstrp         IN so_gltrp    AND
              fmzuob~fonds        IN so_fgber.

Пользователи чаще всего выбирают по периоду и заводу. В этом селекте это не учитывается. Следовательно, выбираются все сообщения ТОРО + все заказы ТОРО по данному заводу во внутреннюю таблицу.

Шаг 3

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

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

Для быстрого выбора заказов:

1.      В таблицу AUFK (соответственно, и в ракурс CAUFV) добавлены Z-поля: ZZ_AFKO_GLTRP и ZZ_AFKO_GSTRP (Рис. 1).

Ограниченный доступ

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

Комментарии:

Олег Точенюк (Рейтинг: 10189) 11:37, 21 мая 2014

1. Ну я так понял администратора базиса и СУБД у вас нет, так что про статистику и индексы БД вместе с планами выполнения запросов никто не только не слышал, но даже и не думал.
 
2. Тему про завод в первом селекте не понял, так как там в условиях явно есть: caufv~werks = _t_so_params-werks.
 
3. Если писать, что "Доработан User Exit на сохранение заказа ТОРО (создание и изменение), который записывает данные", то было бы не плохо указать имя экзита. Ясно что кому надо найдут, но зачем же еще где-то искать, если как бы есть статья.
14:34, 28 мая 2014

Валерия Лакшевич (Рейтинг: 13)

В ответ на вопросы Олега Точенюка:
1. Перед выполнением работ по оптимизации планы SQL-запросов были проанализированы (транзакция ST05). Выборка данных ТОРО осуществлялась неэффективным образом. Статистика и индексы таблиц БД поддерживаются службой базиса в актуальном состоянии.
2. Не вполне понятен вопрос
3. Указанная выборка данных реализована в USER EXIT EXIT_SAPLCOIH_009 «PM Order: Customer Check for 'Save' Event». На текущий момент код перенесен в одну из пользовательских реализаций BADI WORKORDER_UPDATE в метод AT_SAVE() на событии сохранения заказа ТОРО.
16:21, 28 мая 2014

Олег Точенюк (Рейтинг: 10189)

1. Ну вот бы и начали статью с анализа планов запроса до и после оптимизации, а то из нее вообще не понятно было а что собственно делал базис.
 
2. У вас там в тексте идет:
=
Определены наиболее часто используемые параметры, с которыми шла запускаемая программа:
 
завод «WERK»
=
В оригинальном запросе и оптимизированном это поле есть.

Николай Кронский (Рейтинг: 345) 13:57, 03 июня 2014

Признаться, не осознал всей глубины статьи :)
Во-первых, без анализа плана запроса до и после изменений вообще разговор не по существу - читатель не видит актуальной картины выполнения запроса, которую можно обсуждать.
Во-вторых, мне показалось, что ввести поле Завода в таблицу AFKO гораздо проще, чем поля в AUFK. Все-таки, РР-заказы составляют только часть из общей массы данных в AUFK. Да и вообще, индекс на свободно изменяемые поля "попахивает" фрагментацией оного и, в конце концов, приведет к еще более серьезной проблеме производительности.
В-третьих, поскольку про АВАР-оптимизацию говорить не получается (см. п.1), хотелось бы привлечь базисный инструментарий для оценки актуальности используемого индекса, фрагментации (индекса, таблицы, Tablespace'a), загрузки системы в период тестирования и т.п.
В общем, от "руководителей" хотелось бы более серьезного подхода к задаче :)

Андрей Красовский (Рейтинг: 674) 10:21, 22 сентября 2014

Спасибо авторам за поучительную статью, мораль которой в том, что  производительность Z разработок напрямую зависит от профессионализма разработчиков. И очень правильно отмечено, что зачастую не оптимизированные Zки и есть причина проседания производительности всей системы, особенно когда такие разработки имеют массовую популярность у пользователей. Решать подобные проблемы должны не базисники, а разработчики, потому как сбор статистики выполняется если не автоматическом, то в регулярно запланированом режиме. А к созданию индекса нужно подходить с осторожностью и делать это осмысленно, т.к. в одной ситуации он ускоряет выборку из таблицы, а в другой - замедляет вставку.

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»