Как правильно установить параметр параметра optimizer index cost adj для Oracle. Как разработчик, я наблюдал огромное улучшение производительности при снижении этого параметра. Общие запросы сокращены с 2 секунд до 200 мс. В сети есть множество предупреждений о том, что снижение этого значения вызовет серьезные проблемы с базой данных, но подробностей о том, что может пойти не так, не приводится.
В настоящее время я вижу только положительные стороны, значительно улучшенную производительность приложений и никаких недостатков. Мне нужно лучше понять возможные негативные последствия настройки этих параметров.
Причина, по которой не рекомендуется изменять эти параметры, заключается в том, что они влияют на оптимизатор в масштабе всей базы данных, поэтому, когда вы меняете его для настройки конкретного запроса, это, вероятно, окажет некоторое влияние на многие другие запросы. Так что изменять его в производственной среде без тщательного тестирования всего приложения опасно.
Тем не мение:
Если вы хотите использовать как системную статистику, так и параметры оптимизатора, погуглите, об этом написал Джонатан Льюис (извините, сайт не позволяет мне размещать более одной ссылки)
Надеюсь, это поможет
Параметр не следует изменять в производственной среде. Основное использование - принудительное изменение плана просто для проверки производительности с различными планами выполнения. По сути, вы предлагаете оптимизатору использовать все индексы в вашей базе данных дешевле, чем другие пути доступа. И это может быть верно для некоторых sql и может быть ложным для других.
Если у вас есть хороший план производительности, вы должны понять, почему оптимизатор не использует его, и попытаться исправить (т.е. нет свежих / точных статистических данных -> собирать свежие, более точные статистические данные).
Надеюсь, это поможет, Стефано
Значения по умолчанию для этих двух параметров ужасны для систем OLTP, которые являются наиболее распространенным типом баз данных. Они приводят к более полному сканированию таблиц и ошибочным запросам. Обычно вы хотите установить эти параметры ДО выхода в эфир. Вы делаете это на этапе тестирования.
Если вы измените их после запуска, вы рискуете изменить другие запросы, которые были настроены на неверные настройки. Похоже, вы мало знаете о настройке базы данных, поскольку вместо планов запросов упоминаете время отклика. Эти параметры трогать не стоит.
Большинство администраторов баз данных не понимают разницы в концепциях исправления и дизайна. После того, как вы живете, вы исправляете, и именно тогда вам нужно быть осторожным, изменяя эти параметры. Прежде чем вы начнете жить, вы находитесь на стадии проектирования и разработки. Это когда вы настраиваете параметры вот так.
Кстати, хорошее место для начала с этих параметров (обратите внимание, ПРЕЖДЕ ЧЕМ ВЫ ПЕРЕЙДЕТЕ В PRODUCITON, И ТОЛЬКО ЕСЛИ ВЫ ЗНАЕТЕ, ЧТО ВЫ ДЕЛАЕТЕ!)
optimizer_index_cost_adj = 10 кэширование оптимизатора = 90
Это для OLTP. Для пакетной обработки параметры, с которых вы хотите начать, сильно отличаются. Я немного повозился с ними, но эти настройки дают мне наилучшие общие результаты в 99% случаев на OLTP. Однако я НЕ трогаю их после того, как мы перейдем в производство. Если они плохие, я оставляю их плохими и настраиваю запросы.