Обновление материализованного представления при изменении таблиц urderlying

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

CREATE MATERIALIZED VIEW M_FOO
REFRESH COMPLETE ON COMMIT
AS
    SELECT FOO_ID, BAR
    FROM FOO
    WHERE BAR IS NOT NULL
    GROUP BY FOO_ID, BAR
/

COMMENT ON MATERIALIZED VIEW M_FOO IS 'Foo-Bar pairs';

Я написал как своего рода кэш: исходная таблица огромна, но количество разных пар довольно мало. Мне нужны эти пары, чтобы соединить их с другими столами. Пока все хорошо: это абсолютно ускоряет запросы.

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

  1. какой точный синтаксис мне нужно использовать?

  2. Мне нужно создать овеществленный просмотреть журнал?

  3. в чем разница между fast и полное обновление?

10
materialized-views oracle oracle10g

2 ответов

чтобы ответить на ваши вопросы в обратном порядке

быстрое обновление также известно как инкрементное обновление. Это должно дать вам ключ к различию. Полное обновление перестраивает весь MVIEW с нуля, тогда как быстрое обновление применяет только изменения из DML, исключенные из таблицы(таблиц) фидера.

для выполнения быстрого обновления вам нужен соответствующий журнал MVIEW.

что касается синтаксиса, Ну вот основы:

SQL> create materialized view log on emp
  2  with rowid, primary key, sequence (deptno, job)
  3  including new values
  4  /

Materialized view log created.

SQL> create materialized view emp_mv
  2  refresh fast on commit
  3  as
  4  select deptno, job from emp
  5  group by deptno, job
  6  /

Materialized view created.

SQL>

на ON COMMIT предложение означает, что MVIEW обновляется транзакционно (в отличие от ON DEMAND который является регулярным обновлением навалом). The REFRESH п. указывает, следует ли применять инкрементное или полное обновление. Есть некоторые категории запросов, которые заставляют использовать COMPLETE обновить, хотя они, похоже, уменьшаются с каждой новой версией Oracle.

быстрый тест, чтобы увидеть, что это работает ...

SQL> select * from emp_mv
  2  order by deptno, job
  3  /

    DEPTNO JOB
---------- ---------
        10 MANAGER
        10 PRESIDENT
        10 SALES
        20 ANALYST
        20 CLERK
        20 MANAGER
        30 CLERK
        30 MANAGER
        30 SALESMAN
        40 CLERK
        40 DOGSBODY

11 rows selected.

SQL>

как насчет новой запись?

SQL> insert into emp (empno, ename, deptno, job)
  2  values (6666, 'GADGET', 40, 'INSPECTOR')
  3  /

1 row created.

SQL> commit
  2  /

Commit complete.

SQL> select * from emp_mv
  2  order by deptno, job
  3  /

    DEPTNO JOB
---------- ---------
        10 MANAGER
        10 PRESIDENT
        10 SALES
        20 ANALYST
        20 CLERK
        20 MANAGER
        30 CLERK
        30 MANAGER
        30 SALESMAN
        40 CLERK
        40 DOGSBODY

12 rows selected.

SQL>

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

19

быстрое обновление будет только вставлять/обновлять / удалять измененные данные в материализованное представление. Полное обновление опустошит материализованное представление, а затем скопирует все строки.

"on commit" означает, что материализованное представление будет обновляться всякий раз, когда изменение фиксируется в главной таблице. Таким образом, ваш текущий синтаксис будет крайне неэффективным. Каждый раз, когда кто-то изменяет любую строку в foo, m_foo будет усечен, а затем каждая строка в таблице foo будет вставленный.

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

создать материализованный журнал просмотра foo с первичным ключом; -- предполагая, что у вас есть первичный ключ, вы должны создать материализованный вид m_foo быстро обновить при фиксации как\;

есть некоторые дополнительные тонкости с грантами и синонимами, если вы используете ссылки на БД, или схема, которой принадлежит foo, не тот, который владеет m_foo.

8