Матеріалізовані уявлення Oracle і переписування запитів, Інші СУБД, Бази даних, статті

РЕЗЮМЕ

Сьогодні бази даних, незалежно від того, чи є вони сховищами або вітринами даних або ж системами OLTP, містять величезну кількість інформації, яка чекає, щоб її виявили та зрозуміли. Однак своєчасне знаходження і подання цієї інформації може стати головною проблемою, особливо, коли для цього необхідно переглянути величезну кількість даних. Матеріалізовані уявлення допомагають вирішити цю проблему, пропонуючи засоби для доступу до таких даних і дуже швидкого отримання звіту по ним.

ВСТУП

Матеріалізовані уявлення були вперше введені в Oracle8i. Вони є частиною компонента, відомого як Summary Management (управління підсумками). Цілком імовірно, що у вас матеріалізовані уявлення вже використовуються, але відомі вони під іншою назвою, наприклад, як підсумкові (або зведені) таблиці. Нижче ми обговоримо, як створювати і керувати матеріалізованими уявленнями, і як функціональність переписування запитів прозоро перезаписує SQL-запит, щоб в ньому були використані матеріалізовані уявлення для поліпшення часу відповіді на запит. Це дозволяє користувачам бази даних навіть не знати про те, які саме матеріалізовані уявлення існують.

Матеріалізоване уявлення слід уявляти собі як спеціальний вид уявлення, яке фізично існує в базі даних. В це подання можуть бути включені з’єднання та / або складові значення (агрегати). Можна сказати, що воно існує для поліпшення часу виконання запиту шляхом попереднього обчислення дорогих з’єднань і операцій агрегування ще до їх виконання в реальному запиті.

Сьогодні організації, які отримують свої результати, витрачають даремно значний час, створюючи підсумки вручну, визначаючи, які уявлення створювати, індексуючи підсумки, оновлюючи їх і радячи користувачам, які з них використовувати.

Тепер же АБД повинен всього лише спочатку створити матеріалізоване уявлення, після чого воно може автоматично оновлюватися кожного разу, коли з його джерелами даних відбуваються зміни. Крім того, є компонент SQL Access Advisor, який рекомендує АБД, які матеріалізовані уявлення слід створити, видалити або зберегти.

Одне з найбільших переваг від використання матеріалізованих представлень заслужено відмічено користувачами сховищ і баз даних. Більше їм не доведеться задавати АБД питання про те, які матеріалізовані подання існують. Замість цього вони можуть писати свої запити до таблиць або уявлень з бази даних. А потім механізм перезапису запитів в сервері Oracle автоматично перезапише SQL-запит таким чином, щоб у ньому використовувалися матеріалізовані уявлення, істотно поліпшуючи тим самим час відповіді на запит і усуваючи потребу кінцевого користувача в знанні про існування підсумкових даних.

ЯК ВИКОРИСТОВУВАТИ УПРАВЛІННЯ ПІДСУМКАМИ

Запитайте будь-якого кінцевого користувача, що він хоче отримати від сховища даних і, найбільш імовірно, що він відповість – швидку й точну інформацію. Це являє гостру проблему для проектувальників сховищ даних, тому що для того, щоб відповісти на питання: “яку кількість продукту x ми продаємо в місці розташування y “, Потрібно забезпечити швидкий доступ до даних, якщо, звичайно, ми не бажаємо читати кожен рядок таблиці.

Одне з найбільш поширених рішень, використовуваних для вирішення цієї проблеми, полягає в тому, щоб створити підсумкові таблиці, або як їх називають в Oracle, матеріалізовані уявлення. Для цього потрібно спочатку оцінити типову робоче навантаження, а потім створити набагато менші за розміром матеріалізовані уявлення, які можуть містити з’єднання та / або агрегати з необхідною інформацією. Наприклад, матеріалізоване уявлення для відповіді на попереднє запитання могло б містити лише по одному рядку для кожного продукту з розбивкою по регіонах і обсягами продажів. Отже, якщо компанія продала 2000 продуктів в 5 місцях, то максимальна кількість рядків, які необхідно прочитати для отримання відповіді на запит, завжди буде дорівнює 10 000, незалежно від того, скільки саме предметів було продано.

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

Сьогодні в багатьох обчислювальних центрах створюються свої власні підсумкові таблиці, тому серед додаткових вигод, які можна отримати, завдяки використанню Oracle Summary Management, можна назвати наступні:



КОМПОНЕНТИ УПРАВЛІННЯ ПІДСУМКАМИ
Управління підсумками (Summary Management) складається з п’яти компонентів, а саме:



Не потрібно, щоб всі вони були використані одночасно, але максимальне перевага буде досягнуто при виборі для використання як можна більшої кількості компонентів. Розглянемо ці компоненти більш докладно.

Вимоги до схеми

Не існує жодних обмежень на тип або дизайн схеми, яка може бути використана для матеріалізованих представлень. Отже, в середовищах сховищ даних схема може мати дизайн типу Snowflake (Сніжинка), але це не є вимогою.

Для проектувальника бази даних, який знайомий з методиками проектування баз даних в промислових системах, може виявитися несподіваним, що для сховищ даних повинні використовуватися інші правила і методики. Наприклад, промислові бази даних зазвичай нормалізуються, отже, в цьому випадку найбільш ймовірно, що подання виміру часу призведе до появи трьох таблиць – для дати (date), місяця (month) і року (year). Мають бути умови сполуки, які з’єднують кожен рядок дати з одного, і лише одним рядком місяці, а кожен рядок місяця з однієї, і лише одним рядком року . Реалізація ж сховища даних, як правило, призводить до повністю денормалізованной таблиці для виміру часу (time), де стовпці дати, місяця і року перебувають в одній і тій же таблиці. Однак ви можете використовувати матеріалізовані уявлення незалежно від того, чи використовуються в дизайні проекту нормалізовані або денормалізованние таблиці.


Виміри


Перший крок перед створенням матеріалізованих представлень полягає в огляді схеми та визначенні вимірювань. Вимірювання (dimension) є об’єктом Oracle, який визначає ієрархічні (батько / нащадок) відносини між стовпцями, де всі стовпці не зобов’язані бути стовпцями однієї і тієї ж таблиці. Настійно рекомендується, щоб для даних були визначені вимірювання, тому що вони допомагають при переписуванні запитів, і консультант з підсумками (summary advisor) може прийняти більш обгрунтовані рішення.

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

На рис. 1 наведено приклад виміру Time (Час), містить дві ієрархії. При заданій датою одна з ієрархій повідомляє нам, на яку фінансову тиждень (або місяць або рік) посилається ця дата, а інша ієрархія визначає відносини між днем, місяцем, кварталом і роком.

Для опису ієрархії при її визначенні може бути ідентифіковано багато стовпців. Наприклад, якщо стовпець City (місто) унікальний в межах кожного State (штат), але не унікальний для різних States, то ієрархія Geography (географія), можливо, повинна бути визначена як (City, State, ), щоб задовольнити жорстким ієрархічним відносинам 1:n від рівня City до рівня State.

Для створення вимір може бути використаний один з двох методів:

  • Оператор CREATE DIMENSION SQL, як показано на Рис. 2

  • Майстер вимірювань в Oracle Enterprise Manager

  • Зображення вимірювання згідно рис.1 може допомогти АБД в процесі визначення. Кожен “бульбашка” представляє рівень у вимірі і оголошений c використанням фрази LEVEL. Ієрархія вимірювання оголошена з використанням фрази HIERARCHY. Управління підсумками також спирається на певні АБД обмеження, щоб гарантувати, що стовпці кожного рівня в рівні ієрархії є непорожніми (non-null).

    На рис.2 ми бачимо SQL-оператор, який створює цей вимір. Ім’я рівня відповідає стовпцях в таблицях вимірювання. Потім кожна ієрархія описується з використанням цих імен рівня. Нарешті, використовується фраза ATTRIBUTE, щоб визначити ті елементи, які мають прямі відносини. Отже, у атрибута calendar_month_name є зв’язок з рівнем місяць.

    Рис. 2. SQL-оператор для створення вимірювання Time
    CREATE DIMENSION times_dim
    LEVEL day IS TIMES.TIME_ID
    LEVEL month IS TIMES.CALENDAR_MONTH_DESC
    LEVEL quarter IS TIMES.CALENDAR_QUARTER_DESC
    LEVEL year IS TIMES.CALENDAR_YEAR
    LEVEL fis_week IS TIMES.WEEK_ENDING_DAY
    LEVEL fis_month IS TIMES.FISCAL_MONTH_DESC
    LEVEL fis_quarter IS TIMES.FISCAL_QUARTER_DESC
    LEVEL fis_year IS TIMES.FISCAL_YEAR
    HIERARCHY cal_rollup (day CHILD OF month CHILD OF quarter CHILD OF year
    HIERARCHY fis_rollup (day CHILD OF fis_week CHILD OF fis_month CHILD OF    fis_quarter CHILD OF fis_year)
    ATTRIBUTE day DETERMINES (day_number_in_week, day_name, day_number_in_month, calendar_week_number)
    ATTRIBUTE month DETERMINES (calendar_month_desc, calendar_month_number, calendar_month_name, days_in_cal_month, end_of_cal_month)
    ATTRIBUTE quarter DETERMINES(calendar_quarter_desc, calendar_quarter_number, days_in_cal_quarter, end_of_cal_quarter)
    ATTRIBUTE year DETERMINES (calendar_year, days_in_cal_year, end_of_cal_year)
    ATTRIBUTE fis_week DETERMINES (week_ending_day, fiscal_week_number) ;

    Відносини з’єднання 1: n між вимірами оголошуються з використанням фрази JOIN KEY, а між таблицею фактів і таблицею виміру вони представлені з обмеженнями FOREIGN KEY і NOT NULL для таблиці фактів.

    В Oracle Database 10g Release 2 також можливо при визначенні вимірювання специфікувати, що рівень в ієрархії повинен бути проігнорований.
    Використання підказок при визначенні вимірювань
    Нижче наводиться кілька простих кроків, які допомагають при створенні вимірювань.



    1. Ідентифікуйте в схемі всі виміри і таблиці вимірів. Якщо вимірювання нормалізовані, тобто, зберігаються в кількох таблицях, то слід перевірити, щоб з’єднання між таблицями вимірювання гарантувало, що кожен рядок з дочірньою боку з’єднується з однією і тільки з одним рядком з батьківської сторони. У разі денормалізованних вимірювань перевірте, щоб стовпці на дочірньою стороні унікально визначали стовпці (або атрибути) на батьківській стороні. Відмова від дотримання цих правил може призвести до повернення із запиту неправильних результатів. Наприклад, ієрархія типу calendar_week CHILD_OF calendar_month може повернути неправильні результати, тому що calendar_week (календарна тиждень) може включати два календарних місяці.

    2. Ідентифікуйте ієрархії всередині кожного вимірювання. Наприклад, day (день) є нащадком month (місяця) (ми можемо агрегувати дані рівня day до month), а quarter (квартал) є нащадком year (Року).

    3. Ідентифікуйте залежності атрибутів в межах кожного рівня ієрархії. Наприклад, ідентифікуйте, що calendar_month_name є атрибутом місяці.

    4. Ідентифікуйте з’єднання таблиці фактів в сховище даних c кожним виміром і перевірте, що кожне з’єднання може гарантувати, що кожен рядок фактів з’єднується з одного, і лише одним рядком вимірювання. Ця умова має бути оголошено і (за бажанням користувача) може бути введено його примусове виконання шляхом додавання обмежень FOREIGN KEY і NOT NULL для стовпців ключа таблиці фактів і обмежень PRIMARY KEY для ключів з’єднання на батьківській стороні. Ці обмеження можна активувати, використовуючи опцію NOVALIDATE, щоб уникнути втрат часу, пов’язаних з верифікацією того факту, що кожен рядок в таблиці відповідає обмеженням. Крім того, для всіх непідтверджених обмежень потрібно фраза RELY, щоб зробити їх придатними для використання в переписуванні запитів.

    Матеріалізувати УЯВЛЕННЯ

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

    У визначення матеріалізованого уявлення ( materialized view ) Можуть бути включені функції агрегування, а саме: SUM, MIN, MAX, AVG, COUNT (*), COUNT (x), COUNT (DISTINCT), VARIANCE або STDDEV, одна або декілька об’єднаних таблиць і операція GROUP BY. Воно може бути індексувати і секціонірована, до нього можуть бути застосовані основні операції DDL, типу CREATE, ALTER і DROP.
    Оскільки матеріалізоване уявлення є об’єктом бази даних, у багатьох відношеннях воно веде себе як індекс, тому що:



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

    Створення матеріалізованого подання
    Для створення матеріалізованого подання використовується оператор CREATE MATERIALIZED VIEW. Рис. 3 ілюструє створення матеріалізованого уявлення, яке називається costs_mv і обчислює суму costs в розрізі time і prod_nam.

    Рис. 3. SQL-оператор для створення матеріалізованого подання


    CREATE MATERIALIZED VIEW costs_mv
    PCTFREE 0 STORAGE (initial 8k next 8k pctincrease 0)
    BUILD IMMEDIATE
    REFRESH FAST ON DEMAND
    ENABLE QUERY REWRITE
    AS SELECT
    time_id, prod_name, SUM ( unit_cost) AS sum_units,
    COUNT (unit_cost) AS count_units, COUNT(*) AS cnt
    FROM costs c, products p
    WHERE c.prod_id = p.prod_id
    GROUP BY  time_id,   prod_name;


    Після визначення матеріалізованого подання необхідно слідувати декільком простим керівним принципам. У списку SELECT повинні міститися всі стовпці GROUP BY, а стовпці GROUP BY повинні бути простими стовпцями. Підмет агрегації вираз може бути будь-яким виробляє значення SQL-виразом, який не містить підзапитів або вкладених агрегатних функцій.

    Матеріалізоване уявлення може мати свою власну специфікацію зберігання, щоб можна було визначити, в якому табличному просторі воно має бути збережено і розмір його екстентів. Можна також включити фразу про секціонуванні (partitions), щоб контент матеріалізованого уявлення міг зберігатися в багатьох табличних просторах.

    У визначенні матеріалізованого уявлення можуть використовуватися і таблиці, і уявлення. У застосуванні до попереднього прикладу це означає, що вартість (costs) може бути таблицею, а продукт (product) – Виставою. Може використовуватися будь подання, за умови, що в його визначенні не міститься змінюваних користувачем за допомогою функцій типу SYSDATE і USER даних.

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

    Існуючі раніше таблиці можуть бути зареєстровані як матеріалізовані уявлення шляхом використання в операторі CREATE MATERIALIZED VIEW фрази ON PREBUILT TABLE. Ім’я матеріалізованого подання повинно бути тим же самим, що й ім’я таблиці. Крім того, обов’язково має бути запропонована фраза SELECT, що описує створює цю таблицю запит. Не завжди є можливість гарантування, що точність запиту відповідає точності таблиці. Щоб подолати цю проблему, в специфікацію включена фраза WITH REDUCED PRECISION.

    Вибір індексів для матеріалізованих представлень
    Залежно від числа рядків в матеріалізованому представленні може виявитися необхідно створити для матеріалізованих представлень індекси. Тому спочатку слід розглянути питання про створення унікального локального індексу, який містить всі ключі матеріалізованого уявлення. Інші індекси можуть для кожного стовпця ключа матеріалізованого уявлення включати бітові індекси по одному стовпцю. Потребується для швидкого оновлення індекс автоматично створюється при першому визначенні матеріалізованого уявлення. Створюючи індекси, не забувайте враховувати вимоги до дискової пам’яті кожного індексу і той вплив, який ці індекси будуть надавати на час оновлення. Якщо ви не впевнені, які саме індекси слід створити, то подумайте про використання SQL Access Advisor, щоб дізнатися, що порекомендує він.

    Що може зробити матеріалізоване уявлення?
    До створення матеріалізованого уявлення (або відразу після його створення) АБД може задатися питанням, що можна зробити з цим матеріалізованим поданням; скажімо, чи можна його швидко відновити, а якщо ні, то чому. Таку інформацію може запропонувати процедура DBMS_MVIEW.EXPLAIN_MVIEW.

    Перейдемо до створеного (див. Рис. 3) матеріалізованому поданням. Якщо ми видалимо з визначення COUNT (*) і потім викличемо процедуру DBMS_MVIEW.EXPLAIN_MVIEW, як це показано на рис. 4, то дізнаємося, що доступний механізм відстеження змін розділу (PCT), тому що таблиця вартостей (costs) секціонірована і що можливі всі типи переписування запитів. Однак після операцій DML швидке оновлення неможливо, тому що з матеріалізованого уявлення виключена операція COUNT (*).

    Рис. 4. Приклад з виконанням матеріалізованого подання


    TRUNCATE TABLE  mv_capabilities_table;
    EXEC DBMS_MVIEW.EXPLAIN_MVIEW (” SELECT  time_id,
    prod_name, SUM ( unit_cost) AS sum_units, COUNT
    (unit_cost) AS count_units, FROM costs c,
    products p WHERE c.prod_id = p.prod_id GROUP BY
    time_id, prod_name”);
    SELECT capability_name, possible, related_text, msgtxt
    FROM mv_capabilities_table;
    PCT_TABLE: Y      COSTS:
    PCT_TABLE: N      PRODUCTS:   relation is not a
    partitioned table
    REFRESH_COMPLETE: Y
    REFRESH_FAST: Y
    REFRESH_FAST_AFTER_ANY_DML: N    see the reason why
    REFRESH_FAST_AFTER_ONETAB_DML is disabled
    REFRESH_FAST_AFTER_INSERT: Y
    REFRESH_FAST_AFTER_ONETAB_DML: N    COUNT(*) is not
    present in the select list
    REFRESH FAST PCT: Y
    REWRITE: Y
    REWRITE_FULL_TEXT_MATCH: Y
    REWRITE_GENERAL: Y
    REWRITE_PARTIAL_TEXT_MATCH: Y
    REWRITE_PCT: Y


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

    Звернімося ще раз до матеріалізованих поданням, наведеному на рис. 3. З EXPLAIN_MVIEW ми знаємо, що швидке оновлення неможливо, якщо у визначенні відсутній COUNT (*). Якщо це матеріалізоване подання запропоновано як вхідні дані для TUNE_MVIEW, як це показано на рис. 5, то воно згенерує нове визначення матеріалізованого подання, показане на рис. 6.

    Рис. 5. Приклад налаштування матеріалізованого подання

    CREATE DIRECTORY TUNE_RESULTS AS “/tuning/”;
    GRANT READ, WRITE ON DIRECTORY TUNE_RESULTS TO PUBLIC;
    VARIABLE task_mv VARCHAR2 (30);
    VARIABLE create_mv_ddl VARCHAR2 (4000);
    EXECUTE :task_mv := “cust_mv”;
    EXECUTE :create_mv_ddl := ” –
    CREATE MATERIALIZED VIEW cust_mv –
    REFRESH FAST   ENABLE QUERY REWRITE AS –
    SELECT  time_id, prod_name, SUM ( unit_cost) AS
    sum units, COUNT (unit cost) AS count units –
    FROM costs c, products p GROUP BY time_id, prod_name”
    WHERE c.prod_id = p.prod_id GROUP BY time_id,prod_name”);
    EXECUTE DBMS_ADVISOR.TUNE_MVIEW (:task_mv,:create_mv_ddl);


    Рекомендації, отримані з процедури TUNE_MVIEW, зберігаються в задачі консультанта. Їх можна легко знайти, якщо викликати процедуру GET_TASK_SCRIPT і розмістити їх у файлі, використовуючи процедуру CREATE _FILE, як показано нижче.

    EXECUTE DBMS_ADVISOR.CREATE_FILE –
    (DBMS_ADVISOR.GET_TASK_SCRIPT (:task_mv), –
    “TUNE_RESULTS”, “mv_create.sql”);


    На рис. 6 показані повні вихідні дані TUNE_MVIEW, куди включені новий оператор матеріалізованого подання та необхідні журнали матеріалізованого уявлення.


    Рис. 6. Рекомендації з процедури TUNE_MVIEW

    CREATE MATERIALIZED VIEW LOG ON “SH”.”COSTS” WITH ROWID, SEQUENCE(“TIME_ID”,”UNIT_COST”) INCLUDING NEW VALUES;
    ALTER MATERIALIZED VIEW LOG FORCE ON “SH”.”COSTS”
    ADD ROWID, SEQUENCE(“TIME_ID”,”UNIT_COST”)
    INCLUDING NEW VALUES;
    CREATE MATERIALIZED VIEW LOG ON “SH”.”PRODUCTS”
    WITH ROWID, SEQUENCE(“PROD_NAME”) INCLUDING NEW VALUES;
    ALTER MATERIALIZED VIEW LOG FORCE ON “SH”.”PRODUCTS”
    ADD ROWID, SEQUENCE(“PROD_NAME”) INCLUDING NEW VALUES;
    CREATE MATERIALIZED VIEW SH.CUST_MV
    REFRESH FAST WITH ROWID
    ENABLE QUERY REWRITE
    AS SELECT SH.PRODUCTS.PROD_NAME Cl, SH.COSTS.TIME_ID C2,
    SUM(“SH”.”COSTS”.”UNIT_COST”) M1,
    COUNT(“SH”.”COSTS”.”UNIT_COST”) M2, COUNT(*) M3 FROM
    SH.PRODUCTS, SH.COSTS
    GROUP BY SH.PRODUCTS.PROD_NAME, SH.COSTS.TIME_ID;


    Щоб можна було використовувати TUNE_MVIEW, повинен бути визначений шлях до каталогу з використанням команди CREATE DIRECTORY, яка визначає, де будуть зберігатися результати. Повний оператор CREATE MATERIALIZED VIEW передається на вхід TUNE_MVIEW, а результати його виконання зберігаються в унікальній завданню.

    Визнання матеріалізованого уявлення недійсним


    Матеріалізовані уявлення постійно піддаються контролю, гарантуючи, що містяться в них дані є оновленими ( fresh – Свіжі). Визнання матеріалізованого уявлення недійсним ( invalidating ) гарантує, що не будуть повернуті неприпустимі дані. Матеріалізоване уявлення буде відзначено як застаріле (stale) при всякому зміні його базового об’єкта.


    Стан матеріалізованого подання може бути визначено запитом до таблиці USER_MVIEWS. Якщо який-небудь стовпчик цієї таблиці має значення NEEDS_COMPILE (НЕОБХОДІМА_КОМПІЛЯЦІЯ), видайте команду ALTER MATERIALIZED VIEW COMPILE, щоб оновити його поточний статус.


    Наслідки порушення безпеки


    До деякої інформації з бази даних можливий тільки обмежений доступ, і переписування запитів можна розглядати як механізм для обходу захисту. Однак, так як вся перевірка захищеності виконується в Oracle Database, забезпечується набагато глибша захист даних і матеріалізованих представлень. Для запобігання несанкціонованого доступу до матеріалізованим уявленням або до таблиць фактів з використанням CREATE MATERIALIZED VIEW потрібно привілей CREATE MATERIALIZED VIEW, привілей SELECT WITH GRANT для таблиці фактів і привілеї SELECT WITH GRANT і INSERT для матеріалізованого подання містить об’єкт. Крім того, якщо користувач має доступ до використовуваних в запиті таблиць, і для цих таблиць було визначено одне або кілька матеріалізованих представлень, то користувачеві надано доступ до матеріалізованим уявленням незалежно від привілеїв, зазначених для матеріалізованого подання, що включає таблиці. Тому, незалежно від джерела походження запиту, доступ до даних можливий тільки в тому випадку, якщо успішно пройдені перевірки безпеки.


    ЗАВАНТАЖЕННЯ І РЕГЕНЕРАЦІЯ Матеріалізувати УЯВЛЕННЯ


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


  • повного оновлення даних

  • виконання швидкого оновлення, тобто, додавання / злиття тільки змін

  • автоматичного оновлення матеріалізованого подання в разі виконання будь-яких змін

  • Тому АБД повинен передбачити, скільки часу потрібно для створення і обслуговування кожного матеріалізованого уявлення, і зіставити з підвищенням виробничих показників, що досягається при використанні цього матеріалізованого уявлення.


    В Oracle Database 10g передбачено такі методи оновлення:


  • повне

  • швидке (застосовуються тільки зміни)

  • примусове: якщо це можливо, зробіть швидке оновлення, інакше виконайте повне оновлення

  • з використанням механізму відстеження змін розділів (швидке оновлення рядків тільки в змінених розділах)

  • Ці операції можуть бути виконані:

  • на вимогу – оновлення:


  • при фіксації транзакцій – при всякому зміні таблиць, через які визначено матеріалізоване уявлення.

  • Оновлення ON DEMAND (на вимогу) досягається шляхом виклику однієї зі згаданих вище процедур; при цьому АБД передається повний контроль над тим, коли слід оновлювати матеріалізоване уявлення.


    Якщо буде обраний метод поновлення ON COMMIT, то всякий раз, коли матеріалізоване уявлення буде порушено змінами, зробленими над вихідними даними, матеріалізоване уявлення буде автоматично оновлено, щоб відобразити ці зміни. Однак потрібно пам’ятати, що таке оновлення матеріалізованого уявлення відбувається як частина обробки фіксації транзакції, в рамках якої проводилися зміни базової таблиці. Тому фіксація транзакції займе трохи більше часу, тому що зміни робляться і в оригінальній таблиці, і в кожному матеріалізованому представленні, у визначення якого включена ця таблиця.


    Повне оновлення


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


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

  • для матеріалізованого подання немає індексу, який можна було б використовувати для злиття

  • час, потрібний для виконання швидкого оновлення, перевищує час повного оновлення

  • Швидке оновлення


    Деякі матеріалізовані уявлення можуть бути настільки великими, що вимагається для регулярного виконання повного оновлення часом може виявитися неприпустимо великим. Альтернативою повного оновлення є так зване швидке оновлення, при якому до матеріалізованих поданням застосовуються тільки зміни в таблиці фактів. Визначаються нові дані, які були завантажені в будь-яку таблицю сховища, і будь матеріалізоване уявлення, що посилається на цю таблицю, буде автоматично оновлено новими даними.


    Щоб виконати операцію швидкого оновлення, зміни, зроблені над даними, повинні бути зареєстровані. Досягти цього можна одним із двох способів. Якщо дані коли-небудь були вставлені в базу даних з використанням прямого режиму завантаження SQL * Loader, то механізм оновлення виявить це і ідентифікує знову завантажені дані. Однак багато зміни даних відбуваються в результаті виконання SQL-команд INSERT, UPDATE і DELETE. В цьому випадку для кожної з таблиць, на яких базуються матеріалізовані уявлення, потрібно MATERIALIZED VIEW LOG (журнал матеріалізованого подання).


    Для кожної таблиці потрібно тільки один журнал матеріалізованого уявлення, і ці журнали будуються для таблиці, а не для матеріалізованого уявлення. Тому, якби в базі даних є 6 змінюються таблиць, то потрібно всього 6 журналів матеріалізованих представлень. Але за допомогою цих журналів можна побудувати будь-яке число матеріалізованих представлень.


    Необхідно відзначити, що не всі матеріалізовані уявлення можуть бути швидко оновлюються, і підтвердження того, чи є можливим швидке оновлення матеріалізованого подання, може бути отримано шляхом виклику процедури DBMS_MVIEW.EXPLAIN_MVIEW. Ця процедура також повідомить, що потрібно зробити з матеріалізованим поданням, щоб воно стало швидко оновлюваним. Потім можна викликати процедуру TUNE_MVIEW, щоб згенерувати сценарій, який, якщо це виявиться можливим, покаже, як зробити матеріалізоване уявлення швидко оновлюваним.


    Оновлення за допомогою механізму відстеження змін секції


    В Oracle Database 10g пропонується компонент, відомий як механізм відстеження змін секції (Partition Change Tracking – PCT), який прозоро виявляє, коли в секції відбуваються зміни, а потім визначає, чи не зробила ця операція суперечливими дані в матеріалізованих поданні. Наприклад, операції злиття або додавання секцій не будуть зачіпати матеріалізоване уявлення і можуть бути виконані, причому матеріалізоване уявлення не повинно бути зазначено, як застаріле.


    Механізм відстеження змін секції може бути також використаний для визначення того, які рядки матеріалізованого подання порушені операціями секціонування. Наприклад, якщо буде скорочуватися або віддаляється секція таблиці фактів, процедура швидкого оновлення може використовувати PCT, щоб ідентифікувати в матеріалізованому представленні порушені строки і видалити їх. Якщо таблиці, на яких базується матеріалізоване уявлення, секціонірована, і потрібне швидке оновлення, то може бути виконано оновлення за допомогою механізму відстеження змін секції (PCT), якщо буде вирішено, що цей механізм краще, ніж швидке оновлення на базі журналу матеріалізованих представлень. В Oracle Database 10g Release 2 знято обмеження, яке вимагало, щоб був журнал матеріалізованих уявлень для таблиці PCT, якщо потрібне швидке оновлення.


    Коли виконується оновлення PCT, ідентифікуються секції, де дані змінилися, і повторно обчислюється вміст лише цих секцій. Тому, якщо у таблиці є багато секцій, а зміни піддалася тільки одна (або кілька) секцій, оновлення PCT може виявитися дуже швидким методом поновлення матеріалізованого уявлення найостаннішими даними. Процедура DBMS_MVIEW.EXPLAIN_MVIEW повідомить вам, чи може матеріалізоване уявлення використовувати PCT.


    Оновлення та обмеження


    Раніше було заявлено, що в ідеалі для таблиці фактів мають бути визначені обмеження, особливо, обмеження зовнішнього ключа, щоб гарантувати, що рядок у таблиці фактів може бути зіставлена ​​з виміром. При одному лише згадуванні слова “обмеження” деякі АБД можуть підняти руки в повітря і оголосити, що в їхній базі даних не буде ніяких обмежень через можливі накладних витрат на продуктивність. Однак АБД може бути впевнений, що при використанні фрази


    ALTER TABLE <ім'я таблиці> ENABLE NOVALIDATE CONSTRAINT <ім'я>


    обмеження можна активувати негайно, без перевірки даних. Якщо дані завантажені в таблицю фактів з використанням прямого режиму завантаження SQL * Loader, то за замовчуванням всі обмеження є заблокованими. Після завантаження таблиці фактів видання активуючого оператора NOVAIIDATE негайно активує обмеження без виконання перевірки даних. Тому відсутня хоч би то не було вплив на час завантаження даних, і не потрібно часу на активацію обмежень. Однак, так як не проводиться ніякої перевірки правильності завантажуваних даних, дуже важливо гарантувати, що всі файли дані не будуть порушувати ніяких обмежень цілісності, і що включена фраза RELY, так що обмеження буде використовуватися Summary Management.


    Доступність даних


    Навіть у процесі оновлення даних матеріалізовані уявлення як і раніше залишаються доступними для атомарних (atomic) оновлень і швидких оновлень на базі журналу. При переписуванні запитів будь матеріалізоване уявлення, яке в цей час оновлюється, буде проігноровано.


    Переписування ЗАПИТІВ


    Одним з головних переваг використання управління підсумками, яке буде дійсно оцінений кінцевими користувачами, є функціональність переписування запитів ( query rewrite ). Так називається методика оптимізації запиту, яка перетворює користувальницький запит, написаний в термінах таблиць і уявлень, щоб він виконувався швидше за рахунок вибірки даних з матеріалізованих уявлень. Ця методика повністю прозора для кінцевих користувачів, не вимагає ніякого втручання або внесення підказок у прикладні SQL-пропозиції, тому що Oracle Database автоматично перепише будь-які відповідні прикладні SQL так, щоб у них використовувалися матеріалізовані уявлення. Хоча всі посилання в цьому документі ставляться до SQL-фразі SELECT, переписування запитів в рівній мірою стосується і до операторів INSERT і CREATE TABLE, в які включена фраза SELECT.


    Переписування запитів може використовуватися для широкого спектра запитів. Необхідно зазначити, що для відносин, оголошених в об’єктах вимірювання, не потрібно вводити їх примусового виконання, але при виконанні в режимах QUERY_REWRITE_INTEGRITY = TRUSTED або ENFORCED передбачається, що вони є істинними. Якщо оголошення відносин не відповідає фактичним відносинам, які існують в даних таблиці, то в тих випадках, коли при переписуванні запитів використовується некоректне оголошення відносин, переписаний запит, найімовірніше, буде продукувати неправильний результат. Однак, якщо визначити відносини і використовувати обмеження таким чином, щоб система могла гарантувати правильність даних, можна розраховувати, що в згенерованих звітах будуть міститися правильні результати. Швидкі і точні результати виконання запиту – це істотні переваги, які є результатом мінімальних зусиль і накладних витрат, потрібних для примусового здійснення цілісності системи.


    Склад запиту не повинен в точності відповідати визначенню матеріалізованого уявлення, тому що для цього потрібно було б, щоб АБД знав заздалегідь, які запити до даних будуть виконуватися. Це, звичайно, неможливо, особливо по відношенню до сховищ даних, де одним з основних переваг для організації повинна бути можливість “раптово” виконати новий запит. Тому переписування запитів відбувається навіть у тому випадку, якщо використання матеріалізованого уявлення може задовольнити тільки частини запиту.


    Активація / відключення переписування запитів


    Для того щоб переписування запитів працювало, його потрібно активувати як для матеріалізованого уявлення, так і для сеансу, хоча в Oracle Database 10g цей режим включений за умовчанням. Можна активувати режим для матеріалізованого подання шляхом використання фрази ENABLE QUERY REWRITE в операторі CREATE або ALTER MATERIALIZED VIEW.
    Відключити переписування запитів для вашого сеансу можна за допомогою оператора


    ALTER SESSION SET QUERY_REWRITE_ENABLED = FALSE
    або для всіх сеансів з допомогою


    ALTER SYSTEM SET QUERY_REWRITE_ENABLED = FALSE
    або використовуючи фразу DISABLE QUERY REWRITE для певного матеріалізованого уявлення.


    Типи переписування запитів


    В Oracle Database 10g можливі різні типи переписування запитів, і наступні нижче приклади ілюструють частина того, що стає можливим при використанні матеріалізованого уявлення, показаного на рис. 7.


    Рис. 7. Приклад матеріалізованого подання для переписування запитів


    CREATE MATERIALIZED VIEW all_cust_sales_mv
    BUILD IMMEDIATE
    REFRESH COMPLETE
    ENABLE QUERY REWRITE
    AS  SELECT   c.cust_id, sum (s.amount_sold) AS dollars,
    p.prod_id,  sum (s.quantity_sold) as quantity
    FROM  sales s , customers c, products p
    WHERE c.cust_id = s.cust_id AND s.prod_id = p.prod_id
    GROUP BY  c.cust_id, p.prod_id;


    Точна відповідність


    Найпростіший вид переписування запитів має місце, коли визначення матеріалізованого уявлення точно відповідає визначенню запиту. Тобто, таблиці у фразі FROM з’єднуються у фразі WHERE, а ключі у фразі GROUP BY точно відповідають запиту з одного боку і матеріалізованих поданням з іншого боку. Якщо, наприклад, заданий наступний запит:


    SELECT c.cust_id,  sum (s.quantity_sold) as quantity
    FROM   sales s , customers c, products p WHERE 
    c.cust_id = s.cust_id AND s.prod_id = p.prod_id GROUP
    BY  c.cust_id, p.prod_id;


    то він буде переписаний Oracle Database 10g так, щоб в ньому було використано матеріалізоване уявлення all_cust_sales_mv.


    Повторне підключення


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


    SELECT  c.cust_last_name,
    sum (s.quantity_sold) as quantity
    FROM  sales s , customers c, products p
    WHERE c.cust_id = s.cust_id AND s.prod_id = p.prod_id
    GROUP BY  c.cust_last_name, p.prod_id;


    Цей запит посилається на стовпець c. cust_last_name, який не включений в матеріалізоване уявлення all_cust_sales_mv, але c.cust_last_name функціонально залежить від c.cust_id через ієрархічних відносин між ними. Це означає, що цей запит може бути переписаний в термінах all_cust_sales_mv, з яким повторно з’єднується таблиця замовників, щоб можна було отримати стовпець c.cust_last_name.


    Операція ROLLUP для згорток і агрегатних значень


    Коли в запиті фігурують агрегати типу SUM (sales), відповідні більш високих рівнів в ієрархії, ніж рівень, на якому зберігаються агрегати в матеріалізованих поданні, то запит може бути переписаний за допомогою використання матеріалізованого уявлення і скочування його агрегатів до бажаного рівня.


    Наприклад, у нашому матеріалізованому представленні all_cust_sales_mv дані групуються на рівні замовників, але ми хочемо отримати звіт за даними на рівні штату. Було створено вимір customer (замовник), яке описує відносини між замовником і штатом. Тому в наведеному нижче запиті матеріалізоване уявлення all_cust_sales_mv буде використано для генерації звіту, в якому будуть агреговані всі дані для замовника, а потім всі вони будуть згорнуті до рівня штату.


    SELECT c.cust_state_province,
    sum (s.quantity_sold) as quantity
    FROM sales s , customers c, products p
    WHERE c.cust_id = s.cust_id AND s.prod_id = p.prod_id
    GROUP BY     c.cust_state_province;


    Підмножини даних


    Коли в матеріалізованому представленні містяться всі дані, це може привести до істотного збільшення його розміру. Тому буває корисно визначити матеріалізоване уявлення, в якому міститься тільки підмножину даних, як показано на рис. 8, де ми маємо дані тільки для міст Дублін, Голуей, Гамбург і Стамбул.


    Рис. 8. Матеріалізоване уявлення, що містить підмножина даних


    CREATE MATERIALIZED VIEW some_cust_sales_mv
    BUILD IMMEDIATE
    REFRESH COMPLETE
    ENABLE QUERY REWRITE
    AS
    SELECT   c.cust_id, sum (s.amount_sold) AS dollars,
    p.prod_id, sum(s.quantity_sold) as quantity
    FROM  sales s , customers c, products p
    WHERE c.cust_id = s.cust_id AND s.prod_id = p.prod_id
    AND   c.cust_state_province IN (“Dublin”,”Galway”,”Hamburg”,”Istanbul”)
    GROUP BY  c.cust_id, p.prod_id;


    Це матеріалізоване уявлення може тепер використовуватися для задоволення запитів, що містять діапазони, фрази IN і BETWEEN, типу показаного нижче запиту.


    SELECT c.cust_state_province,
    sum(s.quantity_sold) as quantity
    FROM  sales s , customers c, products p
    WHERE c.cust_id = s.cust_id AND s.prod_id = p.prod_id
    AND     c.cust_state_province IN (“Dublin”,”Galway”)
    GROUP BY  c.cust_state_province;


    Використання декількох матеріалізованих представлень


    Іноді єдине матеріалізоване уявлення, яке могло б використовуватися для отримання результатів запиту, відсутня, але переписування запитів стає можливим, якщо можна об’єднати результати декількох матеріалізованих представлень. Такий тип переписування запитів став можливий в Oracle Database 10g Release 2.


    Припустимо, що є три матеріалізованих уявлення, в яких зафіксовані записи про продажі по регіонах EMEA, APAC і обох Америк. На рис. 9 показаний запит, який використовує два з числа цих матеріалізованих представлень для складання звіту про продажі у Великобританії і США.


    Рис. 9. Переписування запитів з використанням декількох матеріалізованих представлень


    CREATE MATERIALIZED VIEW emea_sales_mv
    BUILD IMMEDIATE
    REFRESH COMPLETE
    ENABLE QUERY REWRITE
    AS
    SELECT   c.cust_id, sum(s.amount_sold) AS dollars,
    p.prod_id, sum(s.quantity_sold) as quantity
    FROM  sales s , customers c, products p
    WHERE c.cust_id = s.cust_id AND s.prod_id = p.prod_id
    AND   c.country_id IN (52779, 52789,52770,52777)
    GROUP BY  c.cust_id, p.prod_id;
    CREATE MATERIALIZED VIEW americas_sales_mv
    BUILD IMMEDIATE
    REFRESH COMPLETE
    ENABLE QUERY REWRITE
    AS
    SELECT   c.cust_id, sum(s.amount_sold) AS dollars,
    p.prod_id, sum(s.quantity_sold) as quantity
    FROM  sales s , customers c, products p
    WHERE c.cust_id = s.cust_id AND s.prod_id = p.prod_id
    AND   c.country_id IN (52790, 52772,52773)
    GROUP BY  c.cust_id, p.prod_id;


    Покажемо продажу по продуктах для США і Великобританії. Цей запит буде перезаписаний, щоб використовувати матеріалізовані уявлення americas-sales_ mv і emea_ sales_ mv.


    SELECT   c.country_id, t.country_name,
    sum(s.amount_sold) AS dollars, p.prod_id,
    sum(s.quantity_sold) as quantity
    FROM  sales s , customers c, products p , countries t
    WHERE c.cust_id = s.cust_id AND s.prod_id = p.prod_id
    AND       c.country_id  IN   (52790,   52789)   and
    c.country_id=t.country_id
    GROUP BY     c.country_id,   p.prod_id,   t.country_name;


    Режими цілісності при переписуванні запитів


    У різних користувачів можуть матися різні вимоги до якості даних, з цієї причини в Oracle Database 10 g підтримуються три рівні цілісності, обрані відповідно до значень параметра
    QUERY_REWRITE_INTEGRITY:



    Режим STALE_TOLERATED є найменш обмежуючим. В цьому режимі оптимізатор використовує ті ж самі довірчі відносини, що і для режиму TRUSTED, а, крім того, буде використовувати навіть ті матеріалізовані уявлення, про які відомо, що вони є застарілими.

    В режимі TRUSTED оптимізатор вважає, що добровільні (тобто, не введені в примусовому порядку – прим. Пер.) Відносини, типу оголошених у вимірах і обмеженнях RELY, є коректними. В цьому режимі оптимізатор використовує також попередньо підготовлені матеріалізовані уявлення, навіть якщо оптимізатор не може підтвердити, що вміст матеріалізованого уявлення фактично збігається з результатами, повернутими визначальним запитом матеріалізованого уявлення.

    В режимі ENFORCED, який є значенням за замовчуванням, оптимізатор, використовує тільки ті матеріалізовані уявлення, про які відомо, що в них містяться свіжі дані; крім того, оптимізатор використовує тільки підтверджені відносини. Тому можна виявити, що переписування запитів не відбувається з використанням цього методу, але замість цього використовуються в меншій мірі обмежують режими TRUSTED або STALE_TOLERATED.

    Чи є результати правильними?

    Всякий раз, коли в SQL-запиті використовуються матеріалізовані уявлення, а не дійсне джерело даних, зустрічаються випадки, коли повертаються результати запитів можуть бути різними.



    1. Матеріалізоване уявлення може бути не синхронізовано з детальними даними. Зазвичай це відбувається тому, що процедура поновлення очікує завершення обробки і був обраний режим цілісності STALE_TOLERATED.

    2. Для стовпців з’єднання може порушуватися посилальна цілісність. В цьому випадку деякі рядки рівня нащадків не згортаються точно в один рядок батьківського рівня. Щоб уникнути подібної ситуації використовуйте введене на системному рівні примусове підтримку цілісності, накладні витрати на забезпечення якої незначні, а переваги вельми істотні.

    3. Якщо створено ковзне матеріалізоване уявлення, в якому міститься інформація про рядках, більш неприсутність в детальних даних. Наприклад, матеріалізоване уявлення може містити дані за 18 місяців, але в таблиці фактів при цьому містяться дані тільки за останні 6 місяців. Тому, якби коли-небудь запит було поставлене до базової таблиці, а не до матеріалізованих поданням, то були б показані відрізняються результати.

    План виконання переписування

    При використанні переписування запитів самими часто задаються питаннями є наступні: “буде цей запит переписаний?” і “чому цей запит не був переписаний?”. На ці питання можна відповісти, якщо скористатися процедурою DBMS_MVIEW.EXPLAIN_REWRITE, приклад використання якої показаний нижче на рис. 10. Отже, що цікавить нас інформація може стати відомою ще до першого виконання запиту.

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

    Запит до REWRITE_TABLE можна зробити безпосередньо через SQL, але можна відформатувати вихідні дані за допомогою демонстраційного файлу smxrw. sql , Що проілюстровано на рис. 10. У наведеному нижче прикладі видно, що для цього запиту використовується матеріалізоване уявлення all_cust_sales_mv. Крім того, також показаний переписаний запит і вартість обробки, що проводиться перед виконанням запиту і після нього.

    Рис. 10. Приклад плану виконання переписування

    set serveroutput on
    DECLARE
    querytxt VARCHAR2(1500) := “SELECT c.cust_id,
    sum(s.quantity_sold) as quantity FROM   sales s ,
    customers c, products p WHERE  c.cust_id = s.cust_id
    AND s.prod_id = p.prod_id GROUP BY  c.cust_id,
    p.prod_id”;
    BEGIN
    SYS.XRW (“”, “QUERY_TXT, REWRITTEN_TXT,
    QUERY_BLOCK_NO, COSTS”, querytxt);
    END;
    =======================================================================
    —————————— ANALYSIS OF QUERY REWRITE—————
    “QRY BLK#:0
    ” MESSAGE : QSM-01209: query rewritten with materialized view,
    ALL_CUST_SALES_MV, using text match algorithm
    ” QUERY    : SELECT c.cust_id, sum(s.quantity_sold) as quantity FROM
    sales s , customers c, products p WHERE c.cust_id = s.cust_id AND s.prod_id =
     p.prod_id GROUP BY c.cust_id, p.prod_id
    ” RW QUERY: SELECT ALL_CUST_SALES_MV.CUST_ID, ALL_CUST_SALES_MV.QUANTITY QUANTITY FROM
    SH.ALL_CUST_SALES_MV
    ” ORIG COST: 4203.03120092711
    RWCOST: 164.901117031229
    ========================================= END OF MESSAGES

    SQL ACCESS ADVISOR

    Коли в перший раз приймається рішення про використання матеріалізованих представлень, повинен бути визначений початковий набір уявлень. Раніше це могло стати справжньою проблемою для АБД, особливо, якщо вони не дуже добре знали бізнес, або якщо надходять з програми запити були дуже непередбачуваними. Схожа проблема часто виникає в базі даних, які індекси повинні бути в ній створені.

    Щоб допомогти у вирішенні цієї проблеми, в Summary Management включений компонент, який називається SQL Access Advisor і який може бути запущений або шляхом виклику однієї з багатьох процедур із пакета DBMS_ADVISOR, або з Oracle Enterprise Manager. Він може запропонувати наступну інформацію:



    Перед використанням SQL Access Advisor АБД повинен виконати процедуру DBMS_STATS, щоб зібрати інформацію про кардинальності (кількості елементів) для таблиць і матеріалізованих представлень в базі даних. Ця інформація використовується як частина процесу передбачення.


    Надання робочого навантаження


    Хоча SQL Access Advisor може дати рекомендації про матеріалізованих уявленнях без робочого навантаження, найкраще він працює, коли йому надаються дані про робочого навантаження, які в Oracle Database 10g можуть бути запропоновані в одній з форм:



    Використання певної користувачем робочого навантаження увазі збереження запитів в таблиці бази даних. Потім ці дані будуть прочитані SQL Access Advisor і використані як робоче навантаження.

    Альтернативно, в робоче навантаження можуть бути перетворені поточні запити з кеша SQL, які використовуються як вхідні дані для SQL Access Advisor.

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

    Фільтрація робочих навантажень

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

    Рекомендація матеріалізованих представлень та індексів

    Вся інформація, яка потрібна для генерації набору рекомендацій, і фактичні рекомендації, зберігаються в задачі. Рекомендації про те, які матеріалізовані уявлення та індекси слід створити, можуть бути отримані двома способами. Один підхід полягає в тому, щоб в середовищі Oracle Enterprise Manager використовувати Майстер SQL Access Advisor, який проведе вас крок за кроком через процес рекомендації матеріалізованих представлень і фактично реалізує ці рекомендації.

    Альтернативно, рекомендації можуть бути згенеровані за допомогою виклику процедури EXECUTE_TASK. Незалежно від обраного методу, SQL Access Advisor рекомендує видалити або зберегти існуючі матеріалізовані подання та індекси, а також, якщо це необхідно, створити нові.

    Реалізація рекомендацій

    Одне з багатьох переваг використання Майстра SQL Access Advisor, полягає в тому, що після розгляду рекомендацій, можна вибрати, які з них повинні бути реалізовані, а Enterprise Manager спланує завдання для їх реалізації.

    Альтернативно, для створення SQL-файлу, в якому будуть міститися потрібні для реалізації цих рекомендацій оператори, можна викликати процедури GET_TASK_SCRIPT і CREATE_FILE.


    ВИСНОВОК


    Будь-якому, хто прагне підвищити продуктивність запитів в сховищах даних або в базах даних, слід серйозно розглянути питання про реалізацію матеріалізованих представлень, якщо вони допоможуть попередньо обчислити результати деяких запитів. Для створення матеріалізованих представлень потрібні мінімальні зусилля, а SQL Access Advisor повідомить вам, які матеріалізовані уявлення необхідно створити, і навіть запропонує сценарій виконання своїх рекомендацій. Відразу після створення, матеріалізовані уявлення можуть стати фактично самопідтримуються, і кінцеві користувачі побачать значне поліпшення часу відповіді на запити, для досягнення якого їм не довелося змінювати жодного рядка SQL.

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


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

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *