Министерство Образования РФ Удмуртский Государственный

Министерство Образования РФ
Удмуртский Государственный Университет
Физический факультет
Реферат по теме: «Оптимизатор запросов в Oracle 10g»
Выполнил: Саитов А.М., группа 38-41
Проверил: Вотницев А.А.
Ижевск
2006
Со времени своего появления в Oracle7 стоимостной оптимизатор (CBO)
становился все более важным и значимым с каждой новой версией Oracle, в
то время как его аналог - оптимизатор, основанный на правилах (RBO),
становился
все
менее
таковым.
Различие
между
этими
двумя
оптимизаторами относительно ясно: CBO выбирает наилучший путь для
запросов, основываясь на сведениях о ваших данных, с использованием
таких возможностей баз данных Oracle, как двоичные (bitmap)-индексы,
индексы, основанные на функции, хэш (hash)-соединения, индексные
таблицы и секционирование, тогда как RBO просто следует установленным
правилам (эвристика). В версии Oracle Database 10g устаревание RBO
признано официально, а CBO снова существенно улучшен.
Начнем с того, что теперь CBO имеет специальный режим настройки,
который используется многими другими средствами Oracle Database 10g,
включая SQL Tuning Advisor и SQL Access Advisor. Одним из результатов,
сгенерированным режимом настройки SQL, является SQL-профиль –
дополнительная статистика, относящаяся к заданному оператору, которую
можно сохранить в словаре данных и использовать во время выполнения (во
время обычных операций CBO) для улучшения производительности SQL.
SQL-профили особенно полезны для пакетных приложений (или для любого
приложения, к исходному коду которого нет доступа).
SQL-профили
используют
выборку
для
сбора
дополнительной
информации; технику частичного выполнения для контроля и настройки
стоимостных оценок; и информацию об истории выполнения SQLпредложения для изменения при необходимости значений параметров. За
дополнительной
информацией
обратитесь
к
Приложению
1
и
к
соответствующим статьям по использованию SQL Tuning Advisor и SQL
Access Advisor, приводимых на сервере http://www.oracle.com.
Кроме того, Oracle внес ряд фундаментальных изменений в нормальное
поведение CBO, включая изменения в стоимостной модели и механизме
преобразований. Давайте посмотрим на эти изменения в контексте обработки
SQL-предложения.
Oracle
Database
10g
CBO
построен
на
новой
структуре
преобразований.
SQL-запросы, переданные в ядро базы данных Oracle, сперва проходят
через анализатор, который проверяет синтаксис и анализирует семантику.
Результатом этого просмотра является набор групп запросов, которые
направляются в оптимизатор, объединяющий три основных функциональных
подсистемы, а именно: механизм преобразования запросов, блок оценки и
генератор планов.
Механизм
преобразования
запросов
использует
эвристику,
т.е.
основанные на правилах алгоритмы для групп запросов. Ряд общих
преобразований включает select-join, group-by, distinct-view
merging и перезапись материализованных представлений (см. Приложение
2).
Однако, что более важно, изменилась сама стоимостная модель. В
Oracle9i Database CBO использовал стоимостную модель I/O, которая все
оценивала главным образом на основе чтений единичных блоков, почти
совершенно игнорируя стоимость CPU (или используя константы для оценки
стоимости CPU). В Oracle Database 10g, стоимостная модель теперь включает
системную статистику, которая реально отслеживает CPU и I/O системы по
отношению к рабочей нагрузке Oracle.
Oracle Database 10g CBO использует новую стоимостную модель
В Oracle Database 10g стоимостной моделью по умолчанию является
CPU плюс I/O, где единицей стоимости служит время: CBO оценивает время
выполнения запроса путем подсчета числа операций I/O, типа операций I/O,
и числа циклов CPU, которые будет выполнять база данных в процессе
выполнения запроса. Эти оценки зависят от наличия системной статистики,
которую CBO использует для преобразования числа циклов CPU и числа
операций I/O к времени выполнения. (Заметьте, что некоторые операции,
такие как bitmap-слияние, сортировка, или hash-соединения, могут не
требовать операций I/O, но все такие операции содержат компонент CPU).
Oracle Database 10g накапливает два типа системной статистики:
статистика, собранная без рабочей нагрузки (noworkload), и статистика,
собранная с учетом рабочей нагрузки. Статистика без рабочей нагрузки
отражает производительность системы I/O – среднее время поиска I/O и
скорость передачи - и быстродействие CPU. При сборе статистики без
рабочей нагрузки CBO производит пробные считывания различных объемов
из файлов базы данных; он замеряет каждое считывание и затем использует
статистические методы для вычисления среднего времени поиска и скорости
передачи. Это занимает от нескольких секунд до нескольких минут. CBO
вычисляет быстродействие CPU в миллионах циклов в секунду.
Статистика с рабочей нагрузкой позволяет CBO быть в курсе загрузки.
Системная статистика, собранная в условиях рабочей нагрузки, позволяет
понять, ограничена ли система по I/O или CPU; соответственно, CBO
использует эти данные для корректировки стоимостей планов. Для сбора
статистики с рабочей нагрузкой надо выполнить следующие команды в
начале и в конце работы:
dbms_stats.gather_system_stats(gathering_mode=>'start')
...
dbms_stats.gather_system_stats(gathering_mode=>'stop')
Значения, полученные при запросе из sys.aux_stats$, выглядят
следующим образом:
SQL> select sname, pname, pval1
from sys.aux_stats$;
SNAME
------------SYSSTATS_INFO
SYSSTATS_INFO
SYSSTATS_INFO
SYSSTATS_INFO
SYSSTATS_MAIN
PNAME
PVAL1
--------- ------STATUS
DSTART
DSTOP
FLAGS
1
CPUSPEEDNW 502.005
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
SYSSTATS_MAIN
IOSEEKTIM
IOTFRSPEED
SREADTIM
MREADTIM
CPUSPEED
MBRC
MAXTHR
SLAVETHR
10
4096
7.618
14.348
507
6
32768
13 rows selected.
CPUSPEEDNW, IOSEEKTIM и IOTFRSPEED являются параметрами
статистики без рабочей нагрузки; SREADTIM, MREADTIM, CPUSPEED, MBRC,
MAXTHR и SLAVETHR отражают статистику с учетом рабочей нагрузки.
Если доступны оба типа статистики, оптимизатор использует статистику
с рабочей нагрузкой.
SREADTIM – время чтения одного блока (мс) - это среднее время, за
которое Oracle считывает один блок.
MREADTIM – время чтения группы блоков (мс) - это среднее время,
затраченное на последовательное чтение.
MBRC – счетчик чтения группы блоков – это среднее количество блоков,
считанных во время последовательных чтений группы блоков. В процессе
оптимизации
CBO
использует
параметр
MBRC
вместо
параметра
db_multiblock_read_count запроса, чтобы вычислить стоимость для таблицы и
для быстрого полного сканирования индекса.
MAXTHR – максимальная пропускная способность системы I/O собирается только когда база данных выполняет параллельные запросы.
SLAVETHR - максимальная пропускная способность подчиненных I/O собирается только когда база данных выполняет параллельные запросы.
Большое
преобразований
количество
добавляет
блоков
запроса
сложностей
и
взаимозависимость
стратегии
стоимостного
преобразования. В Oracle Database 10g механизм преобразования стал более
эластичной основой, которая может поддерживать при необходимости новые
алгоритмы, чтобы гарантировать, что Oracle всегда может быстро выбрать
оптимальное преобразование.
Кроме того, базовые преобразования Oracle Database 10g поддерживают
некоторое новое пространство состояний алгоритма поиска, которое
гарантирует, что оптимизатор ищет самый лучший план быстро, даже когда
преобразования достаточно сложны.
Средство оценки измеряет мощность (количество строк), селективность
(количество строк из набора строк, отфильтрованного предикатом) и
стоимость, определяемую как ресурс (дисковый I/O, использование CPU и
объем памяти) различных операций (сканирование таблицы или объединение
таблиц, например), которые выдают данные. Точность этих оценок зависит
от статистики – теперь статистики по объекту и, в Oracle Database 10g,
системной статистики. Специфика SQL-профилей любого запроса также
используется на этом этапе для эффективной оценки стоимости.
Генератор планов рекомбинирует запрос различными способами,
создавая альтернативные планы, используя разные методы соединения и
порядок соединения. Чем больше соединяемых таблиц в исходном запросе,
тем больше порождается альтернативных планов, и тем большее время CBO
тратит на нахождение "лучшего" плана. Напротив, если существует
несколько соединений в отдельном запросе, или соединения расположены в
наилучшем для выполнения порядке, то CBO быстро найдет оптимальный
план.
В конечном счете, CBO выбирает наилучший план – с наименьшей
оцененной стоимостью по отношению к другим планам. Но, строго говоря,
то, как CBO измеряет стоимость вычисления любого SQL-оператора –
стоимостная модель – подвержено влиянию многих факторов, включающих
несколько параметров инициализации (см. Приложение 3), начиная с
optimizer_mode. Параметр optimizer_mode устанавливает общую
задачу производительности для CBO в терминах пропускной способности
(минимальное время возврата всех строк) по отношению к времени отклика
(минимальное время возврата первой строки). (См. Приложение 3).
Другим преимуществом стоимостной модели Oracle Database 10g
является то, что она разрешает CBO использовать другие методы для
создания наиболее быстрого плана - например, путем переупорядочивания
предикатов в запросе. Т.к. CBO знает стоимости, ассоциированные с
заданным запросом с точки зрения CPU, и т.к. основным компонентом в
стоимости предиката является CPU, CBO может рассчитать стоимости
альтернативных порядков предикатов и расставить эти предикаты в наиболее
эффективном порядке.
Например, допустим, что в следующем select-предложении, b < 0
возвращает 1 строку, а a > 0 возвращает все строки таблицы t:
select * from t
where a > 0 and b < 0;
Если предикаты расположены в порядке a > 0 и b < 0, то база данных
будет оценивать b < 0 для каждой строки. Однако, если изменить порядок на
b < 0 и a > 0, то предикат a > 0 будет оценен единожды.
При определении наилучшего порядка алгоритмы упорядочивания
предикатов
учитывают
стоимости
различных
комбинаций
порядка
предикатов и селективности. Эта возможность обеспечивает значительное
улучшение, особенно для неселективных и затратных предикатов.
Заключение
Стоимостной оптимизатор является стратегической подсистемой Oracle
Database. Учитывая, что CBO совершенствуется с каждой новой версией
Oracle Database, желательно учесть побочные эффекты, которые изменения в
CBO могут привнести в приложения на базе данных Oracle. При переносе
существующей системы на Oracle Database 10g необходимо создать
резервную копию всей статистики, которую система использует для
повседневных операций, и протестировать эту статистику на приложениях в
отладочной среде, построенной на новой версии базы данных, перед сдачей в
промышленную эксплуатацию.
Приложение 1. Режим настройки CBO для SQL в Oracle Database 10g
В Oracle Database 10g CBO-оптимизатор имеет два режима - нормальный
режим и режим настройки, который вызывается из SQL Tuning Advisor (и
многими другими Oracle Database 10g советчиками (advisor), такими как SQL
Access Advisor). SQL Tuning Advisor - это новое мощное средство в Oracle
Database 10g для администраторов. В частности, в предыдущих версиях
Oracle если план, созданный оптимизатором, не устраивал разработчика, то
можно было задать подсказку, чтобы повлиять на решение оптимизатора, но
выполнение в лучшем случае занимало слишком много времени. И даже если
найдется время для анализа необходимого для вычисления наилучшего плана
выполнения, то невозможно испытать SQL, сгенерированный пакетными
приложениями (или любым другим приложением), к исходному коду
которого нет доступа.
SQL Tuning
Advisor активизирует режим настройки
CBO для
осуществления более полного анализа (и более длительного, чем в
нормальном режиме, который действует в пределах строгих временных
ограничений) проблематичных запросов, и вырабатывает рекомендации о
том, как достичь самого быстрого доступа к данным. Одним из возможных
результатов этого процесса является генерация SQL-профиля – объекта,
который может быть сохранен в словаре данных (если рекомендация
принята), и который CBO использует (во время выполнения операций, в
нормальном режиме) для пополнения статистики, используемой при
генерации планов.
Режимы стоимостного оптимизатора
Нормальный режим
Режим настройки (Automatic Tuning Optimizer)
Действует внутри строгих
Выполняет дополнительный анализ плана выполнения,
временных ограничений (< 1
созданного нормальным режимом, чтобы определить,
секунды)
может ли план нормального режима быть улучшен
Создает план выполнения
Вырабатывает рекомендации (действия, обоснования,
ожидаемые выгоды), отличные от плана выполнения по
существу
Использует SQL-профиль
Если потребуется, создает SQL-профиль (как часть
для SQL-операторов (если
рекомендации, которую можно принять, в таком случае
таковые доступны)
SQL-профиль сохраняется в словаре данных для
использования CBO в нормальном режиме)
Как таковая, эта новая возможность Oracle Database 10g приносит
огромную пользу администраторам - вместо ожидания патча от поставщика
приложения,
можно
запустить
SQL
Tuning
Advisor,
принять
им
рекомендуемый профиль, чтобы CBO использовал этот профиль во время
выполнения. SQL Tuning Advisor также во многих случаях устраняет
необходимость указания подсказок, поскольку он не только создаст профили,
но и даст актуальные рекомендации, как улучшить код определенных SQLзапросов. Пользуйтесь преимуществами этого нового средства всегда, когда
это возможно.
Режим настройки более общий по отношению к нормальному режиму
CBO. В нормальном режиме CBO действует внутри строгих временных
ограничений, чтобы предоставить альтернативные планы и соответствующие
им стоимости.
Приложение 2. Общие преобразования
Oracle производит множественные преобразования запросов, изменяя и
переписывая запросы в эквивалентные, но более оптимальные формы.
Некоторые
из
этих
преобразований
являются
эвристическими,
или
основанными на правилах, т.е. они базируются на структурных свойствах
запроса, например, на числе таблиц, типах соединений и фильтров, наличии
группирующих
выражений,
-
а
не
на
селективности,
мощности,
распределенности, порядке соединения или относительных стоимостях
различных операций базы данных.
Другие преобразования, такие как перезапись материализованных
представлений, звездное преобразование, или OR-расширение, являются
стоимостными
преобразованиями,
в
которых
запрос
копируется,
преобразовывается и многократно оценивается (и рекурсивно, каждый раз
используя новый набор преобразований) и так до окончания процесса, когда
одно или более преобразование выбирается для применения к начальному
запросу, если оно приводит к оптимальной стоимости. Вот сводка наиболее
общих преобразований:
Эвристические преобразования.
- Select-join
- Select-join-project view слияние (merging)
- Group-by и distinct-view слияние
- Subquery unnesting. (Разбор вложенных подзапросов)
- Filter predicate push-down in a view (Фильтрация предикатов сверху вниз
в представлении)
- Predicate move-around (Перемещение предикатов)
- Common subexpression elimination (Общее исключение подвыражений)
- Join predicate push down (Соединение предикатов сверху вниз)
- Outer to inner join conversion (Преобразование внешнего соединения к
внутреннему)
- Subsumed subquery removal through window function (Удаление
сгруппированного подзапроса через функцию вырезания),
Стоимостные преобразования.
- OR expansion (OR-расширение) преобразует запрос с OR-ами оператора
WHERE в UNION ALL нескольких запросов без OR-ов, который весьма
эффективен, когда операции OR используют ссылочные ограничения на
различные таблицы
- Перезапись материализованных представлений
- Звездное преобразование
- Преобразование набора операторов intersect в join и minus в anti-join
Приложение 3. Параметры инициализации, влияющие на CBO
Параметр optimizer_mode ставит общую задачу производительности для
CBO в терминах пропускной способности по отношению к времени отклика.
В Oracle Database 10g значение по умолчанию (all_rows) заставляет CBO
выбирать лучшую общую производительность - оптимизатор будет выбирать
тот план, который выдает все строки по запросу за наименее возможное
время. С другой стороны, параметр first_rows заставит оптимизатор
обеспечить наименьшее время отклика путем выбора плана, который
наиболее быстро выдает начальное подмножество строк, а остаток строк по
запросу за больший период времени, чем с параметром all_rows.
Параметр
"first_rows_n"
(появившийся
в
Oracle9i
Database)
позволяет сбалансировать возможные несоответствия в этом континууме
(пропускной способности по отношению к времени отклика) более
целенаправленно, позволяя задать число строк равным 1, 10, 100, или 1000. В
Oracle Database 10g, если запрос содержит предикат rownum, CBO
автоматически переключается в режим first_rows_n, извлекая значение n
из предиката rownum.
Другим важным параметром инициализации оптимизатора является
optimizer_dynamic_sampling. Статистика по объектам базы данных
(размер таблиц, индексы, количество строк в таблицах, количество
различных значений в столбцах, процент количества данных таблицы,
меньшее максимального, и т.д.) играет ключевую роль в оценке стоимостей
(см. Приложение 3), и если CBO не может найти актуальной статистики для
работы в течение фазы оценки стоимости обработки оператора, он может,
если этот параметр установлен, в это время динамически подобрать
статистические данные. Уровнем по умолчанию в Oracle Database 10g
является 2, это означает, что CBO будет использовать динамическую
выборку по непроанализированным таблицам для сбора из них необходимой
статистики в ходе оптимизации запроса.
Параметр можно установить в другое значение (3, 4, 5, и так до 10),
чтобы
получить
возможность
динамической
выборки
по
проанализированным таблицам. Динамический отбор уровня 3 делает
возможным вычисление селективности сложных предикатов, селективность
которых имела бы "оценку", а уровня 4 делает возможным комбинированное
вычисление селективности всех предикатов по одной таблице, собирая,
таким образом, корреляции любых данных в их оценке селективности.
Уровень 5 и выше повышает размер образца, таким образом, повышая
точность результата динамической выборки.
Если отключить динамическую выборку (установкой этого параметра в
0), и оптимизатор не имеет доступной статистики во время фазы оценки, то
он будет использовать значения по умолчанию для оценки строк и других
объектов, которые ему требуется получить.
db_multiblock_read_count – Оптимизатор использует mbrc (одно
из
значений
системной
db_multiblock_read_count
вычисления
стоимости
статистики)
во
сканирования
время
вместо
компиляции
таблицы
и
параметра
запроса
быстрого
для
полного
сканирования индекса. В Oracle Database 10g, значение по умолчанию этого
параметра равняется 8 (что эквивалентно размеру I/O, кратному 8 * размерстандартного-блока). Однако размер I/O по умолчанию, требующийся для
выполнения запроса, определяется автоматически на уровне I/O, и
устанавливается соответственно для конфигурации системы, полагаясь на
объем системной статистики для точного значения объема многоблочного
чтения.
Параметры оптимизатора из v$sys_optimizer_env для различных
версий.
Параметры, относящиеся к оптимизатору, могут быть установлены на
уровне сессии или изменены для одиночного SQL-выражения с помощью
подсказок оптимизатора.
optimizer_features_enable
cursor_sharing
db_file_multiblock_read_count
optimizer_dynamic_sampling
optimizer_index_caching
optimizer_index_cost_adj
optimizer_mode
parallel_ddl_mode
parallel_dml_mode
parallel_execution_enabled
parallel_query_mode
parallel_threads_per_cpu
pga_aggregate_ targe
query_rewrite_enabled
query_rewrite_integrity
Skip_unusable_indexes
sort_area_retained_size
sort_area_size
star_transformation_enabled
statistics_level
workarea_size_policy
10.1.0
exact
8
2
0
100
all_rows
enabled
disabled
TRUE
enabled
2
24576 KB
TRUE
enforced
TRUE
0
65536
FALSE
typical
auto
9.2.0
exact
8
1
0
100
choose
enabled
disabled
TRUE
enabled
2
24576 KB
FALSE
enforced
FALSE
0
65536
FALSE
all
auto
9.0.1
exact
16
na
0
100
choose
enabled
disabled
TRUE
enabled
2
24576 KB
FALSE
enforced
FALSE
0
65536
FALSE
all
auto
8.1.7
exact
16
na
0
100
choose
enabled
disabled
TRUE
enabled
2
24576 KB
FALSE
enforced
FALSE
0
65536
FALSE
all
auto
Источники:
1.
Официальный сервер Oracle,
http://www.oracle.com
2.
Журнал Oracle Magazine,
http://www.oracle.com/technology/oramag/oracle/05-jan/o15tech_tuning.html
3.
Журнал Oracle Magazine,
http://www.oracle.com/technology/oramag/webcolumns/2003/techarticles/burleson_cbo_pt1.htm
l