Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 54

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 48 49 50 51 52 53 < 54 > 55 56 57 58 59 60 .. 161 >> Следующая


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

ПРИМЕЧАНИЕ --------------------------------------------------------------------

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

Еще один аргумент в пользу CBO — то, что он может выдавать параллельные планы выполнения, планы, которые могут заставить несколько процессоров одновременно обрабатывать один SQL-запрос. Я не считаю этот аргумент столь уж серьезным, поскольку в реальной работе мне еще не встречался случай, когда для достижения адекватной производительности оптимальному SQL-запросу с правильным дизайном базы данных требовалось параллельное выполнение. Можно предположить, что такие запросы могут выполняться в хранилищах данных, с которыми я работал не слишком много. Однако практически во всех случаях, в которых, казалось бы, параллельные планы выполнения демонстрируют блистательную скорость, на самом деле скрывается ошибка в дизайне базы данных, индексах или дизайне приложения, последствия которой компенсируются аппаратной мощностью. Само по себе это не так уж и страшно — дополнительная аппаратная мощность может обойтись дешевле, чем исправление приложения. Однако параллельные планы обычно используются для больших пакетных процессов, которые отнимают ресурсы у оперативных процессов, более важных для конечных пользователей. То есть параллельные планы выполнения часто крадут необходимые ресурсы у других, более важных приложений.

Самые сильные аргументы против использования RBO.

¦ Он станет недоступным в какой-либо очередной версии, возможно даже в Oracle Database I Og, и вы никогда не сможете использовать более старую версию сервера

¦ CBO постоянно улучшается, в то время как RBO застрял на одном месте с теми же старыми проблемами, какие у него были всегда.

¦ У CBO есть огромное преимущество, позволяющее ему пользоваться соответствующей информацией для вычисления наилучшего плана.

¦ RBO не может использовать преимущества функций, созданных после появления CBO в Огас1е7, и в большинстве случаев RBO просто перебрасывает за-
Управление планами в Oracle

109

просы, содержащие новые типы объектов, такие как растровые индексы, СВО. (Подробнее о том, какие функции не обрабатывает RBO1 в следующем разделе, «Управление выбором оптимизатора в Oracle».)

Ho, с другой стороны, RBO выполняет свою работу на удивление хорошо. Его эвристические функции прекрасно справляются с выбором наилучшего плана, обладая лишь небольшим объемом информации. В главе 6 я опишу свойства плана, который я называю надежным, плана, который хорошо работает на самых различных распределениях данных. RBO практически всегда выдает надежный план, если есть все необходимые индексы и разработчик не запретил использование индекса каким-либо из способов, рассмотренных ранее в этой главе. Имея правильные индексы, вы практически всегда можете получить наилучший план с любым из оптимизаторов, дополнив его ручной настройкой. При автоматизированной настройке самое большое преимущество CBO — его изобретательность, которую он проявляет даже с не идеальным индексированием и не оптимальным SQL. Чаще всего он выдает, по крайней мере, адекватный план, даже без ручной настройки. Когда возможно появление нескольких надежных планов, CBO с большей вероятностью найдет наилучший надежный план, a RBO выберет один из них, не зная относительной стоимости, если только вы не настроите SQL вручную.

Управление выбором оптимизатора в Oracle

Невозможно одновременно оптимизировать запросы Oracle для синтаксического и стоимостного оптимизаторов. Поэтому вы должны понимать, какими факторами руководствуется Oracle при выборе оптимизатора, и контролировать эти факторы, заставляя выбрать нужный оптимизатор.

RBO не может обрабатывать объекты определенных типов и свойства объектов, которые еще не существовали на момент, когда Oracle заморозила код RBO. Однако вместо того, чтобы просто выдавать сообщение об ошибке, Oracle модифицировала код RBO1 чтобы оптимизатор умел распознавать недопустимые для него случаи и передавать их СВО. Так, даже если вы думаете, что заставили систему использовать синтаксическую оптимизацию, в следующих ситуациях абсолютно точно будет использоваться стоимостная оптимизация.

¦ Существуют растровые индексы по любому столбцу таблицы, упомянутой в SQL-запросе, даже если эти индексы охватывают столбцы, к которым запрос не обращается.

¦ В таблице, упомянутой в SQL-запросе, существуют индексы, базирующиеся на функциях, и индексы, созданные по выражению, которое встречается в запросе.
Предыдущая << 1 .. 48 49 50 51 52 53 < 54 > 55 56 57 58 59 60 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100