Использование подсказки Oracle FIRST_ROWS для повышения производительности базы данных Oracle

У меня есть оператор, который работает на сервере базы данных Oracle. Оператор имеет около 5 объединений, и в этом нет ничего необычного. Это выглядит примерно так, как показано ниже:

SELECT field1, field2, field3, ...  
FROM table1, table2, table3, table4, table5  
WHERE table1.id = table2.id AND table2.id = table3.id AND ...  
      table5.userid = 1

Проблема (и что интересно) заключается в том, что оператору userid = 1 требуется 1 секунда, чтобы вернуть 590 записей. Оператор для userid = 2 занимает около 30 секунд, чтобы вернуть 70 записей.

Я не понимаю, почему такая большая разница.

Похоже, что для инструкции с userid = 1 выбран другой план выполнения, а для userid = 2 — другой.

После того, как я реализовал Oracle Hint FIRST_ROW, производительность значительно улучшилась. Оба утверждения (для обоих идентификаторов 1 и 2) возвращают результат менее чем за 1 секунду.

SELECT /*+ FIRST_ROWS */
       field1, field2, field3, ...  
FROM table1, table2, table3, table4, table5  
WHERE table1.id = table2.id AND table2.id = table3.id AND ...  
      table5.userid = 1

Вопросы:
1) Каковы возможные причины плохой производительности, когда userid = 2 (когда подсказка не используется)?
2) Почему план выполнения может отличаться для одного и другого оператора ( когда подсказка не используется)?
3) Есть ли что-то, с чем мне следует быть осторожным, решая добавить эту подсказку к моим запросам?

Спасибо


person bobetko    schedule 11.06.2012    source источник
comment
Актуальна ли и точна ли статистика вашей таблицы?   -  person Tebbe    schedule 11.06.2012
comment
будьте осторожны с кэшированием при сравнении производительности.   -  person tbone    schedule 11.06.2012
comment
Теббе - Статистика актуальна. Являются ли они точными, я не знаю.   -  person bobetko    schedule 11.06.2012


Ответы (1)


1) Каковы возможные причины плохой работы при userid = 2 (когда не используется подсказка)?

Потому что Oracle считает, что один из промежуточных наборов результатов, использующих план from (userid=1), будет очень большим — возможно, это неправильно.

2) Почему план выполнения будет отличаться для одного оператора от другого (когда подсказка не используется)?

Индексы на основе гистограмм

3) Есть ли что-то, с чем мне следует быть осторожным, когда я решаю добавить эту подсказку к своим запросам?

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

person symcbean    schedule 11.06.2012
comment
Спасибо за ваш быстрый ответ. Самое удивительное, что у нас не было этой проблемы 6 лет до 1 месяца назад (когда мы обновились до новой версии Oracle). С тех пор производительность становилась все хуже и хуже (для некоторых пользователей). Существуют ли какие-либо действия, которые можно выполнить на сервере Oracle для оптимизации производительности? Спасибо. - person bobetko; 11.06.2012
comment
Следите ли вы за своей статистикой? Было бы неплохо действительно проанализировать, нужны ли вам гистограммы или нет - person Sebas; 11.06.2012
comment
Вы используете связанные переменные и перешли на СУБД с включенным просмотром привязки? - person symcbean; 11.06.2012
comment
Это может быть связано с тем, что METHOD_OPT изменил поведение по умолчанию: richardfoote.wordpress.com/2008/01/04/ - person Jon Heller; 11.06.2012
comment
Ну, я не dba - он сказал, что статистика в порядке. Спасибо, джонирлз. Может быть... посмотрю на это - person bobetko; 12.06.2012