Chumakov_JA,

Вопрос - нужно ли что-то делать.
Table scan может быть не такой уж плохой операцией и может быть _значительно_ эффективней доступа по индексу.

Например, согласно собранной статистике запрос выбирает (или "может выбирать", тут может играть роль, как условие обозначено в предикате) 30%, ну пусть даже 10% всех записей по таблице.
Допустим, в среднем на странице располагается 50 записей, т.е. каждая страница с большой степенью вероятности содержит искомые записи, т.е. всё равно придётся прочитать всю/практически всю таблицу с диска.
В этом случае значительно эффективней читать экстентами (а скорее всего параллельно несолько экстентов), чем идти по индексу и выдирать по одной странице с разных мест "диска".

Приведите запрос целиком и расскажите, какой план Вы ожидали бы увидеть.


BTW 162 "попугая" - это "ни о чём". Вопрос - во что они выливаются далее.

knudsen,

Вот хиханьки да хаханьки, но кикие бы timeron'ы ни были отвлечённые, а на практике 150 - сродни потоковому чтению порядка сотни страниц (несколько экстентов) или 5 - 10 выдёргиваниям записи по индексу. Т.е. само по себе - "ни о чём".

Вопрос - во что это выливается далее.
Если там NLJOIN (что скорее всего, иначе бы и вопросов не возникло) с таблицей с хорошей мощностью, то эти timeron'ы уже умножаются.
На самом деле не совсем умножаются, т.к. видно, что сканируемая таблица хоть и не вырождена, но невелика. Т.е. с первого захода подчитается в пул и дальше будет сканироваться там, заметно, но не фатально поглощая лишь CPU Time.
Выделяться такой запрос безумным количеством rows read с не настолько же ужасным общим временем выполнения.

Хороший индекс по такой таблице сделает ситуацию лучше и сведёт CPU time к незначительным величинам.

Я бы поставил 9 к 1, что ситуация именно такова, но чего гадать на кофейной гуще, проще спросить, что там на самом деле.


Скорее всего или селективность у индексов не очень хорошая, или в предикате есть преобразование индексируемой колонки. Второе вероятней - индексы есть и даже "перестраивались" (статистику, кстати, стоило собирать после перестройки индексов). Даже кастинг типов рушит возможность использования индекса.

Т.е. если есть таблица T1 с колонкой COL1, по которой построен индекс, то предикат "WHERE F1(COL1) = <somefing>" использовать этот индекс не будет, что логично.
Нужно:
а) или "WHERE F1(COL1) = <somefing>" преобразовать в "WHERE COL1 = F2(<somefing>)", где F2(...) - ф-я, обратная к F1(...) (если такая вообще существует).
б) или строить индекс по выражению (до 10-ки материлизуя выражение в отдельной вычислимой колонке, с 10.1 или 10.5, строя индекс просто по выражению).


В любом случае танцевать надо от самого запроса и ожиданий автора топика (что в какой-то мере может охарактеризовать имеющиеся данные - ведь ожидания на чём-то основываются).