1096

Глава 13

3 values

4 (New Owner, New Name, New Type, 1111111);

1 row created. tkyte@TKYTE816> commit; Commit complete.

Теперь выполним аналогичный запрос, но обратимся только к вновь вставленной строке:

tkyte@TKYTE816> set timing on tkyte@TKYTE816> select owner, count(*)

2 from my all objects

3 where owner = New Owner

4 group by owner;

OWNER COUNT(*)

New Owner 1

Elapsed: 00:00:00.01

tkyte@TKYTE816> set timing off

tkyte@TKYTE816> set autotrace traceonly tkyte@TKYTE816> select owner, count(*)

2 from my all objects

3 where owner = New Owner

4 group by owner;

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=l Card=l Bytes=9)

1 0 TABLE ACCESS (FULL) OF MY ALL OBJECTS AGGS (Cost=l Card=Valve)

Statistics

0 recursive calls

12 db block gets

6 consistent gets

0 physical reads

0 redo size

430 bytes sent via SQL*Net to client

424 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

tkyte@TKYTE816> set autotrace off

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

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

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

tkyte@TKYTE816> set timing on tkyte@TKYTE816> select count(*)

2 from my all objects

3 where owner = New Owner; COUNT(*)

Elapsed: 00:00:00.00

tkyte@TKYTE816> set timing off tkyte@TKYTE816> set autotrace traceonly tkyte@TKYTE816> select count(*)

2 from my all objects

3 where owner = New Owner;

Execution Plan

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=9)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF MX ALL OBJECTS AGGS (Cost=l

-> Card=Valve) Statistics

0 recursive calls

12 db block gets

5 consistent gets

0 physical reads

0 redo size

367 bytes sent via SQL*Net to client

424 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

tkyte@TKYTE816> set autotrace off

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

1098

Глава 13

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

Назначение материализованных представлений

Его можно сформулировать коротко: пов1шение производительности. Получив (однажды) ответы на сложные вопросы, можно существенно снизить нагрузку на сервер. При этом:

Уменьшается количество физических чтений. Приходится просматривать меньше данных.

Уменьшается количество записей. Не нужно так часто сортировать/агрегировать данные.

Уменьшается нагрузка на процессор. Не придется постоянно вгчислять агрегаты

и функции от данных, поскольку это уже сделано.

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

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

Материализованные представления больше подходят для сред, где данные только читаются (пусть даже интенсивно). Они не предназначены для использования в среде интенсивной обработки транзакций. Они требуют дополнительных затрат ресурсов при изменении базовых таблиц для учета этих изменений. При использовании опции REFRESH ON COMMIT возникают проблемы одновременного доступа. Вернемся к рассмотренному выше примеру с итоговыми данными. При вставке строки в базовую таблицу (или удалении) необходимо изменить одну из 24 строк в итоговой таблице, чтобы количество было актуальным. Это означает, что одновременно фиксировать транзакции сможет не более 24 пользователей (если, конечно, они затрагивают объекты разных владельцев). Однако это не мешает использовать материализованные представления в среде ООТ. Например, если периодически полностью обновлять представления (в периоды минимальной нагрузки), при изменении данных ресурсы дополнительно расходоваться не будут, как не будет и проблем с одновременным доступом. Это позволит создавать отчеты на основе, например, вчерашних данных, не обращаясь к активно изменяющимся при обработке транзакций данным.