Петр дал вам ответ на вопрос, который вы задали.
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) позаботится о себе.
Обратите внимание: очистка общего пула и буферного кэша даже более искусственна, чем их очистка. Я подозреваю, что большинство людей скептически относятся к этому, потому что это противоречит общепринятому мнению. Я покажу вам, как это сделать, но не так, чтобы вы могли использовать его для тестирования. Скорее я буду использовать это, чтобы продемонстрировать, почему это бесполезное и абсолютно искусственное упражнение (и, следовательно, приводит к неправильным предположениям). Я только что запустил свой компьютер, и я выполнил этот запрос для большой таблицы. Я "очищаю" буферный кеш и запускаю его снова:
Я думаю, что Том Кайт абсолютно прав. С точки зрения решения проблемы производительности, я не думаю, что «очистка кэша плана выполнения Oracle» обычно является шагом для надежного бенчмаркинга.
Давайте рассмотрим проблему производительности.
Вы говорите нам, что заметили, что первое выполнение запроса занимает значительно больше времени (~ 28 секунд) по сравнению с последующими (~ 5 секунд), даже при очистке (все индексы и блоки данных из) буферный кеш.
Для меня это говорит о том, что hard parse делает некоторую тяжелую работу. Это либо много работы, либо много ожиданий. Это можно исследовать и настраивать.
Мне интересно, может быть, статистика не существует, и оптимизатор тратит много времени на сбор статистики, прежде чем подготовить план запроса. Это первое, что я хотел бы проверить, чтобы статистика собиралась по всем ссылочным таблицам, индексам и индексированным столбцам.
Если ваш запрос объединяет большое количество таблиц, CBO может рассмотреть огромное количество перестановок для порядка соединения.
Обсуждение трассировки Oracle выходит за рамки этого ответа, но это следующий шаг.
Я думаю, вы, вероятно, захотите отслеживать события 10053 и 10046.
Вот ссылка на обсуждение «события 10053» Тома Кайта, которое вам может пригодиться:
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:63445044804318
тангенциально связанный анекдотический рассказ о производительности жесткого анализа
Несколько лет назад я видел один запрос, который прошел в терминах МИНУТ при первом выполнении, а последующие - в секундах. Мы обнаружили, что подавляющее большинство времени для первого исполнения было потрачено на жесткий анализ.
Этот проблемный запрос был написан разработчиком CrystalReports, который невинно (наивно?) Присоединился к двум огромным представлениям отчетов.
Одно из представлений представляло собой объединение 62 таблиц, другое - объединение 42 таблиц.
В запросе использовался Оптимизатор на основе затрат. Трассировка показала, что это было не время ожидания, а все процессорное время, затрачиваемое на оценку возможных путей соединения.
Каждый из поставщиков, предоставивших «отчетные» представления, сам по себе не был слишком плох, но когда два из них были объединены, это было мучительно медленно. Я полагаю, что проблема заключалась в огромном количестве перестановок соединений, которые рассматривал оптимизатор. Существует параметр экземпляра, который ограничивает количество перестановок, рассматриваемых оптимизатором, но мы решили переписать запрос. Улучшенный запрос объединил только дюжину или около того таблиц, которые фактически были необходимы для запроса.
(Первоначальное немедленное краткосрочное исправление «помощь в полосе» состояло в том, чтобы запланировать выполнение запроса ранее утром, до запуска задачи генерации отчета. Это сделало генерацию отчета «более быстрой», поскольку использовался прогон генерации отчета) уже подготовленного оператора в общем пуле, избегая жесткого анализа.
Исправление поддержки группы не было реальным решением, оно просто перенесло проблему на предварительное выполнение запроса, когда долгое время выполнения не было замечено.
Нашим следующим шагом, вероятно, было бы внедрение «сохраненной схемы» для запроса, чтобы получить стабильный план запроса.
Конечно, повторное использование операторов (избегая жесткого анализа, используя переменные связывания) является нормативным шаблоном в Oracle. Это повышает производительность, масштабируемость, yada, yada, yada.
Этот случайный случай может полностью отличаться от проблемы, которую вы наблюдаете.
НТН