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