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

 

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

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

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


SQL-запрос обращается к таблицам с разбиениями.

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

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

НЕНАМЕРЕННОЕ ОТКЛЮЧЕНИЕ RBO -----------------------------------------------------------------------

Я много раз встречал такой сценарий: у вас есть стабильное промышленное приложение, хорошо работающее с RBO, и вдруг большие фрагменты приложения начинают работать со скоростью черепахи. Тут же возникает паника и начинается проверка «методом тыка». После длительного расследования выясняется, что прошлой ночью администратор базы данных (database administrator, DBA) случайно удалил и создал заново некоторый большой индекс по центральной таблице, возможно, переместив его в новую файловую систему, чтобы освободить больше места. Ваш DBA прозорливо решил, что это был такой большой индекс, что создание его заново старым способом займет недопустимо много времени, поэтому он создал его параллельно, используя подобную конструкцию:

CREATE INDEX Order_Ship_Date ON Orders(Ship_Date)

PARALLEL 10;

Благодаря этому десять параллельных процессов занялись созданием индекса и существенно его ускорили, в то же время оставив время для обычной работы. Пока что все хорошо. Ho о чем никто не догадался, так это о том, что у индекса образовалось свойство, заставляющее Oracle использовать стоимостную оптимизацию независимо от конфигурации базы данных и пытаться во всем SQL-коде, в котором упоминается эта таблица, найти планы, использующие этот индекс в параллельных процессах. Так как никто не ожидал, что к этому приложению будет применен СВО, то никто не создал статистику по таблицам и индексам. Поэтому CBO работал без учета правильной статистики и неожиданно выдал ужасные с точки зрения производительности планы для большей части SQL-кода, использующего эту таблицу. Обнаружив причину, проблему можно решить такой командой:

ALTER INDEX Order_Ship_Date PARALLEL 1;

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

SELECT Index_Name FROH ALL_INDEXES WHERE Deg гее!=1:

Если таблицы и индексы, встречающиеся в вашем SQL-запросе, не запрещают

использовать RBO, Oracle делает выбор между RBO и CBO Iia основе следующих

аргументов в порядке использования.

1. Если после любого ключевого слова SELECT в SQL-запросе (даже в подзапросе или определении представления) присутствует любая допустимая инструкция кроме /*+ RULE */ или /*+ CHOOSE */, Oracle выбирает СВО.

2. Если после любого ключевого слова SELECT в SQL-запросе (даже в подзапросе или определении представления) присутствует /*+ CHOOSE */ и для любой таблицы или индекса, упоминающихся в запросе, не существует статистики, Oracle выбирает СВО.

3. Если после любого ключевого слова SELECT в SQL (даже в подзапросе или определении представления) присутствует /*+ RULE */, Oracle выбирает RBO.

4. Если параметр сеанса opt і mi zer_mode устанавливается на уровне сеанса (при помощи ALTER SESSION SET OPTIMIZERJ^0DE=<Ba///_eb/6op>;), Oracle выбирает RBO или CBO согласно значению этого параметра уровня сеанса.

5. Если параметр optimizerjnode устанавливается для экземпляра базы данных в файле init.ora, Oracle выбирает RBO или CBO согласно значению этого параметра уровня экземпляра.

6. В ином случае Oracle выбирает оптимизатор согласно значению по умолчанию параметра optimizerjnode, то есть CHOOSE.
Управление планами в Oracle

111

В трех последних шагах последовательности решений Oracle делает выбор на основе значения параметра optimizerjnode, которое устанавливаете вы или администратор вашей базы данных. Допустимы четыре возможных значения параметра, которые влияют на выбор следующим образом.

¦ RULE. Oracle использует синтаксическую оптимизацию.

¦ ALL ROWS. Oracle использует стоимостную оптимизацию с целью минимизировать стоимость всего запроса. Этот режим по умолчанию стоимостной оптимизации иногда выдает ненадежные планы (планы, в которых используются методы соединения, отличные от вложенных циклов) со всеми рисками, описанными в главе 6. Однако оптимизатор выбирает эти планы только если считает, что они выполняются быстрее, чем наилучшие надежные планы.

¦ FIRST_ROWS. Oracle использует стоимостную оптимизацию с целью минимизировать стоимость получения первых строк из запроса. На практике обычно выбираются надежные планы со вложенными циклами, схожие с теми, которые выбирает синтаксический оптимизатор. Ho в данном случае при построении планов учитывается больше информации о распределении данных и возможной стоимости выполнения. Уровень оптимизации FIRST_ROWS создает тот же эффект, что и подсказка OPTIMIZE FOR I ROW в DB2 и подсказка OPTIONtFAST 1) в SQL Server.
Предыдущая << 1 .. 49 50 51 52 53 54 < 55 > 56 57 58 59 60 61 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100