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

 

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

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

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


B I ООО 000-строчной таблице Orders может быть лишь три или четыре разных значения Status_Code, но если ' OP' означает открытый заказ, еще не выполненный или отмененный, то это условие становится намного более селективным, чем оптимизатор мог бы предположить, основываясь только на количестве различных значений. Если для этого столбца существует индекс, оптимизатор может никогда не задействовать его, поскольку будет знать лишь о небольшом количестве различных индексированных значений. Однако в некоторых базах данных можно сгенерировать дополнительную статистику, которая позволит базе данных узнать не только количество различных значений, но также их распределение. Генерация подобной статистики является необходимым шагом, когда в таблице присутствуют такие асимметричные распределения данных.

Обман стоимостного оптимизатора плохими данными

Последняя техника опасна, и я рекомендую использовать ее только в качестве последнего средства. Иногда вам нужно имитировать большую базу данных на небольшой, тестовой базе данных. Если вы можете экстраполировать (или, лучше, измерить в реальной базе данных) статистику скорости выполнения запросов для большой базы данных, то сумеете вручную изменить таблицы словаря данных, в которых хранится статистика для оптимизатора, чтобы обмануть оптимизатор и заставить его думать, что он работает с крупной базой данных. Статистика небольшой базы данных будет убеждать сервер, что он работает с большими таблицами, содержащими большое количество различных значений для многих индексов. Это удобный способ проверки планов выполнения, которые будут применяться к промышленным объемам данных, когда у вас есть лишь тестовая база данных с «игрушечными» объемами. Для таких игрушечных баз данных в подобном подходе нет никакого риска. В промышленных базах данных оптимизатор иногда будет делать лучший выбор именно на фальшивых данных; обычно, если данные преувеличи-
Управление планами в Oracle

107

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

Попробуйте мысленно перевернуть логику оптимизатора. Спросите: «Что я должен знать о таблицах и индексах этого запроса, чтобы посчитать альтернативный план (альтернативу, которую хотите получить вы, человеческий оптимизатор) намного более привлекательным?» Если предоставить оптимизатору неверную статистику, то нетрудно будет обмануть его и заставить сделать то, что нужно вам, а не то, что он выбрал бы самостоятельно. Ho в промышленных системах это опасно по нескольким причинам.

¦ Как только кто-либо заново сгенерирует статистику для таблиц или индексов, оптимизатор вернется к обычному способу действия, если только статистика не будет настроена вручную. Для предотвращения таких ситуаций вам придется строго следить за генерированием статистики.

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

¦ Что самое важное, любой другой запрос к таблицам и индексам с фальшивой статистикой будет считаться рискованным и потенциально может быть поврежден. И все только из-за того, что статистика была сфальсифицирована, чтобы помочь одному запросу.

Мне никогда не требовалось применять этот способ для получения адекватного оптимизированного плана в Oracle, SQL Server или DB2, и я рекомендую вам также избегать его.

Управление планами в Oracle

В текущее время Oracle предлагает два совершенно разных оптимизатора: синтаксический (rule-based optimizer, RBO) и стоимостный (cost-based optimizer, СВО), с различными методами настройки.

RBO — это исходный автоматизированный оптимизатор Oracle, существовавший еще в Oracle Version 6 и более ранних версиях. Под определением «синтаксический» Oracle подразумевает, что оптимизатор использует только фиксированные свойства таблиц, индексов и SQL для определения оптимального плана выполнения при помощи набора простых «правил большого пальца» (или эвристических), встроенных в автоматизированный оптимизатор. RBO не учитывает сведения о размерах таблиц и индексов или о распределении данных в этих объектах. Он использует данные о фиксированных свойствах индексов — уникальны ли они, какие столбцы они охватывают, в каком порядке и насколько хорошо они соответствуют выглядящим наиболее селективными условиям фильтров и соединениям в SQL. По мере того как таблицы растут и распределение данных изменяется, RBO все также выдает один и тот же план, если только вы не изменяете индексы (например, из уникальных делаете неуникальные) или структуру таблиц (например, из обычной таблицы делаете таблицу с разбиениями). Однако в будущем (возможно, даже в Oracle Database IOg) Oracle прекратит поддерживать синтаксический оптимизатор и стоимостный оптимизатор станет вашим единственным выбором.
108

4. Управление планами выполнения

Начиная с Oracle7, RBO стал еще более стабильным, чем раньше, так как Oracle решила заморозить код RBO, за исключением редких и небольших изменений, необходимых для получения функционально верных (в противоположность обязательно оптимальным) результатов. Таким образом, план выполнения, являющийся правильным в RBO сегодня, скорее всего, останется верным, пока Oracle полностью не прекратит поддержку RBO. Это привлекательно с точки зрения стабильности, хотя оборотной стороной этой стабильности является то, что планы выполнения также никогда не станут лучше.
Предыдущая << 1 .. 47 48 49 50 51 52 < 53 > 54 55 56 57 58 59 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100