Всем привет! Меня зовут Алексей Пьянков, я эксперт Отдела экспертизы по техническим компонентам SAP компании Норникель. В этой статье поделюсь с вами некоторыми нюансами использования оператора FOR ALL ENTRIES в АВАР.
Регулярно просматривая ракурс m_expensive_statements на БД SAP HANA, которая обслуживает продуктивную систему SAP ERP, временами, замечаю в ТОПе среди большого количества классических записей CALL "CL_J_3RMOBVEDH… , отдельные записи, statement_string которых начинается с SELECT /* FDA WRITE */.
Что это за зверь такой /* FDA WRITE */, почему он лезет в ТОП времени выполнения и как с этим бороться я хотел бы рассказать в этой статье.
FDA это FAST DATA ACCESS - довольно новая по меркам SAP технология, позволяющая быстро передавать содержимое внутренней таблицы с сервера приложений ABAP на сервер БД и обратно.
Когда FDA появляется вместе с WRITE, это значит, что запрос к БД сформирован оператором FOR ALL ENTRIES (FAE).
FOR ALL ENTRIES это оператор языка OPEN SQL, который позволяет выполнить операцию соединения внутренней таблицы с сервера приложений ABAP, с таблицами на стороне сервера БД. Раньше это означало, что некий OPEN SQL запрос с FAE преобразуется движком АВАР в последовательность SQL запросов к БД, в которой, в каждый SQL запрос, в условие WHERE подставляются ограничения, сформированные по строкам внутренней таблицы.
Позже SAP придумал технологию FDA WRITE, которая просто берет внутреннюю таблицу на стороне ABAP, целиком передает ее на сервер базы данных и там выполняет классический SQL JOIN с этой таблицей.
Все происходит за один SQL запрос, быстро и красиво, но случаются нюансы.
И эти нюансы легче всего обнаружить в m_expensive_statements. В поле application_source для соответствующей строки этой таблицы можно найти, что-то похожее на “SAPLRSA3:1422”. Если запустить транзакцию DBA_VIEW_ABAP_SOURCE и скормить ей эти данные, то она бросит вас прямо в редактор кода на то место, где находится пациент.
Итак, встречайте:
Пациент №1:
Код был написан на старте проекта внедрения и успешно работал, не вызывая никаких проблем несколько лет, а потом вдруг начал выполняться часами создавая дикую нагрузку на процессоры БД.
Пациент № 2:
Здесь, внезапно, после переноса небольшого изменения, десяток пользователей, запустивших этот отчет, чуть не обрушили БД. HANA встала колом показывая 100% утилизацию процессора.
Пациент №3:
Лаконично, но очень эффективно. Пара десятков процессов, запустивших это код, создали критическую проблему с быстродействием системы, процессы пришлось рубить руками Базиса.
В этом пациенте я отменил желтым маркером то, что приводит к плачевному результату – сочетание FOR ALL ENTRIES и OR.
Теперь вы можете сами поискать такие сочетания у пациентов №1 и №2. В комментариях напишите – удалось ли найти?
Такие запросы могут легко работать на старте проекта, когда данных в системе немного. Но когда проектная команда уйдет и начнутся будни поддержки, OR в комплекте с FOR ALL ENTRIES однажды гарантировано положат ваш сервер БД.
И это ни какая-то особенность SAP HANA, это всеобщий закон вселенной Баз Данных, про который можно чуть подробнее прочитать, здесь же на Хабре про PostgreSQL – ищите раздел BitmapOr vs UNION.
Собственно, здесь же и содержится ответ, что с этим делать. Нужно просто разбить запрос на два и соединить результаты. Вместо UNION у второго запроса напишите APPENDING TABLE вместо INTO TABLE и SAP опять начнет летать как на старте проекта!
Резюмирую:
Господа АВАРеры, постарайтесь воздержаться от использования OR в запросах с FOR ALL ENTRIES.
PS. Прямо сейчас наблюдаю, как третий час выполняется еще один запрос с FOR ALL ENTRIES, написанный на заре проекта внедрения:
Ставьте лайки, пишите комментарии, делитесь советами, как такое можно оптимизировать.
Помните, оптимизировать нужно только тогда, когда это действительно потребуется, но способы лучше знать заранее.
