Чтобы использовать план выполнения (который представляет собой описание того, как база данных будет реализовывать ваш запрос), необходимо понять, какие варианты доступны для нее (база данных), и принять решение о том, был ли сделан выбор. оптимизатором был правильный. Это требует много знаний и опыта.
Для работы, которую я выполняю (обработка ETL), «проблемы» производительности обычно делятся на две категории:
- Запрос занимает много времени, потому что чтение большого количества данных занимает много времени :)
- Оптимизатор допустил ошибку и выбрал неверный план выполнения
Для (1) я должен решить, могу ли я реструктурировать данные по-другому, чтобы я сканировал меньше данных. Индексы редко используются, поскольку меня интересуют достаточно большие подмножества, чтобы сделать индексированный доступ медленнее, чем полное сканирование таблицы. Например, я мог бы хранить горизонтальное подмножество данных (последние 30 дней) или вертикальное подмножество данных (10 столбцов вместо 80), или совокупность данных. В любом случае размер данных будет уменьшен, что приведет к увеличению скорости обработки. Конечно, если данные используются только один раз, я просто перенес проблему в другое место.
Для (2) я обычно начинаю с проверки "Кардинальности" (количество строк) в верхней строке в xplan. Если я знаю, что мой запрос возвращает 5 000 000 строк, но он говорит о 500, я могу быть уверен, что оптимизатор где-то ошибся. Если общая мощность находится в правильном парке, я начинаю с другого конца и проверяю каждый шаг плана, пока не найду первую большую ошибку оценки. Если количество элементов неверно, метод соединения, вероятно, неправильный между этой таблицей и следующей, и эта ошибка будет касаться остальной части плана.
Google для "Настройка с помощью обратной связи по количеству элементов", и вы найдете статью, написанную Вольфгангом Брайтлингом, который описывает (в гораздо лучшем смысле) причудливый подход. Это действительно хорошее чтение!
Кроме того, обязательно побродите вокруг Блог Джонатана Льюиса . если есть что-то о оптимизаторе Oracle, которого он не знает, это не стоит знать. Он также написал лучшую книгу на эту тему. Ознакомьтесь с Основы Oracle на основе стоимости . Если бы я мог отправить себе одну книгу вовремя, это было бы так.
Эксперт Oracle Database Architecture Тома Кайта (человек, стоящий за "Спроси у Тома"), также отлично читается. Мое первое чтение этой книги было разочарованием, потому что я искал "советы по настройке" и не нашел ни одного. Во время второго чтения я понял, что, зная, как работает база данных, вы можете устранить целые классы проблем с производительностью путем «проектирования для повышения производительности» с самого начала вместо «добавления» производительности в конце:)
SQL Tuning от Dan Tow, еще одно удивительное прочтение основ того, как именно можно определить оптимальный план выполнения. Эти знания могут быть использованы для устранения неполадок в плане выполнения (или для того, чтобы оптимизатор сделал это по-своему).
Если бы вы сделали это так далеко, сейчас самое время возиться с подсказками. Не раньше.