наковое количество строк, серверу требуется найти только конечные точки диапазонов значений для каждого сегмента. В нашем примере с 20 сегментами в первом сегменте может храниться диапазон от СА до СА, а во втором - диапазон от СА до CL. В следующих 17 сегментах может храниться наиболее часто встречающееся значение - диапазон от CL до CL. В последнем сегменте будет храниться диапазон от CL до ОР, то есть диапазон, включающий самое редкое значение. Таким образом, Oracle может сделать вывод, что селективность столбца равна 5-10 % для значения СА, 85-95 % для значения CL и 0-5 % для значения ОР. Так как необходимо, чтобы оптимизатор точно знал, насколько селективно значение ОР, стоит выбрать большее количество сегментов - возможно, максимальное, равное 254. (Oracle сжимает информацию в сегменте, когда рассматривается небольшое количество значений, поэтому стоимость большого количества сегментов будет небольшой.) Чтобы создать 254 сегмента для нашего примера, в схеме, владельцем которой является Appl Prod, выполните следующую команду: BEGIN

DBMSJTATS. GATHER TABLE STATS ( AppI Prod . Orders, METHOD DPT => TOR COLUMNS SIZE 254 Stetus Code):

END; /

После того как вы создадите статистику по основной таблице, сгенерируйте гистограмму статистики, так как при создании статистики по таблице гистограмма удаляется.

Общий синтаксис подсказок

В Oracle подсказки используются для ручного управления стоимостной оптимизацией. Синтаксически эти подсказки принимают форму комментариев, как, например, /*+ <Hint String> */, стоящих сразу же за ключевым словом SELECT. Oracle распознает, что это подсказка, а не комментарий, за счет знака + в начале и расположения подсказки - она обязана располагаться сразу же за словом SELECT. Но с точки зрения стандартного синтаксиса SQL подсказки все же являются комментариями, так как они не мешают разбору SQL-выражения, если оно также должно выполняться другими серверами баз данных.

ПРИМЕЧАНИЕ

Подсказки Oracle не помогают 1юлучить быстрые планы выполнения в других базах данных, отличных от Oracle, и, к сожалению, в данный момент невозможно использовать настроенный вручную SQL-запрос в разнообразных базах данных и во всех них проводить одинаковую ручную настройку.

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

Подходы к настройке с использованием подсказок

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

Можно использовать минимум указаний для получения желаемого плана выполнения или, по меньшей мере, плана, близкого к идеальному. Аргументы в

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

Если вы не получили от СВ О желаемый план автоматически, то предполагаете, что СВО сделал неверные предположения, которые распространяются на весь код и портят все его вычисления. Следовательно, нужно оставить ему минимальную свободу действий, явно и полностью указывая, какой именно план вам нужен.

Если вы уверены в выбранном плане вьтолнения (а вы должны быть уверены, если применили все методы, которые я опишу далее в этой книге), то не имеет смысла полностью явно указывать план. Я пока что не сталкивался со случаем, когда хорошо выбранный надежный план вьшолнения требуется изменить, чтобы обработать данные с новым распределением или использовать новые возможности базы данных. С другой стороны, SQL, частично ограниченный набором подсказок, может выполняться неправильно, особенно если для некоторых таблиц или индексов статистика утеряна. Когда СВО делает неправильный выбор, ошибка, которая заставила сделать его этот выбор, вероятнее всего, портит весь план выполнения. Например, рассмотрим запрос:

SELECT £.First Name, £.Lastjame. E.Salary. LE. Descri pti on.

M. First Jame, M. Last Jame. LM. Description FROM Locations LM, Employees M, Locations LE. Employees E WHERE E.Hi re Date > :1

AND E.Manager ID-M.Employee ID

AND E.Location ID-LE.Lccation ID

AND M.Location ID-LM.Location ID

Bo время разбора, когда работает оптимизатор, он не может знать, что параметру : 1, вероятно, будет назначено значение, соответствующее текущей неделе, поэтому он делает благоприятное предположение о селективности этого условия в Hi re Date. Сделав такое предположение, он может не только запретить использование индекса по Hi re Date (в зависимости от распределения данных), но таюке посчитать, что запросу понадобятся практически все строки из всех соединенных таблиц, и тогда СВО выберет полное сканирование таблиц с соединением хэшированием. Даже если вы заставите СВО использовать индекс по Hi re Date, он все равно будет считать, что ведущее условие неселективно, и придерживаться своего неудачного выбора для других соединений и методов доступа к таблицам. В действительности это не является ошибкой оптимизатора. Он не может знать того, что знает разработчик приложения о вероятных значениях связанной переменной. И, как следствие, если вам необходимо принимать в создании плана большее участие, чем просто указать ALL ROWS или FIRST ROWS, велика вероятность того, что ваша помощь потребуется оптимизатору на всем протяжении его работы, чтобы исправить некоторые неверные предположения.

ПРИМЕЧАНИЕ

Подсказки ALL ROWS и FIRST ROWS представляют собой безопасный способ первичной оптимизации. Если вы используете синтаксический оптимизатор, то вполне можете опробовать этот стоимостный подход, указав подсказку еще до того, как начнете искать наилучший план выполнения. Если результат окажется достаточно быстрым, то вы сможете сэкономить усилия. Если же вы уже используете стоимостную оптимизацию в режиме ALL ROWS, то попробуйте FIRST ROWS и наоборот. Если вашу проблему может решить подсказка optimi2er mode, значит, оптимизатор делает правильные пред1Юложения и ему можно доверять.

Подсказки для доступа к таблицам

Далее перечислены основные подсказки, управляющие методами доступа к таблицам.

Ш0ЕХ(<Имя псевйОнимд> <Имя индекса>). Требует от Oracle, когда это возможно, осуществлять доступ к псевдониму <Имя псевдонима>, используя индекс с именем <Иня инденса>. Повторяйте эту подсказку для всех комбинаций индекса и псевдонима, которые необходимо контролировать.

FULL (<Мт псевдонта>). Рекомендует серверу, когда это возможно, осуществлять доступ к псевдониму <Имя псевдонима>, используя полное сканирование таблицы. Используйте эту подсказку для всех необходимых операций полного сканирования таблицы.

ШE){JlESC<Имя пceвдoнимa> <Имя инденса>). Рекомендует Oracle, когда возможно, осуществлять доступ к псевдониму <мя псевдонима>, используя индекс с именем <Имя индекса>, обращаясь к строкам в обратном порядке (обратном по отношению к обычному порядку сортировки индекса). Повторяйте эту подсказку для всех комбинаций индекса и псевдонима, которые необходимо контролировать, хотя маловероятно, что это потребуется больше одного раза в запросе.

Подсказки INDEX и FULL достаточно распространены, и их легко использовать. Подсказка INDEX DESC редко бывает полезной, но иногда она жизненно необходима. Например, если вы хотите получить все сведения о сотруднике, нанятом в апреле последним, можно использовать такой запрос: SELECT *

FROM Employees Е

WHERE Hire Date>=TO DATE(-гООЗ-ОД-ОГ.YYVY-MM-DD) AND Hire Date< TO DATEC2003-05-01- VYYV-MM-DD) ORDER BY Hire Date DESC

Сотрудник, нанятый последним, будет перечислен в начале набора строк, возвращенных запросом. Чтобы избежать считывания всех данных для всех остальных сотрудников, нанятых в апреле, вы можете добавить в запрос условие AND R0WNUM=1. Но иногда в таком случае вы получите нежелательный результат, так как (в зависимости от данных) Oracle будет применять это условие до вьшолнения сортировки по убыванию. Если Oracle проводит полное сканирование таблицы, запрос вернет первого сотрудника, нанятого в апреле, которого найдет в таблице, и, вероятно, это будет сотрудник, нанятый первым по времени. Если же Oracle использует сканирование диапазона индекса по Hi re Date, то начнет, как это происходит с диапазонами по умолчанию, с нижнего края диапазона индекса и вернет первого сотрудника, нанятого в апреле. Однако подсказка INDEXDESC и индекс