1090

Глава 13

териализованное представление, но не делает этого из-за отсутствия важной информации). В частности, будет:

рассмотрен пример, демонстрирующий возможности материализованных представлений и позволяющий решить, пригодятся ли они вам;

описаны параметры и привилегии, которые необходимо установить для использования материализованных представлений;

показано на примерах использование измерений (dimensions) и требований целостности, позволяющих серверу определить, когда для ответа на запрос оправданно применение материализованного представления;

описано использование пакета DBMSOLAP для анализа представлений;

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

Предыстория

Управление итоговыми таблицами - еще одна возможность материализованного представления - уже некоторое время использовалось в инструментальных средствах типа Oracle Discoverer (средство построения произвольных запросов и отчетов). С помощью Discoverer администратор создает в базе данных итоговые таблицы. Затем это инструментальное средство анализировало запросы, прежде чем отправлять их на сервер Oracle. Если имеется итоговая таблица, позволяющая более эффективно ответить на запрос, Discoverer переписывает запрос так, чтобы он обращался к итоговым таблицам, а не к базовым, заданным в исходном запросе, после чего отправляет запрос серверу Oracle. Это б1ло замечательно, пока для выполнения запросов использовалось именно это средство. Если аналогичный запрос выполнялся из среды SQL*Plus или поступал от клиента по протоколу JDBC, то перезапись запроса не происходила (не могла происходить). Более того, синхронизация между исходными и итоговыми данными не могла выполняться автоматически, поскольку это инструментальное средство не входило в состав сервера.

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

В версию Oracle 8.1.5 (Enterprise и Personal Edition) из инструментальн1х средств типа Discoverer была перенесена возможность переписывания запросов, предусмотрены механизмы автоматического обновления и планирования моментальных снимков (что позволило сделать итоговые таблицы самоподдерживаемыми ), и все это объединено с воз-

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

можностью оптимизатора находить лучший план из многих альтернативных. В результате получились материализованные представления.

Все эти возможности, сосредоточенные в сервере, теперь позволяли любому приложению использовать преимущества автоматического переписывания запросов, независимо от способа доступа к базе данных: из утилиты SQL*Plus, из приложения Oracle Forms, через протоколы JDBC и ODBC, из программ Рго*С, OCI или из средства сторонних производителей. Любой сервер Oracle 8i масштаба предприятия позволяет управлять итоговыми таблицами. Кроме того, поскольку все происходит в базе данных, итоговые таблицы легко синхронизировать с исходными (по крайней мере сервер все-1да знает , когда они не синхронизирован!, и может не использовать устаревшие итоговые таблицы (этим управляет пользователь)). Поскольку эти функциональные возможности включены непосредственно в сервер, любое приложение, способное обратиться к СУБД Oracle, может воспользоваться ими.

Тот же подход лежит в основе реализации средств тщательного контроля доступа (Fine Grained Access Control, FGAC, см. раздел об открытости в главе 1 и главу 21, посвященную этим средствам). Чем ближе к данным применяются функции, тем большее количество инструментальных средств сможет ими воспользоваться. Если поместить средства защиты вне базы данных, например в приложении, воспользоваться ими смогут только пользователи этого приложения (и то, если обращаются к данным исключительно через приложение).

Что необходимо для выполнения примеров

Для выполнения примеров, представленных в этой главе, необходима редакция Penal или Enterprise Edition сервера версии Oracle 8.1.5 и выше. Соответствующие функциональные возможности не поддерживаются в редакции Standard. Учетная запись, от имени которой будут выполняться примеры, должна иметь следующие привилегии:

GRANT CREATE SESSION

GRANT CREATE TABLE

GRANT CREATE MATERIALIZED VIEW

GRANT QUERY REWRITE

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

Кроме того, необходим доступ к табличному пространству, 30-50 Мбайт которого свободно.

Наконец, чтобы воспользоваться средствами переписывания запросов, необходимо использовать оптимизатор, основанный на стоимости (Cost-Based Optimizer - СВО). Если СВО не используется, запрос не может быть переписан. В наших примерах остав-

1092

Глава 13

лена стандартная цель оптимизации, CHOOSE; чтобы воспользоваться возможностями переписывания запросов, достаточно проанализировать таблицы.

Пример

Продемонстрирую на простом примере, что может дать материализованное представление. Вы увидите, насколько сокращается время выполнения запроса за счет добавления итогов1х данных. Запрос к большой таблице будет переписан сервером в запрос к гораздо меньшей таблице, причем без потери точности результата. Начнем с создания большой таблицы, содержащей список владельцев и принадлежащих им объектов. Таблица строится на основе представления ALL OBJECTS словаря данных:

tkyte@TKYTE816>create table my all objects

2 nologging

3 as

4 select * from all objects

5 union all

6 select * from all objects

7 union all

8 select * from all objects

Table created.

tkyte@TKYTE816> insert /*+ APPEND */ into my all objects 2 select * from my all objects;

65742 rows created.

tkyte@TKYTE816> commit; Commit complete.

tkyte@TKYTE816> insert /*+ APPEND */ into my all objects 2 select * from my all objects;

131484 rows created.

tkyte@TKYTE816> commit;

Conmit complete.

tkyte@TKYTE816> analyze table my all objects compute statistics; Table analyzed.

Моя система поддерживает язык Java (Java option), поэтому в таблице MY a OBJE][S после выполнения указанных действий оказалось около 250000 строк. Для получения такого же результата вам, возможно, придется выполнить UNION ALL и INSERT большее количество раз. Теперь выполним запрос к этой таблице, показывающий количество объектов у каждого пользователя. Первоначально для этого понадобится полный просмотр громадной таблицы:

tkyte@TKYTE816> set autotrace on

tkyte@TKYTE816>set timing on

tkyte@TKYTE816> select owner, count(*) from my all objects group by owner;