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

Question

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

Answer 1

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

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

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

Например, предположим, что у вас есть следующий запрос: (. Колонку months_of_service имеет NOT NULL ограничение на него и обычный индекс на нем)

SELECT emp_id FROM employees WHERE months_of_service = 6; 

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

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

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

Стоимость План 1, в котором используется ПОЛНЫЙ СКАНИРОВАНИЕ, будет стоить чтение всех строк в таблице сотрудников, что примерно равно 1 000 000; но поскольку Oracle часто может считывать блоки с использованием многоблочных чтений, фактическая стоимость будет ниже (в зависимости от того, как настроена ваша база данных) - например, давайте представим, что количество отсчетов с несколькими блоками равно 10 - расчетная стоимость полного сканирования составит 1,000,000/10; Общая стоимость = 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, потому что он будет часто возвращать первые несколько строк быстрее, ценой менее эффективной для всего запроса.

Answer 2

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

Ваше упоминание о «ПОЛНЫЙ» указывает мне, что запрос делает полный стол сканировать, чтобы найти свои данные. В некоторых ситуациях это нормально, в противном случае это показатель плохой записи индексирования/запроса.

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

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

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

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

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

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