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



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

376   5  

5 ответов:

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

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

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

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

SELECT emp_id FROM employees WHERE months_of_service = 6;

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

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

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

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

стоимостью план 1, что включает в себя полное сканирование, будет стоимость чтения всех строк в таблице employees, которая примерно равна 1,000,000; но поскольку Oracle часто сможет читать блоки с помощью многоблочных считываний, фактическая стоимость будет ниже (в зависимости от того, как настроена ваша база данных) - например, давайте представим, что количество считываний нескольких блоков равно 10 - the расчетная стоимость полного сканирования составит 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 (index scan + access by rowid) - что означает, что CBO выберет полное сканирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ничего не найдено.

Добавить ответ:
Отменить.