есть запрос к vbak, который дольше всего выполняется в задаче.



в часто встречаемых выборках все поля заполнены.

создан индекс:
VKORG Сбытовая организация
VTWEG Канал сбыта
VKBUR Отдел сбыта
SPART Сектор
VKGRP Группа сбыта
VBTYP Тип ДокумСбыта
GUEBG ДатаВступлСилу (ДолгосрочнДоговор/ассортимент)
VDATU Требуемая дата поставки

который, судя по плану запроса используется.
как еще его можно оптимизировать эту выборку?

Пономарев Артем: пользуйтесь тегами для оформления кода, пожалуйста

Должно работать достаточно быстро.
Я бы выкинул из индекса VDATU и GUEBG.

План запроса можете кинуть и кол-во записей в vbak?

SELECT
"VBELN" , "VBTYP" , "VKORG" , "VTWEG" , "VKBUR" , "VKGRP" , "GUEBG" , "ZZTEXT_KORKI" ,
"VBELN_GRP" , "BSTNK" , "KTEXT" , "ERNAM" , "ERDAT" , "ERZET" , "AUART" , "VDATU" , "GUEEN" ,
"ZZDATA_OPL" , "ZZREGIO" , "ZZLAND1" , "WAERK"
FROM
"VBAK"
WHERE
"MANDT" = :A0 AND "VKORG" = :A1 AND "VTWEG" = :A2 AND "VKBUR" = :A3 AND "SPART" = :A4 AND "VKGRP"
BETWEEN :A5 AND :A6 AND "VBTYP" = :A7 AND "GUEBG" BETWEEN :A8 AND :A9


Execution Plan

MANDT добавьте в индекс.

По таймингам вроде вполне удобоваримо.

он там есть, разумеется

Я думаю, что вопрос в количестве записей, возвращаемых данным запросом.
В индекс включены абсолютно все поля из запроса, так что тормозить может только сама выборка из индекса.
Если запрос возвращает большое количество записей, то и работать он может достаточно долго.
Еще всегда смущают конструкции IN, так как RANGE может быть пуст и выборка по индексу может получиться "дырявой". Да и план запроса может меняться для разных типов RANGE, что при большом количестве может снижать производительность.
В приведенном примере 1-й RANGE типа BT (тоже не самый быстрый вариант), а второй просто EQ.

Еще пришло в голову:
Может быть в таблице vbak 90% записей с одними и теми же значениями VKORG, VTWEG, VKBUR, SPART, VKGRP, VBTYP (или несколько первых из этих полей), тогда может и не стоит добавлять эти поля в индекс.

Еще можно эту статейку почитать, некоторые основные принципы при построении индексов:
http://www.intuit.ru/department/database/rdbdev/11/3.html

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

1. Cколько уникальных значений получится, если выполнить запрос SELECT COUNT( DISTINCT <все поля индекса> )
2. Общее количество записей в vbak
3. Код программы
4. Какие бывают RANGES zvkbur и zvkgrp
5. Сколько данных в среднем возвращает такой запрос. Если миллион записей, а в таблице сотни миллионов, то быстро вряд ли получится.

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

Посмотрите еще в сторону таблицы VAKGU. Может случиться, что она у вас заполняется.

она как-то заполнена, а чем она может помочь, я не совсем понимаю.

У нее primary key уж очень похож на ваш запрос. Если речь идет о контрактах, то TRVOG = 4, а DATAB и DATBI скорее всего соответствуют с VBAK-GUEBG/GUEEN. Уже по этим полям вы сразу радикально уменьшите количество выбираемых записей. Проанализируйте свои данные.