Цитата:
Сообщение от
sukhanchik
Цитата:
Сообщение от gl00mie
В частности, замечено, что его оптимизатор, порой, как-то "своеобразно" подбирает "наиболее подходящий" индекс и строит совершенно дикие планы запроса - возможно, как раз из-за перекоса весов различных параметров, используемых им при оценке стоимости использования того или иного плана.
Ну тут могу сказать, что я наоборот, сталкивался с тем, что Oracle, в отличие от SQL Server чаще выберет FULL TABLE SCAN, нежели неоптимальный индекс. Хотя справедливости ради надо отметить, что порой он действительно "своеобразно" подбирает индекс и без Oracle DBA (или человека, исполняющего эту роль) будет тяжело обходиться.
Согласен и с тем и с другим, хотя в случае Аксапты с первым больше.
И это не только из-за
optimizer_index_cost_adj...
Насколько я понимаю, это всё из-за функциональных индексов, с которым оптимизатор (по крайне мере 9i) временами как-то с трудом справляется, даже при наличии самой полной статистики.
Я проводил небольшие "исследования", моделируя одинаковые по сути ситуации, но с участием либо FBI, либо и обычных индексов. В результате было очень заметно, что в случае обычных индексов оптимизатор выбирает отличные оптимальные планы, используя по максимуму всё, что нужно по смыслу. В случае же FBI результаты бывают просто непредсказуемые.
Навскидку помню следующие две проблемные ситуации, хотя их, конечно, больше:
(правда данные эффекты я наблюдал на оракле на Винде. есть шанс, что на каком-нить *nix-e он себя и лучше поведёт)
- Берётся абсолютно левый индекс, иногда даже в котором (кроме компании конечно) нет ни одного поля из запроса! И начинает по нему сканировать. Со всеми вытекающими по производительности. Приходится в таких ситуациях в Аксапте лечиться конкретным индекс-хинтом.
- В ситуации, когда имеем запрос типа
select a.. что-то ещё .... [not]exists join b ... join c.
Предполагаем, что
а соединено с
b, а
b c
с по селективных индексам, которые можно и нужно использовать.. С обычными индексами Оракл бы "пропихнул" нужное условие на таблицу "b" в джоин a+b+c и выполнил бы по индексам нестед лупами с минимальной стоимостью и, соответственно, мгновенной скоростью запроса. С FBI же такую красоту он сделать уже отказывается. Рассматривает джоин b+c как независимое представление, которое и "разрешает" отдельно, обычно hash-джоином, естественно включая фулл-скан на обе таблицы (b & c). Стоит ли говорить о том, как страдает скорость, когда вместо доступа к нескольким строчкам по индексу, оракл начинает сканировать 2 большие таблицы. Приходится либо переписывать запросы, если это возможно и допустимо, либо "забивать".