Базы данных Oracle - статьи
Анализ SQL- структуры
Часто SQL-предложение может быть слишком ресурсоемким только потому, что оно плохо написано. Это обычно случается, когда существуют различные (но не обязательно семантически эквивалентные) способы написания предложения для достижения того же самого результата. Например, SQL-предложение может давать тот же результат, когда его оператор UNION заменяется на UNION-ALL. Тот же самый результат возможен, если для исключения порождения двойных строк, устранение дублирования делается при помощи избыточного оператора UNION. В этом случае его лучше заменить на UNION-ALL, что устранит из плана выполнений затратный этап устранения дублирования. Другой пример – это использование подзапроса NOT IN в то время, как подзапрос NOT EXIST продуцировал бы тот же результат намного более эффективно.
Выяснение того, какая из этих альтернативных форм написания является наиболее эффективной – это кошмарная задача для разработчика приложений, так как она требует глубоких знаний как в области свойств данных (например, нет пустых значений в столбце), так и в области понимания семантики (то есть, смыслового значения) SQL-конструкций.
Кроме того, на стадии разработки разработчики в основном сосредоточены на том, как написать SQL-предложение так, чтобы оно давало желаемый результат и улучшало производительность. Иногда простая ошибка может заставить SQL-предложение выполняться очень плохо. Хороший тому пример – это несоответствие типа столбца и значение его предиката, что по существу исключает использование индексов, даже если они существуют и доступны.
Automatic Tuning Optimizer выполняет анализ SQL-структуры, чтобы обнаружить плохо написанные SQL-предложения, и рекомендует подвергнуть результат пользовательской поверке на предмет нахождения альтернативных способов написания SQL-предложения для улучшения его производительности. Для помощи в написании правильных SQL-предложений и в целях профилактики разработчики могут запускать SQL Tuning Advisor в режиме Limited.
В процессе построения плана при анализе SQL-структуры Automatic Tuning Optimizer генерирует обширные аннотации и диагностики и связывает их с планом выполнения. Аннотации содержат решения, сделанные оптимизатором, и приводят основания таких решений. Используя эти основания, ассоциированные с дорогостоящими операторами плана выполнения, Automatic Tuning Optimizer дает рекомендации или о том, как переписать SQL-предложение, или о том, как изменить схему, для улучшения производительности.
Существуют различные основания, связанные со структурой SQL-предложения, которые могут вызвать плохое выполнение. Часть из них -синтаксические, часть - семантические, а некоторые просто являются проблемами разработки. Мы сгруппировали эти основания по трем категориям:
- Semantic-Based Constructs: конструкция типа подзапрос NOT IN, когда заменяется соответствующим, но не являющимся семантическим эквивалентом подзапроса NOT EXISTS, может привести к существенному повышению производительности. Однако такая замена возможна, только если в связанных (join) столбцах объединения не присутствуют NULL-значения, гарантируя, таким образом, один и тот же результат при использовании любого из этих операторов. Другой пример – замена UNION на UNION-ALL, если нет вероятности получения дублированных строк в результате.
- Syntax-based Constructs: многие из них связаны с тем, как предикаты определены в SQL-предложении. Например, если предикат, такой как col=:bnd используется с col и :bnd, имеющих разные типы, то такой предикат не может быть использован как наездник (driver) индекса. Точно так же предикат, вовлекающий функцию или выражение (например, func(col)=:bnd, col+1=:bnd), не может быть использован как наездник индекса, если нет функционального индекса на выражение или на самое функцию.
- Design Issue: случайное использование, например, декартового произведения (Cartesian product) является обычной проблемой, встречающейся в том случае, когда одна из таблиц не соединена ни к какой-либо другой таблице в SQL-предложении. Это может произойти, если в запросе участвует большое число таблиц.
