Насколько точен Oracle EXPLAIN PLAN?

Question

Есть ли хорошие способы объективно измерить производительность запроса в Oracle 10g? Есть один конкретный запрос, который я настраивал в течение нескольких дней. Я получил версию, которая работает быстрее (по крайней мере, на основе моих первоначальных тестов), но стоимость EXPLAIN примерно такая же.

1. Насколько вероятно, что стоимость EXPLAIN чего-то не хватает?
2. Существуют ли какие-либо конкретные ситуации, когда стоимость EXPLAIN непропорционально отличается от фактической производительности запроса?
3. Я использовал подсказку first_rows для этого запроса. Имеет ли это влияние?

Answer 1

Насколько вероятно, что стоимость EXPLAIN чего-то не хватает?

Очень маловероятно. Фактически, это будет ошибка уровня 1:

На самом деле, если ваша статистика значительно изменилась с момента запуска EXPLAIN, фактический план запроса будет отличаться. Но по мере того, как запрос компилируется, план останется прежним.

Примечание EXPLAIN PLAN может показывать вам вещи, которые могут произойти, но могут никогда не произойти в реальном запросе.

Например, если вы запускаете EXPLAIN PLAN для иерархического запроса:

SELECT  *
FROM    table
START WITH
        id = :startid
CONNECT BY
        parent = PRIOR id

с индексами на id и parent вы увидите дополнительные FULL TABLE SCAN, которые, скорее всего, не произойдут в реальной жизни.

Используйте STORED OUTLINE для хранения и повторного использования плана независимо от того, что.

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

Да, очень часто это происходит при сложных запросах.

CBO (оптимизатор на основе затрат) использует вычисленную статистику для оценки времени запроса и выбора оптимального плана.

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

Вот конкретная ситуация, о которой вы спрашивали: например, HASH JOIN потребуется несколько проходов над probe table, если хеш-таблица не вписывается в pga_aggregate_table, но с Oracle 10g я не помните, что это когда-либо будет принято во внимание CBO.

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

Я использовал подсказку first_rows для этого запроса. Имеет ли это влияние?

Эта подсказка заставит оптимизатор использовать план с более низким ответом времени: он вернет первые строки как можно скорее, несмотря на то, что общее время запроса будет больше.

Практически, это почти всегда означает использование NESTED LOOP вместо HASH JOIN.

NESTED LOOP имеют более низкую общую производительность для больших наборов данных, но они возвращают первые строки быстрее (так как не нужно создавать хеш-таблицу).

Что касается запроса из вашего исходного вопроса , см. Мой ответ здесь .

Answer 2

Q: Есть ли хорошие способы объективно измерить производительность запроса в Oracle 10g?

• Трассировка Oracle - лучший способ измерения производительности. Выполните запрос и дайте возможность Oracle выполнить выполнение. В среде SQLPlus использовать AUTOTRACE очень просто.

http://asktom.oracle.com/tkyte/article1/autotrace.html (статья перемещена)
http://tkyte.blogspot.com/2007/04/when-explanation-doesn-sound-quite.html
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:5671636641855

А включить трассировку Oracle в других средах не так сложно.

Q: Есть один конкретный запрос, который я настраивал в течение нескольких дней. Я получил версию, которая работает быстрее (по крайней мере, на основе моих первоначальных тестов), но стоимость EXPLAIN примерно такая же.

• Фактическое выполнение оператора - это то, что должно быть измерено. EXPLAIN PLAN неплохо предсказывает план оптимизатора, но на самом деле он не измеряет производительность.

Q: > 1. Насколько вероятно, что стоимость EXPLAIN чего-то не хватает?

• Не очень вероятно, но я видел случаи, когда EXPLAIN PLAN предлагает план, отличный от оптимизатора.

Q: > 2. Есть ли какие-либо конкретные ситуации, когда стоимость EXPLAIN непропорционально отличается от фактической производительности запроса?

• Короткий ответ: я не наблюдал ни одного. Но опять же, на самом деле нет прямой связи между стоимостью ОБЪЯСНИТЕЛЬНОГО ПЛАНА и фактической наблюдаемой производительностью. EXPLAIN PLAN может дать действительно большое число по стоимости, но фактический запрос будет выполнен менее чем за секунду. EXPLAIN PLAN не измеряет фактическую производительность запроса, для этого вам нужна трассировка Oracle.

Q: > 3. Я использовал подсказку first_rows в этом запросе. Имеет ли это влияние?

• Любая подсказка (например, /*+ FIRST_ROWS */) может повлиять на то, какой план выбран оптимизатором.

---

«Стоимость», возвращаемая ОБЪЯСНЕННЫМ ПЛАНОМ, является относительной. Это показатель эффективности, но не точный показатель. Вы не можете перевести число затрат в число операций с диском, количество секунд процессора или количество событий ожидания.

Как правило, мы находим, что оператор со стоимостью EXPLAIN PLAN, показанной как 1, выполняется «очень быстро», а оператор со стоимостью EXPLAIN PLAN порядка пяти или шести цифр может занять больше времени для запустить. Но не всегда.

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

Я видел случаи, когда план оптимизатора, показанный EXPLAIN PLAN, NOT соответствует фактическому плану, используемому при выполнении оператора. Я видел это десять лет назад с Oracle8, особенно когда в операторе использовались переменные связывания, а не литералы.

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

[http://asktom.oracle.com/tkyte/article1/autotrace.html][4]

Вне среды SQLPlus вы можете включить трассировку Oracle:

    alter session set timed_statistics = true;
    alter session set tracefile_identifier = here_is_my_session;
    alter session set events '10046 trace name context forever, level 12'
    --alter session set events '10053 trace name context forever, level 1'
    select /*-- your_statement_here --*/ ...
    alter session set events '10046 trace name context off'
    --alter session set events '10053 trace name context off'

Это помещает файл трассировки в каталог user_dump_dest на сервере. Созданный файл трассировки будет иметь план оператора и все события ожидания. (Назначенный идентификатор файла трассировки включен в имя файла и облегчает поиск вашего файла в каталоге udump)

    select value from v$parameter where name like 'user_dump_dest'

Если у вас нет доступа к файлу трассировки, вам потребуется помощь dba, чтобы получить доступ. (Dba может создать простой сценарий оболочки, который разработчики могут запускать с файлом .trc для запуска tkprof, и изменять разрешения для файла трассировки и вывода tkprof. Вы также можете использовать более новую версию trcanlzr. и.

Answer 3

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

Answer 4

По моему опыту EXPLAIN была точной и полезной. Если бы это было не так, это не могло бы быть полезным инструментом. Когда вы в последний раз анализировали таблицы? Я видел, где план объяснения был почти одинаковым до и после анализа, но анализ принес огромный прирост производительности.