Уменьшить CPU cost

Здравствуйте, у меня такая проблемка.
Имеется таблица g - 1909 строк.
По всей схеме и соответственно по этой таблице и её индексам собрана статистика.
Имеется индекс по полю ID_S.

Делаю запрос:
select t.id_tr from g t
where t.ID_S=1
План:
SELECT STATEMENT, Cost=110 Bytes=15272 CPU cost=5784854 IO cost=110
TABLE ACCESS FULL Object owner=T_T Object name=G Cost=110 Bytes=15272 CPUcost=5784854 IO cost=110

Т.е. индекс "не берет".

Заставляю "взять индекс":
select /*+ INDEX (t I_G_ID_S)*/ t.id_tr from g t
where t.ID_S=1

План:
SELECT STATEMENT Cost=223 Bytes=15272 CPU cost=4127901 IO cost=223
TABLE ACCESS BY INDEX ROWID Object owner=T_T Object name=G Cost=223 Bytes=15272 CPU cost=4127901
INDEX RANGE SCAN Object owner=T_T Object name=I_G_ID_S Cost=6 CPUcost=425379 IO cost=6

Проблема в том, что CPU cost очень большое 5784854 / 4127901 и когда программой начинает пользоваться N-е количество пользователей, то сервер просто ложиться :(.
Поскажите что мне делать? В каком направлении копать?

так у тебя табличка 15кбайт ?

нахрена здесь индекс?

Вопрошатель

так у тебя табличка 15кбайт ? нахрена здесь индекс?

Ну хорошо. уберу индекс, а ТОЛКУ!

а в чем проблема? запрос долго работает?

вы кусок из трассы дайте где parse, exec,fetch (табличка) и ожидания какие ниже?

открой для себя тег src

Вопрошатель

а в чем проблема? запрос долго работает? вы кусок из трассы дайте где parse, exec,fetch (табличка) и ожидания какие ниже? открой для себя тег src

Проблема в том, что когда много людей выполняют это запрос, то "сжирается" все CPU сервака и он ложиться!

Да и индекс, похоже, неподходящий для этого запроса...

Очень интерестный вопрос. у тебя кост спу 4 127 901 операций. можешь посмотреть какая у тебя скорость ЦПУ ( в операциях в секунду) SELECT *
FROM sys.AUX_STATS$. возможно будет что-то типа. 500 000 000 000 . Сколько у тебя таких запросов в секунду?

может у тебя там динамический sql используеться?

miksoft

Да и индекс, похоже, неподходящий для этого запроса...

А какой будет подходящий?

Barabulka

miksoft Да и индекс, похоже, неподходящий для этого запроса... А какой будет подходящий?

у тебя оптимизатор решил, что ему дешевле просканировать всю таблицу ( кост = 110). чем идти по индексу ( кост = 223).

почему ты думаешь, что проблемы именно из-за этого запроса. и каково все-же это число N, о котором ты говоришь