СТАТЬЯ
27.06.01

предыдущая часть | содержание | следующая часть

Следующие секции показывают синтаксис каждого совета.

Советы для оптимизации подходов и целей

Советы, описанные в этой секции, позволяют вам выбирать между стоимостным и регулярным подходами к оптимизации, а также, при стоимостном подходе, между целями лучшей пропускной способности и лучшего времени ответа. Если предложение SQL содержит совет, специфицирующий подход и цель оптимизации, то оптимизатор будет использовать предписанный этим советом подход, независимо от наличия или отсутствия статистики, значения параметра инициализации OPTIMIZER_MODE и значения параметра OPTIMIZER_GOAL команды ALTER SESSION.

ALL_ROWS

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

SELECT /*+ ALL_ROWS */ empno, ename, sal, job
    FROM emp
    WHERE empno = 7566

FIRST_ROWS

Совет FIRST_ROWS явно выбирает стоимостной подход для оптимизации блока предложения с целью лучшего времени ответа. Этот совет заставляет оптимизатор принять следующие решения:

Например, для следующего предложения будет выбран стоимостной подход с целью лучшего времени ответа:

SELECT /*+ FIRST_ROWS */ empno, ename, sal, job
    FROM emp
    WHERE empno = 7566

Оптимизатор игнорирует этот совет в блоках предложений DELETE и UPDATE, а также в тех блоках предложения SELECT, которые содержат любой из следующих синтаксических конструктов:

Такие предложения не могут быть оптимизированы для лучшего времени ответа, потому что ORACLE должен извлечь все строки, затрагиваемые предложением, прежде чем сможет возвратить первую строку. Если вы специфицируете этот совет для одного из перечисленных предложений, то оптимизатор будет использовать стоимостной подход, но оптимизирует для лучшей пропускной способности.

Если вы специфицируете совет ALL_ROWS или FIRST_ROWS в предложении SQL, но словарь данных не содержит никаких статистик для таблиц, адресуемых этим предложением, то оптимизатор использует умалчиваемые статистические характеристики, такие как объем памяти, распределенной этим таблицам, чтобы оценить отсутствующие статистики и выбрать план исполнения. Поскольку такие оценки не столь точны, как статистики, генерируемые командой ANALYZE, вы должны выполнить команду ANALYZE, чтобы собрать статистики для всех таблиц, затрагиваемых всеми вашими предложениями, которые используют стоимостную оптимизацию.

Если вы одновременно с советом ALL_ROWS или FIRST_ROWS специфицируете советы для путей доступа или операций соединения, то оптимизатор игнорирует совет ALL_ROWS или FIRST_ROWS, и использует стоимостной подход и те пути доступа и операции соединения, которые специфицированы советами.

RULE

Совет RULE явно выбирает регулярный подход для оптимизации блока предложения. Этот совет также заставляет оптимизатор игнорировать любые другие советы, которые специфицированы для этого блока предложения. Например, для следующего предложения будет выбран регулярный подход:

SELECT                      --+ RULE
    empno, ename, sal, job
    FROM emp
    WHERE empno = 7566

Совет RULE, так же, как и регулярный подход, не будет доступен в будущих версиях ORACLE.

Советы для методов доступа

Каждый из советов, описанных в этой секции, предлагает метод доступа для таблицы. Задание одного из этих советов заставляет оптимизатор выбрать предписанный путь доступа, при условии, что этот путь доступа возможен благодаря существованию индекса или кластера и синтаксическим конструктам предложения SQL. Для обсуждения методов доступа, а также синтаксических конструктов и соответствующих путей доступа, обратитесь к главе 13 "Оптимизатор" документа ORACLE7 Server Concepts Manual. Если совет специфицирует недоступный путь доступа, то оптимизатор игнорирует этот совет.

Вы должны специфицировать в совете имя таблицы точно так же, как оно появляется в предложении. Если предложение использует алиас для таблицы, то вы должны указывать в совете алиас вместо имени таблицы. Имя или алиас должно представлять таблицу или синоним таблицы в вашей локальной базе данных.

FULL

Совет FULL явно выбирает полный просмотр таблицы для указанной таблицы. Синтаксис этого совета имеет следующий вид:

FULL(таблица)

где "таблица" специфицирует имя или алиас таблицы, по которой должен быть выполнен полный просмотр.

Например, для следующего предложения ORACLE выполняет полный просмотр по таблице ACCOUNTS, даже если существует индекс по столбцу ACCNO, путь по которому доступен благодаря условию в фразе WHERE:

SELECT /*+ FULL(a) Don't use index on ACCNO */ accno, bal
    FROM accounts a
    WHERE accno = 7086854

Заметьте, что, поскольку таблица ACCOUNTS имеет алиас A, совет должен ссылаться на эту таблицу по алиасу, а не по имени.

ROWID

Совет ROWID явно выбирает просмотр таблицы по ROWID для указанной таблицы. Синтаксис этого совета имеет следующий вид:

ROWID(таблица)

где "таблица" специфицирует имя или алиас таблицы, по которой должен быть выполнен просмотр по ROWID.

CLUSTER

Совет CLUSTER явно выбирает просмотр кластера для доступа к указанной таблице. Синтаксис этого совета имеет следующий вид:

CLUSTER(таблица)

где "таблица" специфицирует имя или алиас таблицы, по которой должен быть выполнен просмотр кластера.

HASH

Совет HASH явно выбирает хэш-просмотр для доступа к указанной таблице. Синтаксис этого совета имеет следующий вид:

HASH(таблица)

где "таблица" специфицирует имя или алиас таблицы, по которой должен быть выполнен хэш-просмотр.

INDEX

Совет INDEX явно выбирает просмотр индекса для доступа к указанной таблице. Синтаксис этого совета имеет следующий вид:

где:

Этот совет может специфицировать ни одного, один или несколько индексов:

Например, рассмотрим следующий запрос, который выбирает имя, рост и вес для каждого пациента мужского пола в больнице:

SELECT name, height, weight
    FROM patients
    WHERE sex = 'M'

Предположим, что столбец SEX содержит значения M и F, и что по этому столбцу существует индекс. Если в больнице примерно поровну пациентов мужского и женского пола, то этот запрос возвратит относительно большой процент строк таблицы, и полный просмотр таблицы, вероятно, был бы быстрее, чем просмотр индекса. Однако, если доля пациентов мужского пола в больнице очень мала, то этот запрос возвратит относительно маленький процент строк таблицы, и просмотр индекса, скорее всего, окажется быстрее, чем полный просмотр таблицы.

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

Если вы знаете, что значение в фразе WHERE вашего запроса появляется в очень маленьком проценте строк, вы можете использовать совет INDEX, чтобы заставить оптимизатор выбрать просмотр индекса. В следующем предложении совет INDEX явно выбирает индексный просмотр по индексу SEX_INDEX, который был создан по столбцу SEX:

SELECT /*+ INDEX(patients sex_index) Use SEX_INDEX, since there
                are few male patients    */
name, height, weight
    FROM patients
    WHERE sex = 'M'

INDEX_ASC

Совет INDEX_ASC явно выбирает просмотр индекса для доступа к указанной таблице. Если предложение использует интервальный просмотр индекса, то ORACLE просматривает записи индекса в порядке возрастания индексных значений. Синтаксис этого совета имеет следующий вид:

Параметры здесь имеют тот же смысл, что и в совете INDEX.

Так как умалчиваемым поведением ORACLE при интервальном просмотре является просмотр в порядке возрастания индексных значений, этот совет в настоящее время ничем не отличается от совета INDEX. Однако корпорация Oracle не гарантирует, что умалчиваемое поведение интервальных просмотров индекса не изменится в будущем; поэтому вы можете явно специфицировать совет INDEX_ASC для интервального индексного просмотра по возрастанию, чтобы не полагаться на умалчиваемое поведение.

INDEX_DESC

Совет INDEX_DESC явно выбирает просмотр индекса для доступа к указанной таблице. Если предложение использует интервальный просмотр индекса, то ORACLE просматривает записи индекса в порядке убывания индексных значений. Синтаксис этого совета имеет следующий вид:

Параметры здесь имеют тот же смысл, что и в совете INDEX. Этот совет не имеет эффекта на предложения SQL, обращающиеся к более чем одной таблице. Такие предложения всегда выполняют интервальные просмотры в порядке возрастания индексных значений.

Например, рассмотрим следующую таблицу, которая содержит показания температуры резервуара с морской водой, содержащей образцы жизни моря:

CREATE TABLE tank_readings
    (time         DATE    CONSTRAINT un_time UNIQUE,
     temperature  NUMBER )

Каждая строка этой таблицы содержит значение времени и температуру, которая была измерена в этот момент времени. Ограничение UNIQUE по столбцу TIME гарантирует, что таблица содержит не более одного показания для каждого значения времени. ORACLE задействует это ограничение с помощью автоматически создаваемого индекса по столбцу TIME.

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

SELECT temperature
    FROM tank_readings
    WHERE time = (SELECT MAX(time)
                  FROM tank_readings
                  WHERE time <= TO_DATE(:t) )

предыдущая часть | содержание | следующая часть

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Обсудить на форуме Oracle
Отправить ссылку на страницу по e-mail


Interface Ltd.
Тel/Fax: +7(095) 105-0049 (многоканальный)
Отправить E-Mail
http://www.interface.ru
Ваши замечания и предложения отправляйте автору
По техническим вопросам обращайтесь к вебмастеру
Документ опубликован: 27.06.01