21.03.2006, 14:27 | #1 |
Участник
|
Oracle - снова индексы
Заметил странную особенность...
Выполняю запрос на собственной таблице, по ней построен индекс по нескольким полям, в запросе как раз эти поля и используются в качестве критериев отбора... Выполняю запрос в 3-х уровневой конфигурации - индексы не подхавтываются.. Выполняю в 2-х уровневой, индекс подхватывается и запрос выполняется быстро.. index hint в конфигурационной утилите равно 0. С чем это может быть связано? |
|
21.03.2006, 15:34 | #2 |
злыдень
|
Может это?
Управление опциями SQL запроса
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
21.03.2006, 16:04 | #3 |
Роман Долгополов (RDOL)
|
может следующие проверки и удары в бубен помогут
1. в конфиге самого аоса, который доступен через панель управления хинты то же выключены? 2. Галочки "force literals in..." в двухровневой и в конфиге аоса одинаковые? 3. закешировался плохой план запроса. например статистики не было, запрос выполнили, потом собрали статистику, но план все равно останется старый. хотя кеш планов живет в SGA и плохо должно быть по любому. попробуйте alter sytem flush shared pool 4. ну и на всяк случай - пересоберите статистику по всем индексам своей таблицы. |
|
21.03.2006, 16:17 | #4 |
Роман Долгополов (RDOL)
|
еще глупый вопрос, но лучше все таки спрошу - планы запросов действительно разные?
т.е вы реально видели планы запросов, а не просто тут быстро, а тут медленно, потому что наверное индекс не используется. если запрос выполнять несколько раз с одними и теми же параметрами и с размером кеша у оракла все в порядке, то данные запросто могут выгребаться из кеша, без обращения к дискам - разница по скорости несколько порядков |
|
21.03.2006, 16:26 | #5 |
Участник
|
Цитата:
Сообщение от db
еще глупый вопрос, но лучше все таки спрошу - планы запросов действительно разные?
|
|
21.03.2006, 18:10 | #6 |
Участник
|
А сами данные в критериях одинаковые?
|
|
21.03.2006, 19:47 | #7 |
злыдень
|
Цитата:
Сообщение от Bars
да смотрел план запроса... в одном случае цепляет индекс, во втором плане - обращается напрямую к таблице и пишет .. TABLE ACCES (FULL)
Ась?
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
21.03.2006, 22:12 | #8 |
Участник
|
Цитата:
Сообщение от belugin
А сами данные в критериях одинаковые?
|
|
22.03.2006, 09:48 | #9 |
злыдень
|
Абсолютно идентичный запрос в аксапте или в профайлере?? Если в профайлере - может наполнение таблиц данными меняется?
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
22.03.2006, 11:50 | #10 |
Участник
|
Цитата:
Сообщение от 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; |
|
22.03.2006, 13:33 | #11 |
злыдень
|
в профайлере запросы возможно разные
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
22.03.2006, 13:42 | #12 |
Участник
|
Есть "правило 5%" по которому используется Full Table Scan если селективность индекса по данному значению больше 5%.
Может быть данные в запросе разные? |
|
22.03.2006, 14:35 | #13 |
Участник
|
Цитата:
Сообщение от belugin
Есть "правило 5%" по которому используется Full Table Scan если селективность индекса по данному значению больше 5%.
Может быть данные в запросе разные? Про селективность, что вы имеете ввиду? |
|
22.03.2006, 15:13 | #14 |
злыдень
|
Селективность = 1/(Keys - TotalDup), где
Keys: Число ключей в индексе. Обычно равно Records в таблице TotalDup: Всего повторений ключей. Чем ближе это число к Keys, тем менее эффективен данный индекс при поиске, особенно когда оптимизатор использует несколько индексов.
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
23.03.2006, 11:11 | #15 |
Участник
|
Цитата:
Сообщение от Recoilme
Селективность = 1/(Keys - TotalDup), где
Keys: Число ключей в индексе. Обычно равно Records в таблице TotalDup: Всего повторений ключей. Чем ближе это число к Keys, тем менее эффективен данный индекс при поиске, особенно когда оптимизатор использует несколько индексов. |
|
23.03.2006, 14:41 | #16 |
Роман Долгополов (RDOL)
|
Цитата:
Сообщение от 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; А поля в индексе в каком порядке идут? Если в том-же, в котором критерии указаны в запросе, то оптимизатор скорее всего предпочтет сканирование. Все поля, по которым идет выборка не по == надо сдвигать в хвост индекса |
|
23.03.2006, 14:57 | #17 |
Участник
|
Цитата:
Сообщение от db
...оптимизатор скорее всего предпочтет сканирование
|
|
23.03.2006, 15:13 | #18 |
злыдень
|
Цитата:
Сообщение от Bars
спасибо за объяснение
Попробуя сформулировать своими словами: есть таблица 1 есть поле1, число, все значения в поле =1 - такой индекс будет бесполезен вообще есть поле2, логика, тут индекс тоже будет бесполезен, т.к. обладает низкой слективностью, он делит таблицу примерно на 2 части, мало "селективит" и оптимизатор его проигнорирует есть поле3, например дата - если большинство дат в таблице разные - индекс будет хорошим, потому что из миллиона записей он позволит отобрать 100 при условии по определенной дате С составными индексами - сложнее - там сам плохо понимаю Примерно так. СУБД считает селективность, примерно по той формуле что я привел, как точно считает оракл надо глядеть в доках. Там может быть ещё ряд условий, например макс кол дубликатов в индексе и т.п. На основании селективности оптимизатор решает свалиться в скан или юзать индекс. Процесс рассчета селективности называется сбор статистики, собрать её db ещё давно советовал. Бывают ещё всякие причины не юзанья индекса. Например в версионных базах данных КАУНТ не использует индекс постольку-поскольку там идеология другая. Считаются "живые" версии записей, о кот. нет инфы в индексе, поэтому там фуллскан всегда и каунт тормозней чем в блокировочниках. Но т.к. оракл наполовину блокировочник, наполовину версионник как там работает каунт - сложно сказать. Есть ещё всякие фьючерс чтоб обмануть оптимизатор и заставить его НЕ пользовать индекс, например where a = b, заменяют на a+0=b Бывает наоборот когда приложение посылает оптимизатору хинты заставляющие его использовать индекс даже если он неоптимален. Об этом я писал тут вначале. Уфф устал. Вобщем гораздо толковей и лучше всё это написано тут: www.sql.ru, www.ibase.ru
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|
23.03.2006, 15:15 | #19 |
Роман Долгополов (RDOL)
|
Цитата:
Сообщение от savel
тогда почему в 2х уровневой у человека сканирование не происходит?
инфу в студию. а то еще окажется в итоге, что базы разные - одна на ноуте, вторая на серваке (шутка) |
|
23.03.2006, 15:31 | #20 |
злыдень
|
Ага, мне тоже надоело. Другой бы уже давно вывалил и скрипт таблицы и запросы из профайлера. Такое ощущение что это "развод на поболтать"
__________________
Ибо зло есть лучшая сила человека. "Человек должен становиться все лучше и злее" -- так учу я. /Ф. Ницше/ |
|