Понимание результатов плана выполнения в Oracle SQL Developer

CBO строит дерево решений, оценивая затраты на каждый возможный путь выполнения, доступный для каждого запроса. Затраты устанавливаются параметром CPU_cost или I/O_cost, установленным в экземпляре. И CBO оценивает затраты, насколько это возможно, с существующей статистикой таблиц и индексов, которые будут использоваться в запросе. Вы не должны настраивать свой запрос, основываясь только на стоимости. Стоимость позволяет понять, ПОЧЕМУ оптимизатор делает то, что он делает. Без затрат вы могли бы понять, почему оптимизатор выбрал план, который он сделал. Более низкая стоимость не означает более быстрый запрос. Есть случаи, когда это верно, и будут случаи, когда это неправильно. Стоимость основана на вашей таблице статистики, и если они ошибаются, стоимость будет неправильной.

При настройке запроса вы должны взглянуть на мощность и количество строк каждого шага. Имеют ли они смысл? Оптимизатор считается корректным? Правильно ли возвращаются строки. Если информация присутствует неправильно, то, скорее всего, оптимизатор не имеет надлежащей информации, необходимой для принятия правильного решения. Это может быть связано с устаревшими или отсутствующими статистическими данными в таблице и индексе, а также cpu-stats. Лучше всего обновлять статистику при настройке запроса, чтобы максимально использовать возможности оптимизатора. Знание вашей схемы также очень помогает при настройке. Зная, когда оптимизатор выбрал действительно плохое решение и указал его на правильный путь с помощью небольшого подсказки, можно сэкономить время.

Вот ссылка на использование EXPLAIN PLAN с Oracle: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm), с конкретной информацией о столбцах, найденных здесь: http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm#i18300

Ваше упоминание "FULL" указывает мне, что запрос выполняет полноэкранное сканирование, чтобы найти ваши данные. В некоторых случаях это нормально, в противном случае это показатель плохой записи индексирования/запроса.

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

В последних версиях Oracle COST представляет собой время, которое оптимизатор ожидает от запроса, выраженный в единицах времени, необходимого для чтения одного блока.

Итак, если чтение одного блока занимает 2 мс, а стоимость выражается как "250", запрос может потребоваться для завершения 500 мс.

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

Возникает вопрос о том, как оптимизатор знает, как долго выполняются операции. последние версии Oracle позволяют создавать коллекции "системной статистики", которые, безусловно, не следует путать со статистикой таблиц или индексов. Системная статистика - это измерения производительности аппаратного обеспечения, в основном важно:

• Как долго выполняется чтение одного блока.
• Как долго многозадачное чтение берет
• Насколько велико многоблочное чтение (часто отличное от максимально возможного из-за того, что размер таблицы меньше максимального значения и другие причины).
• Производительность процессора

Эти цифры могут сильно различаться в зависимости от операционной среды системы, и различные статистические данные могут храниться для операций "дневного OLTP" и операций "ночной периодической отчетности", а для "отчетов о конце месяца", если вы хотите.

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

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

Обратите внимание, что стоимость не обязательно настенное время, так как операции параллельного запроса потребляют общее количество времени для нескольких потоков.

В старых версиях Oracle стоимость операций с ЦП была проигнорирована, а относительная стоимость одно- и многоблочных чтений была эффективно исправлена ​​в соответствии с параметрами init.

FULL, вероятно, относится к полному сканированию таблицы, что означает, что индексы не используются. Обычно это указывает на то, что что-то не так, если только запрос не должен использовать все строки в таблице.

Стоимость - это число, которое сигнализирует сумму различных нагрузок, процессор, память, диск, IO и высокие числа, как правило, плохие. Числа добавляются при перемещении в корень плана, и каждая ветвь должна быть проверена для определения узких мест.

Вы также можете запросить v $sql и v $session для получения статистики о операторах SQL, и это будет иметь подробные показатели для всех видов ресурсов, таймингов и исполнений.