Есть ключ к таблице на уровне словаря. Есть соответствующий ему индекс в Oracle. При обращении к таблице идет последовательное считывание и очень долго, т.е. скорее всего выборка идет не по индексу. Похоже что нет связи индекса R/3 и индекса Oracle (были сбои в системе). Как узнать наличие этой связи и что можно сделать вообще?

нет такого понятия индекс R/3 - и тем более связей. Оптимизатор Оракла выбирает по неким правилам - по какой схеме работать - использовать или не использовать тот или иной индекс. - Смотрите план выполнения. Смотрите правила оптимизатора. Смотрите сам запрос и стоимостную оценку индекса:) Много условий.

Неправильно выразился "индекс R/3",
Уже другой вопрос: есть такой случай (по вторичному индексу уже), что в словаре видим индекс а соответствующего ему в Oracle нет, опять таки после сбоя.

Возможно он никогда и не создавался? По крайней мере мне ОЧЕНЬ сложно представить такой сбой Оракла при котором терялись индексы физически.

Создайте индекс - если честно я не очень понимаю - в чем проблема? Что план выполнения, выбранный Ораклом не соответствует ожидаемому Вами? Тогда анализируйте запрос прежде всего.

Создать через se14

И, конечно, не стоит забывать регулярно запускать проверку статистики.

А почему Вы дали такой диагноз? Посмотрите какой выполняется SELECT в транзакции ST04 - вполне возможно что в программе запускается выборка, не попадающая в существующие индексы.

Тут можно посоветовать следующее:
1. проверьте программу, которая вполняет SELECT, если это самопис - тогда или переписывать программу, или создавать индекс под нее и т.д.
2. если стандартная программа, тогда делать анализ настроек, приведших к такой выборке и как вариант - или править настройки, или создавать новый индекс, попадающий под условия выборки и т.д.

Лирическое замечание ...
Я встречал массу перлов ABAP-еров и консультантов, которые могут катострофически снизить производительность работы диалога, отчета, программы обновления и вообще всего-чего-только-можно:
1. однажды ABAP-ер создал "шедевр" такого вида:

Это при том что в каждой из таблиц (TABLE1 и TABLE2) было по 5 млн записей.
Отчет с такой конструкцией работал 24 часа. Пока не вырвали руки абаперу и не переписали кусок. После правки на форму SELECT ... WHERE отчет стал работать 20 мин. А после переделки на форму SELECT ... FROM VIEW_TAB1_TAB2 стал работать 5 мин.

2. Однажды ОЧЕНЬ умный консультант по логистике при обновлении заказа на материал в программу обновления заказов вставил свой модуль с конструкцией типа:

При том что в системе работало с MM порядка 200 пользователей - они просто вешались при создании заказа. Работала система со всеми тюнингами 1 заказ в 30 мин ... Потом мы полезли по системе... Руки оторвали консультанту.

User-Exit сущее зло

По поводу лирических замечаниий N2:
К сожалению зачастую умение быстро писать программы ценится больше чем умение писать быстроработающие программы.
Если я не прав скажите как часто вам приходилось видеть просьбы поделиться курсом BC490?

Вы к сожалению правы.