Как я могу очистить кеш плана выполнения для сравнения?

Ответ 1

Питер дал вам ответ на вопрос, который вы задали.

alter system flush shared_pool;

Это утверждение, которое вы должны использовать для "удаления подготовленных операторов из кэша".

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

Как я указал в своем предыдущем комментарии (по вашему вопросу), v$sql не является таблицей. Это динамическое представление производительности, удобное табличное представление структур внутренней памяти Oracle. У вас есть привилегия SELECT для динамических представлений производительности, вы не можете удалять из них строки.

очистить общий пул и буферный кеш?

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

Должны ли мы нормально очищать общий пул и/или буферный кеш для измерения производительности запроса?

Короче говоря, ответ - нет.

Я думаю, что Том Ките очень хорошо справляется:

http://www.oracle.com/technology/oramag/oracle/03-jul/o43asktom.html
http://www.oracle.com/technetwork/issue-archive/o43asktom-094944.html

< выдержка >

Собственно, важно, чтобы инструмент настройки не делал этого. Важно запустить тест, проигнорировать результаты, а затем запустить его два или три раза и усреднить эти результаты. В реальном мире буферный кеш никогда не будет лишен результатов. Никогда. Когда вы настраиваетесь, ваша цель - уменьшить логический ввод/вывод (LIO), потому что тогда физический ввод-вывод (PIO) позаботится о себе.

Рассмотрим это: Очистка общего пула и кеш-буфера еще более искусственна, чем их удаление. Я подозреваю, что большинство людей скептически относятся к этому, потому что оно летит перед обычной мудростью. Я покажу вам, как это сделать, но вы не можете использовать его для тестирования. Скорее, я буду использовать его, чтобы продемонстрировать, почему это упражнение бесполезно и полностью искусственно (и поэтому приводит к ошибочным предположениям). Я только что начал свой компьютер, и я запустил этот запрос с большой таблицей. Я "зачищаю" буферный кеш и запускаю его снова:

</выдержка >

Я думаю, что Том Ките совершенно прав. Что касается решения проблемы производительности, я не думаю, что "очистка кэша плана выполнения оракула" обычно является шагом для надежного бенчмаркинга.

Позвольте затронуть проблему производительности.

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

Для меня это говорит о том, что жесткий синтаксис делает тяжелый подъем. Это либо большая работа, либо ее встреча с множеством ожиданий. Это можно исследовать и настроить.

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

Если ваш запрос объединяет большое количество таблиц, CBO может рассматривать огромное количество перестановок для порядка объединения.

Обсуждение трассировки Oracle выходит за рамки этого ответа, но это следующий шаг.

Я думаю, что вам, вероятно, захочется отслеживать события 10053 и 10046.

Здесь вы можете найти ссылку на дискуссию "событие 10053" Тома Ките:

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:63445044804318

тангенциально связанная анекдотическая история re: жесткая производительность синтаксического анализа

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

Этот запрос проблемы был написан разработчиком CrystalReports, который невинно (наивно?) присоединился к двум огромным представлениям отчетов.

Одним из видов было объединение 62 таблиц, другое представление было объединением 42 таблиц.

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

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

(Первоначальная немедленная краткосрочная "помощь по оказанию помощи бандам" заключалась в том, чтобы планировать запуск запроса раньше утром, прежде чем запускать задачу генерации отчета. Это сделало генерацию отчета "более быстрым", поскольку запуск отчета уже подготовленного оператора в общем пуле, избегая жесткого разбора.

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

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

Конечно, повторное использование оператора (избегая жесткого анализа, используя переменные связывания) является нормативным шаблоном в Oracle. Он улучшает производительность, масштабируемость, yada, yada, yada.

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

НТН

Ответ 2

Прошло некоторое время с тех пор, как я работал с Oracle, но я считаю, что планы выполнения кэшируются в общем пуле. Попробуйте следующее:

alter system flush shared_pool;

Буферный кеш - это то, где Oracle хранит недавно используемые данные, чтобы свести к минимуму диск io.

Ответ 3

В последнее время мы много работаем с запросами настройки производительности, и одним из виновников непоследовательной производительности запросов является кэш файловой системы, на котором сидит Oracle.

Возможно, что пока вы очищаете кеш Oracle, файловая система по-прежнему имеет данные, которые ваш запрос запрашивает, чтобы запрос все равно быстро возвращался.

К сожалению, я не знаю, как очистить кеш файловой системы - я просто использую очень полезный script от наших очень полезных системных администраторов.