Программирование >>  Oracle 

1 ... 227 228 229 [ 230 ] 231 232 233 ... 469


Материализованные представления 99

Как работать с материализованными представлениями

Сначала работа с материализованными представлениями может показаться сложной. Иногда материализованное представление содержит ответ на определенный вопрос, но сервер Oracle почему-то его не использует. Если достаточно глубоко покопаться, можно понять, почему. Сервер Oracle - всего лишь программа, и она может работать только с явно предоставленной информацией. Чем больше метаданных предоставлено, чем больше сведений о базовых данных передано серверу Oracle, тем лучше. Эти фрагменты информации (требования NOT NULL, первичные ключи, внешние ключи и т.д.) - слишком тривиальные вещи, чтобы задумываться о них в среде хранилищ данных. Предоставляемые этими ключами и требованиями метаданные дают оптимизатору больше информации, а значит, - больше шансов.

Ключи и требования, подобные представленным выше, не только обеспечивают целостность данных, но и добавляют в словарь данных информацию о данных, которую можно использовать при переписывании запросов (отсюда и название - метаданные). Подробнее об этом см. в разделе Требования целостности .

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

Подготовка

Для использования материализованных представлений обязательно надо установить один параметр инициализации, COMPATIBLE. Параметр COMPATIBLE должен иметь значение 8.1.0 или больше, чтобы переписывание запросов вообще применялось. Если этот параметр не будет иметь соответствующего значения, модуль переписывания запросов не будет вызываться.

Есть еще два связанных с использованием материализованных представлений параметра, которые можно устанавливать либо на уровне системы (в файле параметров инициализации, INIT.ORA), либо на уровне сеанса (с помощью оператора ALTER SESSION).

QUERY REWRITE ENABLED. Если этот параметр не имеет значения TRUE, запроса не переписывается. Стандартное значение - FALSE.

QUERY REWRITE INTEGRITY. Этот параметр управляет тем, как сервер Oracle переписывает запросы. Он может иметь одно из трех значений.

ENFORCED. Запросы будут переписываться с помощью требований и правил, применяемых и гарантируемых сервером Oracle. Имеются механизмы, с помощью которых можно сообщить серверу Oracle о других косвенных взаимосвязях, и это позволит переписать больше запросов; но поскольку сервер Oracle не обеспечивает эти взаимосвязи, он не будет использовать подобные сведения на этом уровне целостности.



1100 Глава 13

TRUSTED. Запросы будут переписываться на основе требований, обеспечиваемых сервером Oracle, а также всех взаимосвязей данных, о которых сообщили серверу, даже если их выполнение сервером не гарантируется. Например, в начальном примере можно вручную создать физическую таблицу MY ALL OBJECTS AGGS с помощью распараллеливаемого и нерегистриру-емого в журнале повторного выполнения оператора CREATE TABLE AS SELECT (для ускорения построения итоговой таблицы). Затем можно создать материализованное представление, использующее эту созданную заранее таблицу, а не создавать ее заново. Если необходимо, чтобы сервер Oracle использовал эту созданную заранее таблицу при последующем переписывании запросов, необходимо задать параметру QUERY REWRITE INTEGRITY значение TRUSTED. Надо, чтобы сервер Oracle поверил , что мы предоставили корректные данные в заранее созданной таблице (сам сервер Oracle корректность этих данных не обеспечивает).

STALE TOLERATED. Запросы будут переписываться для использования материализованных представлений, даже если серверу Oracle известно, что содержащиеся в представлении данные устарели (не синхронизированы с исходными). Это может пригодиться в среде, где итоговые таблицы обновляются периодически, а не при фиксации изменений, и где небольшая рассинхрони-зация приемлема.

В представленном выше примере использовались операторы ALTER SESSION, обеспечивающие применение фокуса с переписыванием запроса. Поскольку в примере использовались только объекты и связи, поддерживаемые сервером Oracle, целостность запроса при перезаписи можно установить максимальной: ENFORCED.

Также необходимо получить привилегию QUERY REWRITE. Но учетной записи, от имени которой я работаю, предоставлена роль DBA, среди привилегий которой есть и QUERY REWRITE, так зачем же явно предоставлять эту привилегию самому себе? Причина в том, что нельзя создать скомпилированные хранимые объекты, будь то материализованные представления, хранимые процедуры или триггеры, имея привилегии роли (роли DBA в данном случае). Полное описание особенностей использования ролей при работе со скомпилированными хранимыми объектами дано в главе 23. Если создается материализованное представление при включенном параметре QUERY REWRITE ENABLED, но системная привилегия QUERY REWRITE явно не предоставлена, будет получено следующее сообщение об ошибке:

create materialized view my all objects aggs ERROR at line 1:

ORA-01031: insufficient privileges

Внутренняя реализация

Итак, теперь, научившись создавать материализованные представления и убедившись, что они используются, разберемся, что будет предпринимать сервер Oracle для переписывания запросов? Обычно, когда параметр QUERY REWRITE ENABLED имеет значение FALSE, сервер Oracle анализирует полученный оператор SQL и оптимизирует его.



Материализованные представления 1101

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

Переписывание запроса

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

Полное совпадение текста

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

Частичное совпадение текста

Начиная с конструкции FROM, оптимизатор сравнивает оставшийся текст с текстом запроса, определяющего материализованное представление. В результате допускаются расхождения в списке выбора. Если необходимые данные можно получить из материализованного представления (т.е. по нему можно найти значения всех выражений, указанных в списке выбора), сервер Oracle перепишет запрос с использованием этого материализованного представления. Запрос SELECT LOWER(OWNER) FROM MY ALL OBJECTS GROUP BY OWNER; - пример частичного совпадения текста.

Общие методы переписывания запроса

Они обеспечивают использование материализованного представления, даже если оно содержит часть необходимых данных, больше данных или данные, которые могут быть преобразованы к нужному виду. Оптимизатор сравнивает определение материализованного представления с отдельными компонентами запроса (SELECT, FROM, WHERE, GROUP BY) в поисках соответствия. При этом сервер Oracle проверяет для этих компонентов следующее.

Достаточность данн1х. Можно ли получить нужные данные из этого материализованного представления? Если в списке выбора есть столбец X, отсутствующий в материализованном представлении, и его нельзя получить, выполняя соединение с этим представлением, то сервер Oracle не будет переписывать запрос так, чтобы он обращался к этому представлению. Например, запрос SELECT



1 ... 227 228 229 [ 230 ] 231 232 233 ... 469

© 2006 - 2025 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика