Немного о ремонте запросов

По мотивам статьи Troubleshooting Bad Execution Plans

Плохой запрос -- плохой (неправильный с нашей точки зрения) план. Причины плохого плана:

1. Неправильная статистика
2. Переустановленные параметры оптимизатора (optimizer_index_..., db_file_multiblock_read_count)

Как же его отремонтировать? Очень понравилось, почему не стоит ремонтировать запросы через глобальные параметры:

1. This is a global change to a local problem
2. Although it appears to solve one problem, it is unknown how many bad execution plans resulted from this change
3. The root cause of why the index plan was not chosen is unknown, just that tweaking parameters gave the desired result
4. Using non-default parameters makes it almost impossible to correctly and effectively troubleshoot the root cause

Что же делать? Ответ традиционен -- корректировать статистику. Причины, по которой статистика может быть неадекватной (кроме очевидной, что ее собирают неправильно или совсем не собирают):

1. Data skew: Is the NDV inaccurate due to data skew and a poor dbms_stats sample?
2. Data correlation: Are two or more predicates related to each other?
3. Out-of-range values: Is the predicate within the range of known values?
4. Use of functions in predicates: Is the 5% cardinality guess for functions accurate?
5. Stats gathering strategies: Is your stats gathering strategy yielding representative stats?

Советы по исправлению ошибок можно прочитать в самой статье.

PS: если нужно поставить параметр для отдельно взятого запроса, можно использовать хинт /*+ opt_param('optimizer_index_cost_adj', 100) */