Добрый день.

У нас есть такая проблема: Делаем автоматическом выравнивании всех дебиторов, с количеством прогонов в пределах 30 в фоновом режиме по нескольким БЕ. Обычно задание отрабатывает в пределах 4000 секунд. Но периодически, и теперь довольно часто, это выравнивание зависает - вернее оно может выполниться, но в десятки раз дольше, что, естественно, неприемлемо. Практика показала, что это случается из-за того, что не правильно строится запрос в базу данных таблиц BSID и BSAD. В этом случае помогает лишь сброс статистики запроса в базу данных - тогда всё начинает работать нормально. Но при следующем выравнивании всё сбивается заново. Есть предположение, что большое количество записей в таблице BSAD и большое количество выбираемых данных как-то сбивает план запроса в базу данных.

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

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

Может быть кто-то сталкивался с такой проблемой? Может это решается какой-то стандартной процедурой?

Все зависит от того, чем вы выравниваете - стандартом или Z-кувалдой. Если стандартом, то все должно работать нормально при условии что ваши админы вовремя тюнят перформанс. А если Z- то к абаперам, разбираться как они там что наваяли
На всякий случай попросите полномочия на всякие ST02.

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

Выравниваем стандартом - всё и работает нормально до определённого момента, который сбивает план запроса в базу данных. После чего обычный селект из BSAD начинает выполняться очень долго, что заметно в отладке и SM66.

А что такое "вовремя тюнят перформанс" - там какие-то процедуры нужно делать периодически или по факту чего-то?



В частности это селект:
select (BSID_FIELDS) from BSAD
into corresponding fields of table XBSAD
for all entries in K_KUNNR
where KUNNR eq K_KUNNR-LOW
and BUKRS in DD_BUKRS
* AND GJAHR IN DD_GJAHR
* AND AUGDT BETWEEN '00010101'
* AND '99991231'
and BUDAT in DD_BUDAT
and BUDAT le DD_STIDA
and AUGDT gt DD_STIDA
and ZUONR in DD_ZUONR
and SHKZG in DD_SHKZG
and UMSKZ in DD_UMSKZ
and BSCHL in DD_BSCHL
and (BSID_WHERE).

В программе SAPDBDDF. form UPDATE_XBSAD.

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

Что-то я туда не попадаю...
Скажите транзакцию и какие документы выравниваете (параметры запуска).

Выравниваю дебиторов - авансы и счёта-фактуры в транзакции J3RCALD. Выравнивание идёт по договору (поле Присвоение - указано в настройках).
Правила выравнивания:
Один платёж > несколько счетов
Обязат. ссылка на счет-факт.
C частичным платежом
Сортировка по дате проводки
Процедура выравнивания EINGZAHL
Валютный курс счета-фактуры

Этот селект у меня совсем не работает, BSID_FIELDS пустой.
Я думаю, что ваша проблема в BSID_WHERE. Он у вас чем-то заполняется, при определенных условиях, и начинаются тормоза.
Я бы сделал временный энхансмент перед селектом (селект в подпрограмме, так что в начале подпрограммы можно вставить свой код).
и отловить ситуацию, когда BSID_WHERE будет не пустой.

Спасибо. Попробую сделать так, как только снова начнутся проблемы.
Сейчас сбоев не наблюдается: я разбил выравнивание на несколько этапов по 10000 дебиторов в каждом. Т. е. сейчас есть подозрение, что возможно проблема была в объёме данных.