имею запрос

Выполняется примерно минуту. Добавляю и активирую индекс для поля KONNR в таблицу ekpo

вверху есть сообщение что Индекс не существует в системе БД ORACLE, используется СУБД ORACLE 9.2.0.7.0
Как же создавать индексы? Насколько примерно быстрее будет выполняться запрос если будет соответствующий индекс в ekpo?

Нужно активировать индекс (судя по картинке, Ваш не аткивирован - статус "Новое").

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

а вообще рекомендую все таки по анализу производительности запроса посмотреть trace ST05, там все понятно что куда тратиться.

по данному селекту.
я бы все такие OUTER JOIN вынес в отдельный запрос, хотя это конечно не принципиально и спорно.
и в ключах по JOIN T023T поменять очередность ключей SPRAS, MATKL как они в есть таблице.

Ну порядок-то не важен. Интерпретатор весьма успешно разбирается обычно.

Это стандартная логистическая цепочка: контракт -> заказ на поставку. И тем не менее в EKKO нет индекса по KONNR. Почему? Посмотрите таблицу EKAB, там как раз к контрактам все созданные заказы.

вот тут я поспорю проверено на практие
в некоторые много JOIN ых запросах, если в некоторых таблицах указать не верный порядок ключей то может случиться full scan.

еще раз повотрю проверено на практике, понимаю что в теории все должно быть краисиво., тем более если без JOIN ов

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

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

Спасибо за EKAB выборка стала быстрее.
Просто забыл что после создания индекса надо таблицу переактивировать.

Поддерживаю. У нас, например, в таблице T163Y для языка EN всего десяток записей. Возможно будет гораздо эффективнее выбрать их все и потом добавить в LOOP? Кроме того, посмотрите, действительно ли нужен LEFT JOIN. Это же вроде таблица конфигурации, неужели там какие-то записи отсутствуют?

утилита базы данных -> создать индекс
вернуться в индекс -> активировать

Из своего опыта могу сказать - это сильно зависит от конкретной СУБД. В свое время, например, оптимизатор SYBASE сильно зависел от порядка условий в WHERE. А насколько я помню, MS SQL как раз и сделан на базе SYBASE. А посему то, что верно для Oracle может оказаться неверным для MS SQL.

В Oracle недостаточно активировать индекс. Надо по нему еще и статистику собрать. Причем делать это надо регулярно, иначе Oracle перестанет использовать такой индекс.

по моему от Sybase в MS SQL давно уже ничего не осталось

ладно бы просто перестал использовать, а то иногда башню сворачивает настолько, что запрос выдает данные, абсолютно несоответствующие условию WHERE

Был на нефтянном проекте в продуктиве такой случай с таблицей BSIS . Потребовалось переиндексировать таблицу. Только дело было не в сборе статистики, у нас полетел индекс. За Oracle тоже следить надо