а бросьте скрин DB20 по этой таблице

1. Проверьте что индекс точно существует на уровне БД
2. Проверьте когда собиралась статистика по resb в тр. db20, и если давно - то пусть ваш админ выполнит пересбор статистики. Или в любом случае выполнит пересбор, хуже не будет

Что-то там на курсе adm100 говорили, что узкое горшылко SAP - enqueue server, мол любую мощную систему можно завалить запросами на блокировку, записи на блокировку будут вставать в очередь в таблицу блокировок
А что там в SM12 заодно ?

ArmAnn прав, в DB13 то запланировал сбор статистики?

FoLKo, ну вы же сами выложили скриншот explain с full table scan.
Объяснений может быть по большому счету только два:
1. Что-то не то с индексом на уровне БД -> пересоздать индекс через se14 или средствами БД
2. Не собрана статистика -> собрать статистику в программе rsanaora (если у вас Oracle)

Ну можно еще в интерфейсе explain посмотреть как Oracle отреагирует на явное указание индекса в хинте (кнопка "объяснить с советом"). Пример хинта:

Для сравнения можете посмотреть explain в системе, где все хорошо. Ловить когда промелькнет запрос в st04 не надо, есть прекрасная тр. st05

умеючи то можно и сломать кое-что...

есть ноты по оптимизации ENQ, эт рас
есть логический анализ при участии вендоров, эт два...
есть опция тестирования в SM12, эт три
будут массовые ошибки в SM21, эт четыре

вобщем видали....все решаемо

а вот если со статистикой все плохо, то очередь будет в DB01

А в индексе добавлено поле мандант ?

Тормозит то на селекте, так что саповские блокировки тут побоку

ааа точняк )

Спасибо всем за советы!

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

На прошлом проекте 70% проблем с системой администраторы решали перезагрузкой))

Сервер на Windows?

Когда вернётся, попробуйте избавиться от FOR ALL ENTRIES.
Эта фишка чисто SAP-овская, и пока дело дойдёт до СУБД, SAP-а тоже пытается оптимизировать запрос, и не всегда успешно.
Я однажды наблюдал, как один и тот же запрос с FOR ALL ENTRIES выполнялся за очень разное время, при этом видно было, что он разбивался то на кучу маленьких запросов, то на несколько больших. При этом нужно учитывать, что условия в этих кусочках перечисляются через OR, что в свою очередь плохо сказывается на оптимизации уже самой СУБД. Теперь в SAP-е начали объединять эти кусочные запросы через SQL UNION, но принципиально это ситуацию не меняет - FOR ALL ENTRIES по определению неоптимален, он годится только в крайнем случае. Если есть возможность, избавьтесь от него.
Во всяком случае таблицы EBAN и RESB прозрачные, ничто не мешает объединить их в JOIN или использовать подзапрос. И ему для выборки 3 тыс. записей по вашим условиям одной минуты будет очень много.

На уровне СУБД замечал ещё одну фишку, если есть очень похожие индексы, то оптимизатор может в какой-то момент начать выбирать неоптимальный. Иногда помогает сброс статистики, но гарантий от рецидивов это не даёт. Лучше разобраться где используется "плохой" индекс и либо удалить его, либо объединить со своим, возможно скорректировав и сами SELECT-ы.