Виведені таблиці з збереженим результатом. Частина 2

Частина 1

Зміст

• Синхронізація зі змінами у вихідних даних
  
  
  
  • Явна оновлення отриманих даних
    
  • Неявно оновлення даних
    
  • Журнали базових таблиць
    
  • Завдання схеми оновлення
    
    
    
    • Вказівка обсягу обчислень при оновленні
      
    • Зазначення часу оновлення
  
  
• Інші споживчі властивості
  
  
  
  • Створення з відкладеним побудовою результату
    
  • Створення на основі наявних даних
    
  • Джерела даних

Синхронізація зі змінами у вихідних даних

Синхронізація утворених при створенні 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”)

Інші значення параметра 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.

(Для більш екзотичних об'єктних таблиць можна ще вказувати 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;

Різний обсяг інформації, що включається до журналу, може бути затребуваний різними схемами оновлення. Деякі схеми оновлення можуть вимагати включення до складу рядків журналу певних полів, а деякі – Ні.

Завдання схеми оновлення

Вказівка обсягу обчислень при оновленні

Синтаксично для вказівки методу поновлення використовуються наступні ключові слова у фразі 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;

Приклад показує, що економне оновлення агрегують зберігається результату можливо тільки при виконанні деяких умов на повноту журнальної таблиці.

Зазначення часу оновлення

Синтаксичні конструкції фрази 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”;

SELECT sal FROM emp2 WHERE ename = “SMITH”;

SELECT * FROM jobtotals;

COMMIT;

SELECT sal FROM emp2 WHERE ename = “SMITH”;

SELECT * FROM jobtotals;

Можна помітити, що останній приклад дозволяє обійти проблему Mutating Trigger при спробі автоматичного поновлення збережених агрегатів (наприклад, сум) після оновлення полів з вихідними даними.

Інші споживчі властивості

Створення з відкладеним побудовою результату

Фраза BUILD IMMEDIATE (умолчательную) у реченні CREATE MATERIALIZED VIEW повідомляє, що сам зберігається результат буде вирахувано автоматично негайно після створення materialized view. Фраза BUILD DEFERRED повідомляє, що обчислення зберігається результату відбудеться пізніше, при виконанні першого оновлення:

CREATE MATERIALIZED VIEW ім'я BUILD DEFERRED AS SELECT …

Створення на основі наявних даних

Фраза ON PREBUILT TABLE дозволяє сформувати зберігається результат без початкового обчислення, на основі збереженої таблиці з тією ж структурою, або незначно відрізняється. Нижче наводиться простий приклад першого варіанту:

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;

Джерела даних

Подібно звичайним іменованих виведеним таблиць, materialized views можуть базуватися не тільки на збережених таблицях, але і, в свою чергу, на виведених: як views, так і materialized views.

Схожі статті:

• Горизонтальне і вертикальне центрування контейнера (0)
• Що нового в DB2 Viper (0)
• Контроль запитів за допомогою SQL Monitor. (0)
• «Розумний» SQL (0)
• Причини переходу від BDE до ADO (0)
• Вчимо говорити по-російськи: AllFusion Component Modeler (раніше Paradigm Plus) (0)
• Використання веб-сервісів в Internet Explorer (0)

---

Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

ЕasyСode