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

Question

Я материализованное представление определяется следующим образом:

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. В чем разница между быстрым и полным обновлением?

Answer 1

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

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

Для выполнения повторных обновлений FAST необходим соответствующий MVIEW LOG.

Что касается синтаксиса, а вот основы:

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, регулярное обновление в объеме). В статьях 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> 

Вы можете найти более подробную информацию о синтаксисе в the SQL Reference. Также стоит прочитать Materialized View chapter in the Data Warehousing Guide.

Answer 2

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

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

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

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

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