Как использовать кластеры
При выборе таблиц для кластеризации руководствуйтесь следующими правилами:
Кластеризуйте таблицы, которые часто опрашиваются вашими приложениями в операциях соединения.
Не кластеризуйте таблицы, если ваше приложение соединяет их не часто, или часто модифицирует значения их общих столбцов. Модификация ключа кластера
в строке таблицы требует больше времени, чем такая же модификация в некластеризованной таблице, потому что ORACLE может оказаться вынужденным перенести
модифицированную строку в другой блок, чтобы поддержать кластер.
Не кластеризуйте таблиц, если ваше приложение часто выполняет по ним полные просмотры. Полный просмотр кластеризованной таблицы может потребовать больше
времени, чем полный просмотр некластеризованной таблицы. Кластеризованная таблица занимает большее количество блоков, так как она разделяет их с другими
таблицами.
Кластеризуйте главную и подчиненную таблицы, если вы часто выбираете главную запись, а затем соответстввующие ей детальные записи. Поскольку в кластере
детальные записи хранятся в одних и тех же блоках данных с главными записями, они, скорее всего, уже находятся в памяти, когда вы выбираете их, и ORACLE
должен выполнять меньше ввода-вывода.
Кластеризуйте одну подчиненную таблицу, если вы часто выбираете много детальных записей для одной и той же главной записи. Эта мера улучшает производительность
запросов, выбирающих детальные записи для заданной главной записи, и в то же время не снижает производительности полных просмотров по главной таблице.
Не кластеризуйте таблиц, если совокупность данных из всех таблиц с одинаковым значением ключа кластера превышает один или два блока ORACLE. При обращении
к строке кластеризованной таблицы ORACLE считывает все блоки, содержащие строки с этим значением ключа. Если эти строки занимают несколько блоков, то
доступ к одиночной строке потребует больше операций чтения, чем доступ к той же самой строке в некластеризованной таблице.
Рассмотрите достоинства и недостатки кластеров по отношению к потребностям вашего приложения. Например, вы можете решить, что выигрыш в производительности
для операций соединения перевешивает потери в производительности для тех предложений, которые модифицируют значения ключа кластера. Вы можете поэкспериментировать
и сравнить время обработки для ваших таблиц как с кластером, так и без него. Для создания кластера используйте команду CREATE CLUSTER. Для дополнительной
информации о создании кластеров обратитесь к главе 2 "Управление объектами схемы" этого руководства.
Как использовать хэширование
При выборе таблиц для хэширования руководствуйтесь следующими правилами:
Используйте хэш-кластеры для таблиц, доступ к которым часто осуществляется предложениями SQL, фразы WHERE в которых используют условия равенства по
одному и тому же столбцу или комбинации столбцов. Назначьте этот столбец или комбинацию столбцов ключом кластера.
Храните таблицу в хэш-кластере, если вы можете определить, сколько памяти требуется на все строки с данным значением ключа кластера, учитывая все строки,
которые могут быть добавлены в таблицу в будущем.
Не используйте хэш-кластеров, если память в вашей базе данных дефицитна, и вы не можете позволить себе распределить дополнительную память для тех строк,
которые будут вставлены в будущем.
Не используйте хэш-кластер для размещения постоянно растущей таблицы, если для вас непрактично периодически создавать новый хэш-кластер большего размера
под эту таблицу.
Не храните таблицу в хэш-кластере, если ваше приложение часто использует полные просмотры этой таблицы, и вы чувствуете, что вам придется распределить
порядочное количество лишней памяти для хэш-кластера в предвидении существенного роста таблицы в будущем. Полные просмотры таблицы должны считывать все
блоки, распределенные хэш-кластеру, даже если некоторые блоки содержат мало строк. Размещение таблицы вне кластера сокращает число блоков, считываемых
при полном просмотре таблицы.
Не храните таблицу в хэш-кластере, если ваше приложение часто модифицирует значения ключа кластера. Модификация ключа кластера в строке таблицы требует
больше времени, чем такая же модификация в некластеризованной таблице, потому что ORACLE может оказаться вынужденным перенести модифицированную строку
в другой блок, чтобы поддержать кластер.
Размещение одиночной таблицы в хэш-кластере может быть полезным, независимо от того, часто ли эта таблица используется в операциях соединения с другими
таблицами, при условии, что предыдущие условия в этом перечне показывают приемлемость хэширования для данной таблицы.
Рассмотрите достоинства и недостатки хэш-кластеров по отношению к потребностям вашего приложения. Вы можете поэкспериментировать и сравнить время
обработки для ваших таблиц как с хэш-кластером, так и без него (с индексом). Для создания хэш-кластера используйте команду CREATE CLUSTER с параметрами
HASH и HASHKEYS. Для дополнительной информации о создании хэш-кластеров обратитесь к главе 2 "Управление объектами схемы" этого руководства.
Как определить количество хэш-значений
При создании хэш-кластера вы должны использовать параметр HASHKEYS предложения CREATE CLUSTER, чтобы указать количество хэш-значений для этого хэш-кластера.
Для лучшей производительности хэш-просмотров выбирайте значение HASHKEYS не меньше, чем количество значений ключа кластера. Такое значение уменьшит
число КОЛЛИЗИЙ, т.е. случаев, когда разные значения ключа кластера дают одно и то же хэш-значение. Коллизии заставляют ORACLE после выполнения хэш-просмотра
проверять строки в каждом блоке, отыскивая нужное значение ключа кластера. Поэтому коллизии снижают производительность хэш-просмотров.
ORACLE всегда округляет заданное вами значение HASHKEYS вверх до ближайшего простого числа, чтобы вычислить действительное количество хэш-значений.
Это округление имеет целью сокращение числа коллизий.
Как выбирать подход оптимизации
Эта секция обсуждает следующие вопросы:
когда использовать стоимостной подход
как выбирать цель для стоимостного подхода
когда и как генерировать статистики для стоимостного подхода
когда использовать регулярный подход
Когда использовать стоимостной подход
В общем, вы должны использовать стоимостной подход для всех ваших новых приложений. Стоимостной подход обычно выбирает план исполнения, который как
минимум не хуже плана исполнения, выбираемого регулярным подходом, особенно для больших запросов с множественными соединениями или множественными индексами.
Стоимостной подход также улучшает продуктивность разработки, устраняя необходимость вам самим настраивать ваши предложения SQL.
Чтобы задействовать стоимостной подход для предложения, соберите статистики для таблиц, адресуемых этим предложением, и убедитесь, что параметр инициализации
OPTIMIZER_MODE имеет свое умалчиваемое значение COST.
Вы можете также задействовать стоимостной подход следующими способами:
тобы включить стоимостную оптимизацию для вашей сессии, выдайте команду ALTER SESSION со значением параметра OPTIMIZER_GOAL, равным ALL_ROWS или FIRST_ROWS.
тобы включить стоимостную оптимизацию для индивидуального предложения SQL, используйте совет ALL_ROWS или FIRST_ROWS. Для информации о советах обратитесь
к секции "Как использовать советы"
Генерация статистик
Поскольку стоимостной подход опирается на статистики, вы должны сгенерировать статистики для всех таблиц, кластеров и индексов, адресуемых в ваших
предложениях SQL, прежде чем сможете применять стоимостной подход. Если размеры и распределение данных в ваших таблицах часто изменяются, вы должны
генерировать эти статистики регулярно, чтобы гарантировать, что они точно отражают данные в таблицах.
ORACLE может генерировать статистики двумя способами:
путем оценки, основанной на произвольной выборке данных
путем точного вычисления
Используйте, как правило, оценку вместо точного вычисления, если у вас нет оснований полагать, что вам требуются точные значения:
Вычисление всегда обеспечивает точные значения, но может потребовать большего времени. Время, требуемое для вычисления статистик по таблице, сравнимо
с временем выполнения полного просмотра этой таблицы.
Оценивание зачастую намного быстрее, чем вычисление, особенно для больших таблиц, потому что при оценивании
никогда не считывается больше 1064 строк таблицы. Результаты, как правило, близки к точным.
Сбор статистик по таблице блокирует эту таблицу и препятствует доступу к ней предложений SELECT, INSERT,
UPDATE и DELETE. По этой причине, оценивание особенно полезно при сборе статистик по таблицам, к которым
одновременно обращаются другие приложения, потому что при этом минимизируется время недоступности этих
таблиц. По той же причине, не собирайте статистик по вашей производственной базе данных во время периодов
высокой активности.
Когда вы генерируете статистики для таблицы, столбца или индекса, ORACLE заменяет существующие статистики
по этому объекту, если они уже есть в словаре данных, новыми статистиками. ORACLE помечает как недействительные
все ранее разобранные предложения SQL, которые обращаются к любому из анализируемых объектов. При очередном
исполнении такого предложения оптимизатор автоматически выберет новый план исполнения, базирующийся на
новых статистиках. Распределенные предложения, выданные на удаленных базах данных, которые обращаются
к анализируемым объектам, будут использовать новые статистики при очередном разборе.
Некоторые статистики всегда вычисляются, независимо от того, выбрали ли вы оценку или точное вычисление.
Если вы выбрали оценку, но время, которое экономится за счет выборки, незначительно, то ORACLE выбирает
вычисление.
Чтобы сгенерировать статистики, используйте команду ANALYZE.
Пример Следующий пример генерирует статистики для таблицы EMP и ее индексов:
ANALYZE TABLE emp
ESTIMATE STATISTICS
Выбор цели для стоимостного подхода
План исполнения, выбираемый оптимизатором, может изменяться в зависимости от цели оптимизатора. Оптимизация
для лучшей пропускной способности, т.е. для минимизации времени на возвращение всех строк, обрабатываемых
предложением, с большей вероятностью приведет к полному просмотру таблицы, чем к просмотру индекса, и
к соединению через сортировку-слияние, нежели к соединению через вложенные циклы. Оптимизация для лучшего
времени ответа, т.е. минимизация времени на возвращение первой строки, обрабатываемой предложением, с
большей вореятностью приведет к доступу через индекс и соединению через вложенные циклы. Например, рассмотрим
предложение соединения, которое может быть выполнено либо операцией вложенных циклов, либо операцией сортировки-слияния.
Операция сортировки-слияния быстрее возвратит весь результат запроса, тогда как операция вложенных циклов
может быстрее возвратить первую строку. Поэтому, если целью является лучшая пропускная способность, оптимизатор
скорее выберет соединение через сортировку-слияние; и наоборот, если целью является лучшее время ответа,
оптимизатор предпочтет соединение через вложенные циклы.
Выберите цель для оптимизатора, базируясь на потребностях вашего приложения:
Для приложений, выполняемых в пакетном режиме, таких как отчеты SQL*ReportWriter, оптимизируйте для лучшей пропускной способности. Пропускная способность
обычно более важна в пакетных заданиях, потому что пользователь, инициировавший это задание, заинтересован лишь в том, чтобы скорее закончить все приложение.
Время ответа здесь менее важно, так как пользователь не анализирует результатов индивидуальных предложений, пока приложение не закончило работу.
Для интерактивных приложений, таких как приложения SQL*Forms или запросы SQL*Plus, оптимизируйте для лучшего времени ответа. Время ответа в интерактивных
приложениях обычно важно, потому что интерактивный пользователь ждет появления первой строки, возвращаемой предложением.
По умолчанию, стоимостной подход оптимизирует для лучшей пропускной способности. Вы можете изменить цель стоимостного подхода следующими способами:
тобы изменить цель стоимостного подхода для всех предложений SQL в вашей сессии, выдайте команду ALTER SESSION с параметром OPTIMIZER_GOAL.
тобы специфицировать цель стоимостного подхода для индивидуального предложения SQL, используйте совет
ALL_ROWS или FIRST_ROWS. Для информации о советах обратитесь к секции "Как использовать советы" на странице
5-14.
Пример
Следующее предложение изменяет цель стоимостного подхода для вашей сессии на лучшее время ответа:
ALTER SESSION
SET OPTIMIZER_GOAL = FIRST_ROWS
Когда использовать регулярную оптимизацию
Если вы разрабатывали приложения, используя предыдущую версию ORACLE, и проводили тщательную настройку
ваших предложений SQL, основываясь на правилах оптимизатора, то вы можете захотеть продолжать использование
регулярной оптимизации и после перевода этих приложений на ORACLE7. Если вы не собирали статистику и не
добавляли советов в ваши предложения SQL, то эти предложения будут продолжать использовать регулярную
оптимизацию. Однако в конце концов вы должны перевести ваши существующие приложения на стоимостной подход,
потому что регулярный подход не будет поддерживаться в будущих версиях ORACLE.
Вы можете попробовать стоимостной подход на ваших приложениях, просто собрав статистики. После этого
вы можете вернуться к регулярной оптимизации, просто удалив эти статистики, либо установив значение параметра
инициализации OPTIMIZER_MODE (или параметра OPTIMIZER_GOAL команды ALTER SESSION) в RULE. Вы можете также
использовать это значение, если хотите просто собрать и исследовать статистики по вашим данным, не переходя
на применение стоимостного подхода.
Как использовать советы
Как разработчик приложения, вы можете иметь о ваших данных такую информацию, которая неизвестна оптимизатору.
Например, вы можете знать, что некоторый индекс более селективен для тех или иных запросов, чем это может
определить оптимизатор. Базируясь на этой информации, вы можете быть способны выбирать более эффективные
планы исполнения, чем это может сделать оптимизатор. В таком случае, вы можете использовать советы, чтобы
заставить оптимизатор использовать тот план исполнения, который выбран вами.
СОВЕТЫ - это подсказки, которые вы даете оптимизатору для конкретного предложения SQL. Советы позволяют
вам принимать те решения, которые обычно принимаются оптимизатором. Вы можете использовать советы, чтобы
специфицировать:
подход к оптимизации для предложения SQL
цель стоимостного подхода для предложения SQL
путь доступа для таблицы, адресуемой предложением
порядок соединения для предложения соединения
операцию соединения для предложения соединения
Совет применяется к оптимизации лишь того блока предложения, в котором он появляется. БЛОК ПРЕДЛОЖЕНИЯ - это одно из следующих предложений или частей
предложений:
простое предложение SELECT, UPDATE или DELETE
родительское предложение или подзапрос сложного предложения
часть составного запроса
Например, составной запрос, состоящий из двух составляющих запросов, объединенных оператором UNION, имеет два блока предложения, по одному для каждого
составляющего запроса. Поэтому советы в первой компоненте такого запроса применяются только к оптимизации первого составляющего запроса, и не применяются
к оптимизации второго составляющего запроса.
Вы можете посылать советы оптимизатору для предложения SQL, оформляя их как комментарии внутри предложения. Для дополнительной информации о комментариях
обратитесь к главе 2 "Элементы SQL" документа ORACLE7 Server SQL Language Reference Manual.
Блок предложения может иметь лишь один комментарий, содержащий советы. Этот комментарий может следовать только за ключевым словом SELECT, UPDATE или
DELETE. Следующие синтаксические диаграммы показывают синтаксис советов для обоих типов комментариев, которые ORACLE поддерживает в блоке предложения:
где:
- DELETE, SELECT или UPDATE - ключевое слово DELETE, SELECT, которое начинает блок предложения. Комментарии, UPDATE содержащие советы оптимизатору,
могут появляться только за этими ключевыми словами.
- знак "плюс", который заставляет ORACLE интерпретировать данный комментарий как список советов. Знак "плюс" должен следовать непосредственно за
разделителем комментария (без разделяющего их пробела).
- совет один из советов, обсуждаемых ниже в этой секции. Если комментарий содержит несколько советов, между каждой парой советов должен стоять хотя
бы один пробел.
- текст любой комментирующий текст, которым могут перемежаться советы.
Если вы специфицируете советы некорректно, ORACLE игнорирует их, но не возвращает ошибку:
ORACLE игнорирует советы, если содержащий их комментарий не следует непосредственно за ключевым словом SELECT, UPDATE или DELETE.
ORACLE игнорирует советы, содержащие синтаксические ошибки, но принимает остальные корректно заданные советы внутри того же самого комментария.
ORACLE игнорирует комбинации противоречащих друг другу советов, но принимает остальные советы внутри
того же самого комментария.
ORACLE также игнорирует любые советы в предложениях SQL в окружениях, использующих PL/SQL версии 1,
например, в триггерах SQL*Forms версии 3.
Оптимизатор распознает советы лишь тогда, когда используется стоимостной подход. И обратно, если вы
включите в блок предложения любой совет (за исключением совета RULE), то оптимизатор автоматически использует
стоимостной подход.
предыдущая часть | содержание
| следующая часть
Дополнительную информацию Вы можете получить в компании Interface Ltd.
Обсудить на форуме Oracle
Отправить ссылку
на страницу по e-mail