Министерство образования РФ Удмуртский государственный университет Физический факультет Кафедра информатики и математики РЕФЕРАТ Тема: «Материализованные представления». Выполнила: Светлакова Е.А., студентка гр. 38-41 Проверил: Вотинцев А.А. Ижевск, 2006 Содержание: 1. Понятие материализованного представления.................................................3 2. Синтаксис создания материализованного представления.............................4 3. Свойства материализованного представления. Объекты, связанные с материализованными представлениями..........................................................5 4. Создание материализованных представлений и работа с ними....................7 4.1. Создание материализованных представлений..........................................7 4.2. Использование предварительно построенных таблиц.............................9 4.3. Синхронизация с изменениями в исходных данных..............................11 5. Пример работы с материализованными представлениями..........................16 6. Приложение......................................................................................................17 7. Список литературы..........................................................................................19 2 Понятие материализованного представления. Часто бывает необходимо выполнить сложные запросы, которые суммируют данные из нескольких таблиц, а этот процесс требует большого объема вычислений. До сих пор единственным решением было использование сводных таблиц в хранилище данных, но этот подход имеет свои недостатки. В Oracle8i появилась новая возможность создание материализованных представлений (выводимые таблицы с хранимым результатом), суммирующих данные, которые могут существенно улучшить выполнение запросов к хранилищам данных. Материализованное представление (materialized view) - это представление, результаты которого не вычисляются в момент обращения к нему с помощью оператора SELECT, а хранятся в специальных скрытых от пользователя таблицах. В Oracle и раньше была подобная возможность. Она называлась SNAPSHOT. Главным отличием SNAPSHOT в ранних версиях Oracle от материализованных представлений является то, что последние могут автоматически обновляться при изменении базовых таблиц. Материализованные представления позволяют заметно ускорить обработку аналитических и статистических запросов, производящих агрегатные вычисления над большими объемами данных. Самое интересное, что Oracle автоматически преобразовывает запросы к базовым таблицам так, чтобы использовать агрегированные значения из материализованных представлений, тем самым значительно повышая производительность. Таким образом, вы можете повышать производительность давно эксплуатируемых приложений простым добавлением материализованных представлений, ведь они даже не будут знать, что вычисления производятся не над базовыми таблицами. Материализованное представление обслуживается процессом обновления. Этот процесс может выполняться автоматически при фиксации операции, либо может контролироваться вручную администратором БД. Обновление представления может выполняться как полностью, так и только для измененных данных. Материализованное представление похоже на моментальный снимок таблицы (table snapshot). Например, вы обновляете материализованное представление, чтобы поддерживать актуальность сводной информации. Материализованные представления чем-то напоминают индексы: используют область хранения, должны обновляться при изменении данных в главных таблицах, и при использовании для преобразования запросов, увеличивают скорость обработки SQLзапросов. Кроме того, в отличие от индексов, к материализованным представлениям можно получить доступ напрямую в выражении SELECT и, в зависимости от типа обновления, в выражениях INSERT, UPDATE или DELETE. 3 Синтаксис создания материализованного представления. Materialized views, так же как и обычные именованные выводимые таблицы, являются с точки зрения словаря-справочника Oracle хранимыми объектами и создаются, изменяются и удаляются SQL-командами CREATE, ALTER и DROP, например: CREATE MATERIALIZED VIEW имя [ENABLE QUERY REWRITE] AS SELECT ... Если в предложении выше присутствует фраза ENABLE QUERY REWRITE, это выводимая хранимая таблица для возможности перенаправления к ней запроса, предъявленного к базовым. Иначе, если в предложении SELECT присутствует обращение к удаленной таблице (в другой БД), это выводимая хранимая таблица для локализации удаленных данных. Если в предложении CREATE MATERIALIZED VIEW нет ни того, ни другого, это обычная выводимая таблица с хранимым результатом, создаваемая для технических ухищрений программирования работы с данными в Oracle. AS описывает запрос, используемый для создания материализованного представления, почти каждый запрос может быть использован с учетом нескольких ограничений, например: ссылка на эту таблицу не может принадлежать пользователю "SYS", столбцы с атрибутом LONG не разрешены, представления, которые включают операции соединения (join) и GROUP BY не могут быть выбраны из IOT (Index-Organized Table). Отметьте, что в примере, когда имя таблицы полностью квалифицируется схемой владельца таблицы, это предлагается, но не требуется Oracle. Запрос может включать GROUP BY, CUBE, ROLLUP, операции соединения, вложенные запросы (динамические представления) и почти любую другую конструкцию. Oracle8i Release 2 (8.1.6) позволяет запросу содержать фразу ORDER BY и for INSERT...SELECT в материализованном представлении, что также оговаривается ORDER BY. Oracle рекомендует, чтобы имена материализованных представлений не превосходили 19 символов, тогда полное сгенерированное имя не будет больше 30 символов; Кроме этого materialized views могут характеризоваться следующим признаком: наличием в своем определении операции соединения над базовыми таблицами. 4 Свойства материализованного представления. Объекты, связанные с материализованными представлениями. В целом materialized views характеризуются следующими группами свойств: Описание ожидаемого результата, задаваемое предложением SELECT Схема обновления результата Схема внутренней организации результата Свойства хранения и доступа Все свойства этих групп формулируются собственными синтаксическими конструкциями в предложениях CREATE/ALTER MATERIALIZED VIEW. Сведения об имеющихся выводимых таблицах с хранимым результатом и их свойства хранятся в системных USER/ALL/DBA_-таблицах с подстрокой MVIEW в имени, например: USER_MVIEWS USER_MVIEW_LOGS USER_MVIEW_AGGREGATES USER_MVIEW_DETAIL_RELATIONS USER_MVIEW_JOINS USER_MVIEW_KEYS Часть свойств materialized views в этих таблицах унаследована от выводимых таблиц (обновляемость), часть от хранимых таблиц (внутренняя организация, организация хранения, а часть свойств является собственными (схемы обновления хранимого результата)). В то же время при работе с materialized views в схеме автоматически создаются специальные служебные объекты (таблицы, индексы). Сведения о них доступны из “обычных” справочных таблиц, в первую очередь из USER_OBJECTS. Материализованные представления - это объекты схемы, которые используются для обобщения, прекомпиляции, репликации и распределении данных. Они могут использоваться в широком диапазоне вычислительных сред - хранении данных, поддержке принятия решений и в распределенной или мобильной среде. В хранилищах данных материализованные представления используются для прекомпиляции и хранения агрегированных данных, таких, как суммы, средние значения и т.п. Материализованные представления в таких средах обычно называются обобщениями (summary), поскольку они хранят обобщенные данные. Помимо этого они могут использоваться для прекомпиляции связей (joins) в многотабличных запросах с агрегированными значениями или без них. Стоимостной (Cost-based) оптимизатор может использовать материализованные view для повышения скорости выполнения запросов, автоматически распознавая, когда материализованные представления могут быть использованы вместо базовых таблиц. В распределенных средах материализованные представления используются для кэширования данных на локальных серверах. В мобильных вычислительных системах материализованные представления используются для передачи наборов данных от центральных серверов - мобильным клиентам (с периодическим обновлением данных центральными серверами и передачей обновленных данных с мобильного клиента). В целом материализованные представления - полезное новшество, облегчающее жизнь разработчика и позволяющее оптимизировать некоторые аспекты работы с базой данных. Не следует, тем не менее, считать это нововведение некой палочкойвыручалочкой. Материализованным представлениям присущи ограничения, вытекающие из жизненных реалий - поскольку даже такому гиганту как Oracle не по силам сделать все и сразу. Приведем их краткое перечисление: 5 Запрос, на котором базируется материализованное представление, не может выбирать данные из таблиц или view, принадлежащих пользователю SYS. В запросе, на котором базируется материализованное представление, нельзя использовать выражение ORDER BY. Материализованные представления не могут базироваться на индексных таблицах (index-organized tables), если в запросе, на котором базируется материализованное представление, содержатся связи или оператор GROUP BY. Материализованные представления не могут содержать колонок с типом данных LONG. Если подзапрос ссылается на временную таблицу, для этого материализованного представления нельзя ни создать log, ни указать QUERY REWRITE в CREATE MATERIALIZED VIEW или в ALTER MATERIALIZED VIEW. Если в списке FROM материализованного представления есть ссылка на другой материализованное представление, то, чтобы сохранить целостность, следует отследить порядок обновления материализованных представлений вручную. Подзапрос не может содержать (напрямую либо через view) ссылок на ROWNUM, USER, SYSDATE, удаленные таблицы, последовательности или функции PL/SQL, которые могут записывать или считывать БД или package. Материализованные представления и базовые таблицы должны быть локальными Нельзя использовать условия HAVING или CONNECT BY. В материализованном представлении нельзя определять любые вложенные подзапросы или вложенные (inline) view. При использовании GROUP BY, в нем нельзя использовать функции или выражения PL/SQL, и, кроме того, в списке SELECT следует определить все колонки GROUP BY. Все реляционные объекты, представленные в списке FROM, должны быть таблицами, причем они должны отличаться после разрешения синонимов. Для комплексных материализованных представлений следует определить внешние связи, и перечислить обе стороны этих связей в списке GROUP BY. Каждое агрегированное выходное выражение должно использовать только одну функцию агрегации (SUM, MIN, MAX, COUNT(x), COUNT(*), COUNT(DISTINCT x), AVG, VARIANCE, GROUPING или STDDEV) с выражением, которое содержит неявную ссылку на любую другую группирующую функцию. 6 Создание материализованных представлений и работа с ними. Создание материализованных представлений. Для создания материализованного представления в базе данных, и дальнейшего анализа его влияния на выполнение запросов, необходимо выполнить следующие шаги: Шаг 1. Установите параметры сервера. Шаг 2. Дайте привилегии соответствующей схеме. Шаг 3. Создайте материализованное представление. Шаг 4. Обновите статистику оптимизатора. Шаг 5. Убедитесь, что материализованное представление используется. Шаг 6. Вручную обновите материализованное представление. Шаг 1. Установите параметры сервера Перед созданием материализованного представления необходимо установить несколько параметров сервера. В таблице 1 (см. Приложение) перечислены все параметры; дано их краткое описание, и рекомендованы значения для обновления сводной информации, переписывания запроса, и последующего анализа. Как нужно отредактируйте файл параметров сервера (init.ora) и затем перезапустите экземпляр, чтобы использовались новые настройки. Шаг 2. Дайте привилегии соответствующей схеме Oracle8i предоставляет некоторые новые привилегии базы данных для создания и использования материализованных представлений, а также для обеспечения возможности переписывания запроса для материализованных представлений. Предположим, что вы создали материализованное представление у того же пользователя (в той же схеме), который является владельцем лежащих в основе базовых таблиц (рекомендуемая конфигурация). Этому пользователю нужно дать системные привилегии CREATE MATERIALIZED VIEW, CREATE TABLE, CREATE VIEW и QUERY REWRITE. Ему необходима также существенная квота табличного пространства для хранения материализованного представления, точная квота колеблется в зависимости от размеров сводной таблицы. Шаг 3. Создайте материализованное представление Для создания материализованного представления используйте SQL-команду CREATE MATERIALIZED VIEW. Следующая ниже команда создает простое материализованное представление, содержащее сводную информацию, вычисляемую из данных детальных связанных таблиц ORDERS, ITEMS, и PARTS: CREATE MATERIALIZED VIEW sales_summary BUILD IMMEDIATE REFRESH COMPLETE ON DEMAND ENABLE QUERY REWRITE AS SELECT i.ord_ord_id AS order_id, MAX(TO_CHAR(orderdate,'MonthYYYY')) AS orderdate, SUM(i.quantity * p.unitprice) AS total FROM orders o, items i, parts p WHERE o.ord_id = i.ord_ord_id AND p.part_id = i.part_part_id GROUP BY i.ord_ord_id; Обратите внимание на следующие ключевые слова в приведенном выше предложении: Предложение BUILD IMMEDIATE заполняет материализованное представление во время его создания (значение по умолчанию). Альтернативное предложение 7 BUILD DEFERRED создает только структуру; заполнить материализованное представление можно позже, используя пакет DBMS_MVIEW. Используйте BUILD DEFERRED для заполнения материализованного представления по окончании рабочего дня, чтобы избежать влияния на обычные операции. Предложение REFRESH указывает, как Oracle8i обновляет данные материализованного представления. В приведенном примере полные (COMPLETE) обновления являются единственным вариантом. Возможны также быстрые (FAST) (инкрементные) обновления, однако для них существует ряд ограничений и предостережений, подробнее смотрите в руководстве Настройка Oracle8i правила, управляющие быстрыми обновлениями материализованных представлений. В предложении REFRESH также указывается, когда Oracle8i обновляет данные материализованного представления. В этом примере, материализованное представление будет обновляться по требованию (ON DEMAND) - только, когда вы явно обновляете его, используя пакет DBMS_MVIEW. Если объявленный запрос материализованного представления содержит сводные показатели и контрольные цифры только одной таблицы, или если этот запрос соединяет данные из нескольких таблиц, но не содержит никаких сводных показателей, то Oracle8i может автоматически обновлять представление при фиксации транзакции (ON COMMIT) - каждый раз когда выполняется фиксация транзакции для мастер таблицы (таблиц) представления. Опцию QUERY REWRITE необходимо включить, чтобы оптимизатор Oracle8i переписывал запросы таким образом, чтобы использовались материализованные представления. (Этот параметр можно также установить позднее, используя SQLкоманды ALTER SYSTEM или ALTER SESSION.) Предложение AS описывает столбцы и строки материализованного представления, используя определяющий запрос (ничем не отличающийся от запроса в стандартном представлении или моментальном снимке). Определяющие запросы для материализованных представлений, используемых в хранилище данных (для сводных таблиц), будут вычислять один или несколько сводных показателей часто используемых аналитиками. Шаг 4. Обновите статистику оптимизатора Возможность переписывания запроса в Oracle8i связана с оптимизатором Oracle, основанным на стоимости. Следовательно, необходимо убедиться, что статистика для всех таблиц и материализованных представлений в схеме хранилища данных является актуальной. Для обновления статистики можно выдавать индивидуальную команду ANALYZE для каждого объекта схемы, после того как в него загружены новые данные, либо обновлять статистику оптимизатора для всех объектов схемы, используя процедуру ANALYZE_SCHEMA пакета DBMS_UTILITY. Следующий PL/SQL блок обновляет статистику для всех объектов схемы SALES_APP, включая детальные таблицы и материализованные представления, используемые в примере: BEGIN dbms_utility.analyze_schema('SALES_APP','ESTIMATE',15); END; Шаг 5. Убедитесь, что материализованное представление работает, и запрос переписывается Теперь можно использовать команду EXPLAIN PLAN для проверки работы материализованного представления и убедиться в том, что Oracle8i будет переписывать сводный запрос таким образом, чтобы использовалось материализованное представление. Запрос, приведенный в Листинге 1, обращается к детальным таблицам ORDERS, ITEMS, и PARTS. План выполнения показывает, что Oracle8i автоматически переписал запрос, чтобы использовать преимущества материализованного представления SALES_SUMMARY, которое содержит данные, необходимые для выполнения запроса. 8 Листинг 1 Это предложение EXPLAIN PLAN и запрос на его вывод из таблицы PLAN_TABLE объясняют, как Oracle8i перезаписывает запрос, адресуемый к детальным таблицам, чтобы получить преимущества от использования маитериализованных представлений. EXPLAIN PLAN SET STATEMENT_ID = '1.0' INTO plan_table FOR SELECT i.ord_ord_id AS order_id, MAX(TO_CHAR(orderdate,'MonthYYYY')) AS orderdate, SUM(i.quantity * p.unitprice) AS total FROM orders o, items i, parts p WHERE o.ord_id = i.ord_ord_id AND p.part_id = i.part_part_id GROUP BY i.ord_ord_id; SELECT LPAD(' ',2*LEVEL)||operation||' ' ||options||' '||object_name AS exec_plan, cost FROM plan_table WHERE statement_id = '1.0' CONNECT BY PRIOR id = parent_id AND statement_id = '1.0' START WITH id = 1; OPERATION COST --------------------------------- ------TABLE ACCESS FULL sales_summary 31 Одной из основных выгод создания материализованных представлений является возможность использования преимуществ переписывания запросов. В существующих приложениях, содержащих дорогостоящие сводные запросы, которые вычисляют контрольные цифры для детальных таблиц, существенно повысится производительность, и при этом не придется изменять сами приложения. Кроме того, пользователи хранилища данных не должны знать ничего о материализованных представлениях для того, чтобы воспользоваться их преимуществами: это похоже на построение нового индекса, который помогает определенным запросам выполняться быстрее. Шаг 6. Обновление материализованных представлений вручную Для обновления данных в материализованном представлении вручную, для того, чтобы оно отображало самую свежую информацию из детальных таблиц, можно вызвать процедуры REFRESH, REFRESH_ALL_MVIEWS, или REFRESH_DEPENDENT пакета DBMS_MVIEW. Следующий PL/SQL блок обновляет материализованное представление SALES_SUMMARY в схеме SALES_APP. BEGIN dbms_mview.refresh('SALES_APP.SALES_SUMMARY', 'A'); END; Использование предварительно построенных таблиц. Определение материализованного представления на существующей таблице (ON PREBUILT TABLE) позволяет использовать существующие таблицы и индексы. drop table dept_summary_tab; drop snapshot dept_summary_tab; create table dept_summary_tab 9 as select dept.deptno ,dname ,count(*) nbr_emps ,sum(nvl(sal,0)) tot_sal from scott.emp emp ,scott.dept dept where emp.deptno(+) = dept.deptno group by dept.deptno,dname; create materialized view dept_summary_tab on prebuilt table with reduced precision refresh start with sysdate next sysdate + 1 as select dept.deptno ,dname ,count(*) nbr_emps ,sum(nvl(sal,0)) tot_sal from scott.emp emp ,scott.dept dept where emp.deptno(+) = dept.deptno group by dept.deptno,dname; Использование фразы ON PREBUILT TABLE требует, чтобы исходная таблица и материализованное представление использовали одни и те же имя и схему. WITH REDUCED PRECISION позволяет обновлению работать должным образом, даже если некоторые столбцы генерируют значения с точностью, отличной от той, что была первоначально определена. Пример создания материализованного представления: CREATE TABLE e4 AS SELECT * FROM emp WHERE deptno = 20; CREATE MATERIALIZED VIEW e4 ON PREBUILT TABLE AS SELECT * FROM emp; SELECT * FROM e4; Нужно обратить внимание на то, что при таком построении materialized view сведения о бывшей самостоятельной роли таблицы E4 после создания выводимой E4 не теряются. Они восстановятся после удаления materialized view (что невозможно при обычном создании): DROP MATERIALIZED VIEW e4; SELECT * FROM e4; Далее приведен пример использования материализованного представления, определенного на базовой таблице: select dname,ename,sal,sal/tot_sal pct_dept from emp,dept_summary_tab where emp.deptno = dept_summary_tab.deptno order by dname 10 Синхронизация с изменениями в исходных данных. Синхронизация образованных при создании materialized view данных с изменениями в базовых таблицах требуется почти всегда. Принципы синхронизации общие для всех категорий materialized view. Синхронизация может осуществляться явно, либо выполняться автоматически. Схема обновления хранимого результата характеризуется двумя свойствами: Режим обновления. Указывает, будет ли обновление осуществляться по фиксации транзакции (ON COMMIT) или с помощью API (ON DEMAND), процедурам из состава системных пакетов Oracle, вызываемым явно или неявно (автоматически). Метод обновления. Два основных метода – полное перевычисление результата (COMPLETE) и экономное (FAST), достигаемое путем внесения в результат только изменений, вызванных изменениям в базовых таблицах. Оба свойства могут указываются во фразе REFRESH предложения CREATE/ALTER MATERIALIZED VIEW: CREATE MATERIALIZED VIEW имя [REFRESH ...]; При указании режима ON DEMAND дополнительно можно задать желаемое время внесения обновлений. Вот возможные сочетания задаваемых свойств схемы обновления: Обновления всех видов можно на время запретить, переведя materialized view в специальное состояние командой: ALTER MATERIALIZED VIEW имя NEVER REFRESH; Явное обновление полученных данных. Явное обновление результатов materialized view осуществляется через API, обращением к процедуре REFRESH из состава системного пакета DBMS_MVIEW (старое название – DBMS_SNAPSHOT): EXECUTE DBMS_MVIEW.REFRESH('jobsal') Первый параметр этой процедуры, LIST, может содержать имя выводимой таблицы или их список через запятую. Помимо него у процедуры есть несколько необязательных параметров. Среди них параметр METHOD используется для указания одного из возможных для данной таблицы метода обновления. Пример явного обновления с полным перевычислением результата: EXECUTE DBMS_MVIEW.REFRESH(LIST => 'jobsal', METHOD => 'C') 11 Другие значения параметра METHOD: A (Always, то же, что и ”C”, COMPLETE), ”F” (FAST, быстрое обновление, путем внесения изменений), ”?” (форсированное обновление). Явное обновление применимо к materialized view с любыми установленными режимом и методом обновления. Неявное обновление данных. Происходит в режиме ON COMMIT или ON DEMAND. Режим ON DEMAND (явно можно не указывать) позволяет организовать автоматический пересчет результата по графику. Метод для этих режимов обновления можно указывать любой: и FAST, и COMPLETE. Если пересчет ведется методом FAST, то для таблицы нужно создать журналы всех ее базовых таблиц (materialized view logs). Это будут вспомогательные таблицы, накапливающие сведения об изменениях, совершаемых в базовых. Они и позволят внести необходимые поправки в данные materialized view. После выполнения процедуры обновления журналы автоматически чистятся. Для пересчета результата методом COMPLETE журнал не нужен. Журналы базовых таблиц. Пример создания журнала для исходной (базовой) таблицы: CREATE MATERIALIZED VIEW LOG ON emp; После этой команды в схеме появится служебная таблица для журнализации изменений в EMP и служебный триггер для актуализации таких изменений. (В последних версиях Oracle этот триггер сделан внутренним и в таблице USER_TRIGGERS не виден). Объем данных, попадаемых в журнал, можно регулировать фразой WITH предложения CREATE MATERIALIZED VIEW LOG, вставляемой после фразы ON: CREATE MATERIALIZED VIEW LOG ON имя WITH ... Вот возможные указания для обычных таблиц: PRIMARY KEY: можно не указывать, так как в последних версиях первичный ключ заносится в журнальную строку автоматически. ROWID: при внесении изменений в базовую таблицу в журнальной будет отмечаться ее физический адрес. (список_столбцов): при внесении изменений в базовую таблицу в журнальную будут заноситься значения полей. SEQUENCE: при добавлении в журнальную таблицу новой строки она будет специально нумероваться INCLUDING NEW VALUES: в журнал будут помещаться не только старые, но и новые значения. По умолчанию используется EXCLUDING NEW VALUES. 12 (Для более экзотических объектных таблиц можно еще указывать WITH OBJECT ID). Примеры: DROP MATERIALIZED VIEW LOG ON emp; CREATE MATERIALIZED VIEW LOG ON emp WITH ROWID; DROP MATERIALIZED VIEW LOG ON emp; CREATE MATERIALIZED VIEW LOG ON emp WITH ROWID, SEQUENCE, (sal,comm); DROP MATERIALIZED VIEW LOG ON emp; CREATE MATERIALIZED VIEW LOG ON emp WITH (sal,comm) INCLUDING NEW VALUES; Разный объем информации, включаемой в журнал, может быть востребован разными схемами обновления. Некоторые схемы обновления могут требовать включения в состав строк журнала определенных полей, а некоторые – нет. Задание схемы обновления 1. Указание объема вычислений при обновлении Синтаксически для указания метода обновления используются следующие ключевые слова во фразе REFRESH: REFRESH COMPLETE: указывает СУБД, что при автоматическом обновлении хранимого результата он будет перевычисляться полностью путем повторения оператора SELECT, сформулированного для materialized view. Это гарантированно надежный вариант обновления. REFRESH FAST: указывает СУБД, что при неявном обновлении в хранимый результат будут вноситься изменения на основе информации, собранной в журналах базовых таблиц. Это более быстрый вариант. REFRESH FORCE: указывает СУБД выбрать режим FAST, если это возможно, иначе – COMPLETE. Это вариант по умолчанию. Примеры: DROP MATERIALIZED VIEW LOG ON emp; CREATE MATERIALIZED VIEW LOG ON emp WITH (sal,comm), ROWID INCLUDING NEW VALUES; ALTER MATERIALIZED VIEW jobsal REFRESH FAST; DROP MATERIALIZED VIEW LOG ON emp; ALTER MATERIALIZED VIEW jobsal REFRESH COMPLETE; 13 Пример показывает, что экономное обновление агрегирующего хранимого результата возможно только при выполнении некоторых условий на полноту журнальной таблицы. 2. Указание времени обновления Синтаксические конструкции фразы REFRESH для указания времени осуществления обновлений: ON COMMIT: режим, при котором обновление хранимого результата будет производиться по всякой фиксации транзакции (COMMIT). Время фиксации возрастет. ON DEMAND: режим, при котором обновление будет осуществляться процедурами из состава системного пакета DBMS_MVIEW. START WITH первый_раз NEXT потом: обновление будет выполнено единожды первый_раз, после чего автоматически повторяться по формуле, вычисляемой потом. Может быть только уточнением к режиму ON DEMAND. Автоматическое выполнение обновлений по графику возможно только в случае, если в составе СУБД запущены необязательные фоновые процессы SNPn. Их запуск достигается путем указания параметра СУБД JOB_QUEUE_PROCESSES. До версии 9 умолчанием для него был 0. Пример: CREATE MATERIALIZED VIEW LOG ON emp WITH ROWID INCLUDING NEW VALUES; ALTER MATERIALIZED VIEW jobsal REFRESH START WITH SYSDATE NEXT SYSDATE+1/1440; COMMIT; SELECT * FROM jobsal; Примеры обновлений в режиме ON COMMIT: DROP MATERIALIZED VIEW LOG ON emp; CREATE MATERIALIZED VIEW emp2 REFRESH COMPLETE ON COMMIT AS SELECT * FROM emp; CREATE MATERIALIZED VIEW jobtotals REFRESH ON COMMIT AS SELECT job, COUNT(*), COUNT(comm), SUM(comm), SUM(sal) FROM emp GROUP BY job; Проверка: UPDATE emp SET sal = 8000 WHERE ename = 'SMITH'; 14 SELECT sal FROM emp2 WHERE ename = 'SMITH'; SELECT * FROM jobtotals; COMMIT; SELECT sal FROM emp2 WHERE ename = 'SMITH'; SELECT * FROM jobtotals; Можно заметить, что последний пример позволяет обойти проблему Mutating Trigger при попытке автоматического обновления хранимых агрегатов (например, сумм) после обновления полей с исходными данными. 15 Пример работы с материализованными представлениями. create snapshot прод refresh complete start with sysdate next sysdate+1 as select ид, ФИО, возраст, должность,дата_приема, результат, прод_ид from продавцы where дата_приема between to_date('01.01.2000','dd.mm.rrrr') and to_date('01.01.2006','dd.mm.rrrr'); select ФИО from прод; 16 Приложение. ТАБЛИЦА 1: Параметры сервера для управления и анализа сводной информации. Параметр Описание Рекомендуемое значение JOB_QUEUE_ PROCESSES Включает один или несколько процессов (или потоков) очереди заданий (SNP) для поддержки автоматических обновлений материализованных представлений 1 or 2 JOB_QUEUE_ INTERVAL Определяет количество 60 секунд, в течение которых процессы очереди заданий ожидают проверки очереди заданий Параметры, включающие обновление сводных данных. Параметры, которые включают переписывание запроса OPTIMIZER_MODE Указывает вид оптимизации, используемый по умолчанию при выполнении SQL предложения; для управления сводной информацией необходима оптимизация, основанная на стоимости Для хранилищ данных укажите ALL_ROWS или CHOOSE; для OLTP, укажите FIRST_ROWS QUERY_REWRITE_ENABLED Разрешает переписывание запросов TRUE QUERY_REWRITE_INTEGRITY Определяет насколько актуальным должно быть материализованное представление, чтобы Oracle8i учитывал его при переписывании Значение по умолчанию ENFORCED, обеспечивает согласованность и целостность; STALE_ 17 запроса TOLERATED разрешает переписывать запрос, используя представления, которые не согласованы с лежащими в основе детальными таблицами Определяет функциональную совместимость с версиями Oracle8i 8.1.0 или выше ORACLE_TRACE_ COLLECTION_NAME Указывает имя файла сбора трассировки (trace-collection) oraclsm ORACLE_TRACE_ COLLECTION_PATH Указывает каталог или %ORACLE_HOME% /otrace/admin/cdf папку файла сбора трассировки ORACLE_TRACE_ COLLECTION_SIZE Указывает первоначальный размер файла сбора трассировки 0 ORACLE_TRACE_ ENABLE Включает сбор трассировки Oracle8i TRUE ORACLE_TRACE_ FACILITY_NAME Определяет устройство oraclesm (facility) сбора трассировки ORACLE_TRACE_ FACILITY_PATH %ORACLE_HOME% Указывает местополжение файлов /otrace/admin/cdf описаний для сбора трассировки COMPATIBLE Параметры, которые включают анализ сводок 18 Список литературы: 1. Стив Бобровски «Использование материализованных представлений для ускорения запросов», Журнал Oracle Magazine. 2. «Oracle 8i (Oracle 8.1.5)», http:\\Optim.ru 3. Давида Стенгленда «Расширенная репликация данных», PINNACLE, Oracle Professional, апрель 2002 (Volume 9, Number 4)б http://www.smartaccessnewsletter.com/OP/OPmag.nsf/0/7F7B3812A331EE50 85256B910080F94E 4. Джон Джей Кинг «CUBE, ROLLUP и "материализованные" представления: "добывая" золото Oracle», Oracle Magazine/RU Online, #8/2000 5. Документация из Oracle Database Online Documentation 10g Release 1 (10.1) 19