Понимание результатов Execute Explain Plan в Oracle SQL Developer

Я пытаюсь оптимизировать запрос, но не совсем понимаю некоторую информацию, возвращенную из План. Может ли кто-нибудь сказать мне значение столбцов опций и стоимости? В столбце OPTIONS я вижу только слово FULL. В столбце стоимость я могу вывести, что более низкая стоимость означает более быстрый запрос. Но что именно представляет собой себестоимость и что такое приемлемый порог?

57
oracle oracle-sqldeveloper sql-execution-plan

5 ответов

вывод плана EXPLAIN-это отладочный вывод из оптимизатора запросов Oracle. Стоимость-это конечный результат работы оптимизатора на основе затрат (CBO), цель которого-выбрать, какой из множества возможных планов следует использовать для выполнения запроса. CBO вычисляет относительную стоимость для каждого плана, а затем выбирает план с наименьшей стоимостью.

(Примечание: В некоторых случаях CBO не хватает времени для оценки каждого возможного плана; в этих случаях он просто выбирает план с самой низкой стоимостью, найденной до сих пор)

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

например, допустим у вас есть следующий запрос:

SELECT emp_id FROM employees WHERE months_of_service = 6;

(том months_of_service столбец имеет ограничение NOT NULL и обычный индекс на он.)

есть два основных плана оптимизатор может выбрать здесь:

  • план 1: прочитайте все строки из таблицы "employees", для каждого проверьте, истинен ли предикат (months_of_service=6).
  • План 2: прочитайте индекс, где months_of_service=6 (это приводит к набору ROWIDs), затем получить доступ к таблице на основе возвращенных ROWIDs.

давайте представим, что таблица "сотрудники" имеет 1,000,000 (1 миллион) строк. Давайте далее представим, что значения months_of_service варьируются от 1 до 12 и по какой-то причине довольно равномерно распределены.

стоимостью план 1, который включает в себя полное сканирование, будет стоить чтение всех строк в таблице сотрудников, что примерно равно 1,000,000; но так как Oracle часто сможет читать блоки с помощью чтения нескольких блоков, фактическая стоимость будет ниже ( в зависимости от того, как настроена ваша база данных) - например, давайте представим, что количество чтения нескольких блоков равно 10 - расчетная стоимость полного сканирования составит 1,000,000 / 10; Overal cost = 100,000.

стоимостью План 2, который включает в себя сканирование диапазона индексов и поиск таблицы по ROWID, будет стоить сканирование индекса, а также стоимость доступа к таблице по ROWID. Я не буду вдаваться в то, как сканирование диапазона индексов оценивается, но давайте представим, что стоимость сканирования диапазона индексов составляет 1 за строку; мы ожидаем найти совпадение в 1 из 12 случаев, поэтому стоимость сканирования индекса составляет 1,000,000 / 12 = 83,333; плюс стоимость доступа к таблице (предположим, 1 блок чтения на доступ, мы не можем использовать многоблочные чтения здесь) = 83,333; общая стоимость = 166,666.

как вы можете видеть, стоимость плана 1 (полное сканирование) меньше, чем стоимость плана 2 (сканирование индекса + доступ по rowid) - что означает, что CBO выберет полное сканирование.

Если предположения, сделанные здесь оптимизатором, верны, то на самом деле план 1 будет предпочтительнее и намного эффективнее, чем План 2, который опровергает миф о том, что полное сканирование "всегда плохо".

результаты были бы совершенно разными, если бы целью оптимизатора был FIRST_ROWS(n) вместо ALL_ROWS - в этом случае оптимизатор предпочел бы План 2, потому что он часто будет возвращать первые несколько строк быстрее, ценой того, чтобы быть менее эффективным для всего запроса.

96

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

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

7

вот ссылка на использование 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

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

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

6

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

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

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

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

  1. сколько один блок прочитать занимает
  2. сколько времени занимает многоблочное чтение
  3. насколько велик мультиблок чтения (часто отличается от максимально возможного из-за того, что экстенты таблицы меньше максимального и других причин).
  4. производительность процессора

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

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

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

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

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

3

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

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

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

1