Oracle - снова индексы

[Bars]

Заметил странную особенность...

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

Выполняю запрос в 3-х уровневой конфигурации - индексы не подхавтываются..
Выполняю в 2-х уровневой, индекс подхватывается и запрос выполняется быстро..

index hint в конфигурационной утилите равно 0.

С чем это может быть связано?

[Recoilme]

Может это?
Управление опциями SQL запроса

[db]

может следующие проверки и удары в бубен помогут

1. в конфиге самого аоса, который доступен через панель управления хинты то же выключены?
2. Галочки "force literals in..." в двухровневой и в конфиге аоса одинаковые?
3. закешировался плохой план запроса. например статистики не было, запрос выполнили, потом собрали статистику, но план все равно останется старый. хотя кеш планов живет в SGA и плохо должно быть по любому. попробуйте alter sytem flush shared pool
4. ну и на всяк случай - пересоберите статистику по всем индексам своей таблицы.

[db]

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

[Bars]

Цитата:

Сообщение от db

еще глупый вопрос, но лучше все таки спрошу - планы запросов действительно разные?

да смотрел план запроса... в одном случае цепляет индекс, во втором плане - обращается напрямую к таблице и пишет .. TABLE ACCES (FULL)

[Recoilme]

Цитата:

Сообщение от Bars

да смотрел план запроса... в одном случае цепляет индекс, во втором плане - обращается напрямую к таблице и пишет .. TABLE ACCES (FULL)

Слей сюда запросы то... Интересно всё ж таки с академической точки зрения
Ась?

[belugin]

А сами данные в критериях одинаковые?

[Bars]

Цитата:

Сообщение от belugin

А сами данные в критериях одинаковые?

абсолютно идентичный запрос..

[Recoilme]

Абсолютно идентичный запрос в аксапте или в профайлере?? Если в профайлере - может наполнение таблиц данными меняется?

[Bars]

Цитата:

Сообщение от Recoilme

Абсолютно идентичный запрос в аксапте или в профайлере?? Если в профайлере - может наполнение таблиц данными меняется?

в Аксапте ..

текст запроса примерно следующий...

select count(RecId) from
myTable
where myTable.PeriodStart >= 13\03\2006
&& myTable.PeriodEnd <= 20\03\2006
&& myTable.InventDimId == 'АН0000031'
&& myTable.ItemId == '0140101020'
&& myTable.AverageSale > 0;

[db]

Цитата:

Сообщение от Bars

в Аксапте ..

текст запроса примерно следующий...

select count(RecId) from
myTable
where myTable.PeriodStart >= 13\03\2006
&& myTable.PeriodEnd <= 20\03\2006
&& myTable.InventDimId == 'АН0000031'
&& myTable.ItemId == '0140101020'
&& myTable.AverageSale > 0;

Уже интереснее ...
А поля в индексе в каком порядке идут? Если в том-же, в котором критерии указаны в запросе, то оптимизатор скорее всего предпочтет сканирование. Все поля, по которым идет выборка не по == надо сдвигать в хвост индекса

[savel]

Цитата:

Сообщение от db

...оптимизатор скорее всего предпочтет сканирование

тогда почему в 2х уровневой у человека сканирование не происходит?

[db]

Цитата:

Сообщение от savel

тогда почему в 2х уровневой у человека сканирование не происходит?

человек до сих пор так и не рассказал что там у него происходит ни про данные, ни про настройки, ни про конфиг, ни про версии аксапты, ни про версии оракла.

инфу в студию. а то еще окажется в итоге, что базы разные - одна на ноуте, вторая на серваке (шутка)

[Recoilme]

в профайлере запросы возможно разные

[belugin]

Есть "правило 5%" по которому используется Full Table Scan если селективность индекса по данному значению больше 5%.

Может быть данные в запросе разные?

[Bars]

Цитата:

Сообщение от belugin

Есть "правило 5%" по которому используется Full Table Scan если селективность индекса по данному значению больше 5%.

Может быть данные в запросе разные?

данные... нет, одни и те же выбираются...

Про селективность, что вы имеете ввиду?

[Recoilme]

Селективность = 1/(Keys - TotalDup), где
Keys: Число ключей в индексе. Обычно равно Records в таблице
TotalDup: Всего повторений ключей. Чем ближе это число к Keys, тем менее эффективен данный индекс при поиске, особенно когда оптимизатор использует несколько индексов.

[Bars]

Цитата:

Сообщение от Recoilme

Селективность = 1/(Keys - TotalDup), где
Keys: Число ключей в индексе. Обычно равно Records в таблице
TotalDup: Всего повторений ключей. Чем ближе это число к Keys, тем менее эффективен данный индекс при поиске, особенно когда оптимизатор использует несколько индексов.

спасибо за объяснение

[Recoilme]

Цитата:

Сообщение от Bars

спасибо за объяснение

Попробуя сформулировать своими словами:
есть таблица 1
есть поле1, число, все значения в поле =1 - такой индекс будет бесполезен вообще
есть поле2, логика, тут индекс тоже будет бесполезен, т.к. обладает низкой слективностью, он делит таблицу примерно на 2 части, мало "селективит" и оптимизатор его проигнорирует
есть поле3, например дата - если большинство дат в таблице разные - индекс будет хорошим, потому что из миллиона записей он позволит отобрать 100 при условии по определенной дате

С составными индексами - сложнее - там сам плохо понимаю

Примерно так. СУБД считает селективность, примерно по той формуле что я привел, как точно считает оракл надо глядеть в доках. Там может быть ещё ряд условий, например макс кол дубликатов в индексе и т.п. На основании селективности оптимизатор решает свалиться в скан или юзать индекс. Процесс рассчета селективности называется сбор статистики, собрать её db ещё давно советовал.

Бывают ещё всякие причины не юзанья индекса. Например в версионных базах данных КАУНТ не использует индекс постольку-поскольку там идеология другая. Считаются "живые" версии записей, о кот. нет инфы в индексе, поэтому там фуллскан всегда и каунт тормозней чем в блокировочниках. Но т.к. оракл наполовину блокировочник, наполовину версионник как там работает каунт - сложно сказать. Есть ещё всякие фьючерс чтоб обмануть оптимизатор и заставить его НЕ пользовать индекс, например where a = b, заменяют на a+0=b

Бывает наоборот когда приложение посылает оптимизатору хинты заставляющие его использовать индекс даже если он неоптимален. Об этом я писал тут вначале.

Уфф устал. Вобщем гораздо толковей и лучше всё это написано тут: www.sql.ru, www.ibase.ru

[Recoilme]

Ага, мне тоже надоело. Другой бы уже давно вывалил и скрипт таблицы и запросы из профайлера. Такое ощущение что это "развод на поболтать"