Всем доброго времени суток!



У нас сообщения используются не совсем по назначению, о причинах умолчу. К таблице QMEL существует стандартный индекс по полю qmtxt. В разработке все шло хорошо и выборка шла по индексу. Но когда перенесли в продуктив и объем данных увеличился, селект перестал его использовать. Как в наших разработках, так и в стандарте. Перепробовали все до чего дошли руки: искали ноты, обновляли статистику, переактивировали индексы. Ничего не помогло. Единственная закономерность, которую удалось выявить, что если выбирать чрез se16n и ставить количество выборки 500, то индекс используется, а если ставить 1 запись - то нет. Можно конечно использовать HINT, но хотелось бы без него.

Если у кого-нибудь есть идеи почему индекс перестал работать, буду очень признателен.

СУБД какая?
Посмотрите план разбора запроса
Создайте запрос с хинтом(ну хотя бы в ST04), посмотрите его план. Из оценочных попугаев плана может быть видно, почему оптимизатор считает, что не нужно использовать индекс

можно сравнить планы запросов se16n и программы

Oracle. Из плана ничего, не понятно. Когда использует индекс, Coast больше чем по full table. Скриншоты приложить не могу, система закрытая. Select в базу уходит ровно один и тот же за исключением количества возвращаемых записей, если сравнивать с se16n

обратитесь в СПОРТЛОТО

интересно, если на сурбд есть load balancing может ли разъехаться индекс

1) а в чем именно кост выше? в IO-cost или CPU-cost?
2) однако план можно и текстом кинуть

Может быть стоит попросить базис проверить индекс на уровне СУБД и при необходимости перестроить его

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


IO-cost

Базис тоже пытался разобраться, но пока также безрезультатно

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

Раз IO-cost, то или индекс уже плохой и его надо ребъюлдить, или расположен он на винте не удачно. Ну это первые предположения, которые приходят в голову.

МО ? делегируйте базису, ведь со стороны разработки всё в порядке.
вдруг кому-то не понравится - можно невыездным стать или срок за разглашение получить

Попробуйте обновить проблемный индекс (можно из ST05)

А запросы вручную (sqlplus) как отрабатывают по индексу? Думается мне что проблема на стороне БД.

Почему хотелось бы без него?
У нас после апгрейда БД с Oracle 9 на Oracle 11 появилась куча проблем, связанных с неверным построением плана запроса.
В некоторых случаях помогает как раз прямое указание индекса через HINT.
В некоторых - прямая подстановка значений параметров (&SUBSTITUTE VALUES&).
У SAP есть куча нот по производительности, в которых добавляются HINT`ы. И никого это не смущает.
Вот прямой вызов нативного SQL как правило недопустим.
А хинты... Почему нет?

SE11, Утилиты БД, Индексы, Удалить индекс БД, Создать индекс БД.

После этого желательно обновить статистику. Причем мне услуги базиса не помогали, а вот так на ура для оракла:

Для какой версии?

Это же отчет RSANAORA