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

Question

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

Я узнал, что мой вопрос - ответ. Я должен включить osOther в TFDPhysObjectScopes.

DM.FDConnection.GetTableNames(ADatabse, '', APattern, tables, [osMy, osOther], [tkTable], False);

34

sql oracle10g

задан 13 May 2009 в 16:03

3 ответа

Другие вопросы по тегам:

sql oracle10g

Похожие вопросы:

score 17 · Answer 1

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

alter system flush shared_pool;

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

score 52 · Answer 2

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

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 секунд), даже при очистке (всех индексов и блоков данных из) буферного кеша.

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

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

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

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

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

Вот ссылка на Обсуждение «события 10053» Тома Кайта может оказаться полезным:

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

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

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

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

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

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

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

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

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

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

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