Как устранить проблемы с производительностью с помощью оператора Oracle SQL

Используйте Средство трассировки SQL и TKPROF.

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

Я видел системы, в которых индексы отбрасываются перед массовой вставкой и перестраиваются в конце - и это быстрее.

Первое, что нужно понять, это то, что, как в документации говорится, отображаемая стоимость зависит от одного из планов запроса. Затраты на 2 разных объяснения сопоставимы нет. Во-вторых, затраты основаны на внутренней оценке. Как ни старается Oracle, эти оценки не точны. Особенно, когда оптимизатор плохо себя ведет. Ваша ситуация предполагает, что есть два плана запросов, которые, по мнению Oracle, очень близки по производительности. Но которые, на самом деле, работают по-разному.

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

Что дальше? Что ж, есть множество стратегий для исправления плохих заявлений. Первый вариант, который я бы предложил, если вы используете Oracle 10g, - это попробовать их Советник по настройке SQL, чтобы увидеть, сообщит ли Oracle более подробный анализ об ошибке его пути. Затем он может сохранить этот план, и вы будете использовать более эффективный план.

Если вы не можете этого сделать или это не сработает, вам нужно заняться такими вещами, как предоставление подсказок по запросу, сохраненные вручную схемы запроса и т. д. Это сложная тема. Вот где помогает настоящий администратор базы данных. Если вы этого не сделаете, тогда вы захотите начать читать документация, но имейте в виду, что есть чему поучиться. (У Oracle также есть класс настройки SQL, который является или, по крайней мере, когда-то был очень хорошим. Однако это не дешево.)

Я согласен с предыдущим постером, что SQL Trace и tkprof - хорошее место для начала. Я также настоятельно рекомендую книгу Оптимизация производительности Oracle, в которой обсуждаются аналогичные инструменты для отслеживания выполнения и анализа вывода.

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

Любимые приемы настройки производительности

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

SQL Trace и tkprof хороши только в том случае, если у вас есть доступ к этим инструментам. Большинство крупных компаний, в которых я работаю, не позволяют разработчикам получать доступ к чему-либо под идентификаторами Oracle unix.

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

Еще один хороший справочник, который представляет общую технику настройки запросов, - это книга Дэна Тоу Настройка SQL.

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

Когда производительность оператора sql не соответствует ожидаемому / желаемому, первое, что я делаю, это проверяю план выполнения.

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

Точка, в которой оптимизатор Oracle иногда ошибается, - это оценки количества строк, возвращаемых шагом. Если план выполнения ожидает 2 строки, но вы знаете, что он будет больше похож на 2000 строк, план выполнения обязательно будет менее оптимальным.

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

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

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

а) по-прежнему делает то, что должен делать

б) на самом деле быстрее

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

Если вы найдете лучший план выполнения, последний шаг - заставить вашу базу данных действительно использовать его в реальной программе. Если вы добавили индекс, это часто срабатывает из коробки. Подсказки - это вариант, но они могут быть проблематичными, если библиотека создает ваш оператор sql, они часто не поддерживают подсказки. В крайнем случае вы можете сохранять и исправлять планы выполнения для определенных операторов sql. Я бы избегал этого подхода, потому что о нем легко забыть, и примерно через год какой-нибудь плохой разработчик почесает затылок, почему этот оператор работает таким образом, который мог быть неуместным с данными год назад, но не с текущим данные ...