Как увеличить оценку стоимости CBO для Oracle для хеш-соединений, по группам и по заказам без подсказок

Question

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

Некоторые дополнительные примечания:

1. Я уже установлен optimizer_index_cost_adj до 20 и это все еще не достаточно хорошо. Я НЕ хочу увеличивать стоимость чистых полных сканирований таблицы, на самом деле я бы не прочь оптимизатор, уменьшающий стоимость.
2. Я заметил, что pga_aggregate_target оказывает влияние на оценки стоимости CBO, но я определенно НЕ хочу понижать этот параметр, так как у нас много ОЗУ.
3. В отличие от использования подсказок оптимизатора в отдельных запросах, я хочу, чтобы настройки были глобальными.

---

Edit 1: Я думаю о экспериментировать с динамической выборкой, но не имеет достаточно глубоких знаний, чтобы предсказать, как это может повлиять на общую производительность, то есть, как часто планы выполнения могут измениться. Я определенно предпочел бы что-то, что очень стабильно, ведь для некоторых наших крупнейших клиентов у нас есть политика блокировки всех статистических данных (что изменится с помощью Oracle 11g SQL Plan Management).

Answer 1

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

Другими словами, если оптимизатор считает, что он будет получать 1M строк из таблицы A и 1000 строк из таблицы B, он вполне может выбрать полное сканирование + сортировать объединение или хеш-соединение; если, однако, когда он действительно запускает запрос, он получает только 1 строку из таблицы A, сканирование диапазона индекса может быть лучше.

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

EDIT: Вы упомянули, что оценки мощности неверны. Это основная причина ваших проблем; калькуляция хеш-соединений и сорта, вероятно, вполне нормально. В некоторых случаях оптимизатор может использовать неправильные оценки, потому что он не знает, сколько данных коррелировано. Гистограммы в некоторых столбцах могут помочь (если вы еще не получили их), и в некоторых случаях вы можете создавать индексы на основе функций и собирать статистику по скрытым столбцам для предоставления еще более качественных данных оптимизатору.

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