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

Question

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

Answer 1

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

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

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

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

SELECT emp_id FROM employees WHERE months_of_service = 6;

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

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

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

Давайте представим, что таблица "employee" содержит 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

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

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

Answer 3

Вот ссылка для использования 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 может найти данные, которые вы ищете, с доступом к наименьшему количеству возможных строк. В конечном счете, иногда вы можете зайти так далеко от архитектуры ваших таблиц. Если затраты остаются слишком высокими, вам, возможно, придется подумать о том, чтобы настроить макет вашей схемы так, чтобы он был в большей степени основан на производительности.

Answer 4

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

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

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

Это поднимает вопрос о том, как оптимизатор знает, сколько времени занимает операция. последние версии Oracle позволяют собирать «системную статистику», которую определенно не следует путать со статистикой таблиц или индексов. Системная статистика - это измерения производительности оборудования, в основном это важно:

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

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

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

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

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

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

Answer 5

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

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

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