1. Порівняння таблиць матеріалізованих запитів DB2 в с матеріалізовані уявленнями Oracle
2. Таблиця 1. Таблиця матеріалізованих запитів DB2, перетворена з матеріалізованого уявлення Oracle
3. Команда REFRESH TABLE
4. Лістинг 1. Команда REFRESH TABLE
5. Як виконати DBMS_MVIEW.REFRESH в DB2
6. Регістр CURRENT REFRESH AGE для DEFERRED MQT
7. SET CURRENT REFRESH AGE
8. проміжні таблиці
9. Як MQT-таблиці використовуються DB2-оптимізатором
10. Налаштування прикладу MQT
11. Лістинг 2. Створення базових таблиць прикладу MQT
12. Створення випадкових даних в таблицях
13. Лістинг 3. Вставка даних в базові таблиці прикладу MQT
14. Лістинг 4. Створення збереженої процедури для тестування таблиць
15. Малюнок 6. Текстова пояснює інформація про план
16. Малюнок 7. Відображення плану доступу
17. Лістинг 5. Створення MQT
18. Ресурси для скачування

технічний огляд

В DB2 таблиця матеріалізованих запитів (MQT) являє собою таблицю, визначення якої базується на результатах виконання запиту. По суті, MQT містить попередньо отримані результати, що базуються на даних з таблиць, на основі яких визначено MQT. Якщо компілятор запитів визначає, що запит до MQT буде більш ефективний, ніж до базової таблиці або таблиць, запит виконується до MQT, і результат повертається швидше, ніж в іншому випадку. Ця концепція ідентична концепції матеріалізованих уявлень в Oracle.

Порівняння таблиць матеріалізованих запитів DB2 в с матеріалізовані уявленнями Oracle

В DB2 DDL-синтаксис створення MQT аналогічний синтаксису створення матеріалізованих уявлень в Oracle. Хоча є синтаксичні відмінності. Давайте розглянемо реальне DDL-вираз матеріалізованого уявлення Oracle, перетворене в DB2, і порівняємо розділи тіла вираження (див. таблицю 1 ).

Таблиця 1. Таблиця матеріалізованих запитів DB2, перетворена з матеріалізованого уявлення Oracle

• (1) CREATE TABLE
  DB2 використовує синтаксис CREATE TABLE на відміну від CREATE MATERIALIZED VIEW, використовуваного Oracle. DB2 називає MQT "таблицями", а не "уявленнями", тому і використовує синтаксис CREATE TABLE при їх створенні. DB2 знає про те, що це таблиця матеріалізованих запитів, а не звичайна таблиця, тому що, по-перше, MQT завжди створюються з іншої таблиці або набору таблиць і, по-друге, DDL-вираз створення MQT не вказує в кінці "FOR DEFINITION ONLY ". Якщо ви хочете створити звичайну (НЕ MQT) таблицю, певну з іншої таблиці, використовуйте наступні ключові слова FOR DEFINITION ONLY.
• (2) TABLENAME.SCHEMANAME
  DB2 дозволяє визначити MQT, використовуючи будь-який специфікатор схеми (schema qualifier) ​​і ім'я, яке ви хочете. Як і в Oracle, всьому оператору SELECT, що створює MQT, передує AS.
• (3) AS SELECT
  DB2 використовує оператор SELECT для визначення тіла MQT. Дозволено вибирати підмножини, повні вибірки і навіть з'єднання таблиць. Така ж концепція і в Oracle. Примітка: Існує багато винятків і застережень, що стосуються того, що може бути в DB2 MQT (також як і в Oracle), але в даній статті ці питання не розглядатимуться детально. Чіткі правила створення MQT наведені в документації по DB2.
• (4) DATA INTIALLY DEFERRED
  В DB2 за замовчуванням дані негайно поміщаються в нову MQT під час її створення. Якщо цього не потрібно, потрібно використовувати підкоманду DATA INITIALLY DEFERRED. У Oracle команда BUILD IMMEDIATE теж виконується за замовчуванням, але її можна вказати спеціально, і це часто роблять адміністратори баз даних Oracle. Для прикладу з таблиці 1 дані повинні створюватися негайно при створенні MQT, тому можна видалити параметр DATA INTIALLY DEFERRED з MQT DDL (цей параметр показаний в квадратних дужках, що говорить про його необов'язковість).
• (5) REFRESH [DEFERRED / IMMEDIATE]
  DB2 управляє способом поновлення MQT за допомогою параметра REFRESH [DEFERRED / IMMEDIATE]. У прикладі використовується REFRESH DEFERRED, оскільки вихідне матеріалізоване уявлення Oracle було визначено з підкоманду ON DEMAND, що означає те ж саме. REFRESH DEFERRED в DB2 просто означає, що ви повинні використовувати вираз REFRESH TABLE, для того щоб отримати в MQT найостанніші зміни даних (додаткова інформація наведена в розділі " Команда REFRESH TABLE "). REFRESH IMMEDIATE означає, що DB2 змінює MQT при кожній зміні таблиці або таблиць і не вимагає використання виразу REFRESH TABLE.
  Примітка: В Oracle існує ключове слово FAST, показане в прикладі. Дана функціональна можливість використовує спеціальні log-файли для завершення "дельта-оновлення", що може прискорити цей процес. Для отримання такого "швидкого" поновлення в DB2 ви можете використовувати коректувальну таблицю (staging table) (більш детальна інформація наведена в розділі " проміжні таблиці ").
• (6) MAINTAINED BY [SYSTEM / USER / FEDERATED TOOL]
  DB2 MQT можуть "обслуговуватися" трьома різними способами:
  1. MAINTAINED BY SYSTEM - спосіб за замовчуванням, тому його не обов'язково вказувати в даному DDL-прикладі. Він показаний в квадратних дужках, що вказує про його необов'язковість в даному випадку. Цей спосіб просто означає, що тільки DB2 управляє вмістом MQT на основі параметрів REFRESH (які можуть бути або DEFERRED, або IMMEDIATE).
  2. MAINTAINED BY USER дозволяє DBA виконувати прямі операції INSERT, UPDATES і DELETES в MQT.
  3. MAINTAINED BY FEDERATED TOOL вказує на те, що MQT обслуговується інструментальної програмою реплікації DB2.
• (7) ENABLE QUERY OPTIMIZATION
  DB2 тепер може використовувати MQT в своїх алгоритмах оптимізації запитів, використовуючи ENABLE QUERY OPTIMIZATION. Це поведінка за умовчанням, і воно показано в квадратних дужках, що вказує на нього не обов'язковість в даній ситуації. Існують певні обставини, коли бажано використовувати DISABLE QUERY OPTIMIZATION, але в даній статті ця тема не розглядається.
• (8) IN [TABLE SPACE NAME] INDEXES IN [TABLE SPACE NAME]
  Нарешті, DB2 поміщає дані MQT і індекси MQT в призначені для них табличні простору (table space). Адміністратори бази даних Oracle повинні знати, що в DB2, незалежно від того, базова це таблиця або MQT, при створенні таблиці завжди потрібно визначати табличні простору для даних, індексів і довгих об'єктів (наприклад, lobs або XML).

Команда REFRESH TABLE

Для MQT-таблиць з відкладеним оновленням необхідно вказувати DB2, коли і як виконувати оновлення, оскільки DB2 не робить цього автоматично. Це можна вказати за допомогою команди REFRESH TABLE. Детально дана команда показана в лістингу 1.

Лістинг 1. Команда REFRESH TABLE

Ключові слова INCREMENTAL / NON INCREMENTAL

• INCREMENTAL вказує інкрементне оновлення MQT, що враховує тільки різницю (якщо є) в використовуваних нею таблицях або вміст пов'язаної коректувальною таблиці (якщо вона існує і її вміст несуперечливо). Якщо такий запит не може бути задоволений (тобто система виявляє, що визначення таблиці матеріалізованих запитів вимагає повного перерахунку), повертається помилка (SQLSTATE 55019).
• NON INCREMENTAL виконує повне оновлення MQT.

Ключові слова ALLOW [NO ACCESS / READ ACCESS / WRITE ACCESS]

Ці ключові слова вказують рівень доступу, з яким інші можуть використовувати MQT під час її поновлення:

• ALLOW NO ACCESS - параметр за замовчуванням, що забезпечує найшвидше оновлення MQT. Його назва говорить сама за себе.
• ALLOW READ ACCESS - це наступний за швидкістю оновлення MQT параметр. Під час оновлення MQT можна виконувати операції читання її вмісту, але не можна виконувати з нею призначені для користувача DML-операції.
• ALLOW WRITE ACCESS - це параметр з найповільнішим оновленням. Він дозволяє все DML-операції під час поновлення MQT.

Як виконати DBMS_MVIEW.REFRESH в DB2

Вираз DB2 REFRESH TABLE аналогічно використанню процедури REFRESH пакету Oracle DBMS_MVIEW, як показано нижче.

Приклад повного оновлення:

• Oracle: EXEC DBMS_MVIEW.REFRESH ( 'PROD.DAILYSUM', 'c');
• DB2: REFRESH TABLE PROD.DAILYSUM NON INCREMENTAL;

Приклад інкрементного поновлення:

• Oracle: EXEC DBMS_MVIEW.REFRESH ( 'PROD.DAILYSUM');
• DB2: REFRESH TABLE PROD.DAILYSUM INCREMENTAL;

Регістр CURRENT REFRESH AGE для DEFERRED MQT

Регістр CURRENT REFRESH AGE вказує значення тривалості мітки часу з типом даних DECIMAL (20,6). Це максимальний період часу після певного зафіксованого події, що виник в об'єкті кешованих даних (наприклад, вираз REFRESH TABLE виконало підтримуване системою відкладене оновлення таблиці матеріалізованих запитів), протягом якого цей об'єкт кешованих даних може бути використаний для оптимізації виконання запиту. Якщо значення CURRENT REFRESH AGE одно 99 999 999 999 999, а клас оптимізації запитів дорівнює 5 або більше, типи таблиць, зазначені в CURRENT MAINTAINED TABLE TYPES FOR OPTIMIZATION, враховуються при оптимізації виконання динамічного SQL-запиту.

SET CURRENT REFRESH AGE

При використанні DB2-команди db2 SET CURRENT REFRESH AGE ANY регістр віку поновлення встановлюється в значення 99 999 999 999 999.

Значення CURRENT REFRESH AGE має дорівнювати 0 або 99 999 999 999 999. Початковим значенням є 0. Можна виконати вираз SET CURRENT REFRESH AGE для зміни цього значення.

проміжні таблиці

При визначенні MQT можна визначити другу таблицю, яка буде проміжної таблицею для цієї MQT. Проміжна таблиця дозволяє підтримку інкрементного обслуговування для відкладених MQT. Проміжна таблиця збирає зміни, які повинні бути виконані в MQT для синхронізації її з вмістом використовуваних таблиць. Використання проміжних таблиць усуває конфлікти блокування, що викликаються при запиті негайного поновлення MQT. Також MQT-таблиці більше не потрібно повністю генерувати повторно при виконанні REFRESH TABLE.

Як MQT-таблиці використовуються DB2-оптимізатором

Адміністратори баз даних Oracle вже знають принципи роботи матеріалізованих уявлень, тому давайте розглянемо роботу MQT в DB2. Давайте поглянемо на Control Center, Command Editor, а також текстові та візуальні пояснюють допоміжні програми з точки зору "новачка" з невеликим досвідом використання DB2 і її інструментальних засобів.

Налаштування прикладу MQT

1. Перш за все, запустіть DB2 Control Center. Виберіть Start> All Programs> IBM DB2 General Administration Tools> Control Center.
   DB2 Control Center можна запустити також з командного рядка Windows. Введіть db2cc.
2. Клацніть правою кнопкою миші SAMPLE database> Query. При цьому відкриється редактор Command Editor і підключиться до бази даних SAMPLE.
3. Скопіюйте в командне вікно редактора Command Editor SQL-запит, наведений в лістингу 2 .

   Лістинг 2. Створення базових таблиць прикладу MQT

   - # SET TERMINATOR! DROP TABLE SHIPPING.BILL! DROP TABLE SHIPPING.CHARGE_BILL! CREATE TABLE "SHIPPING". "BILL" ( "BILL_GK" INTEGER NOT NULL, "TD_IND" DOUBLE, "CREATION_TS" TIMESTAMP NOT NULL)! CREATE UNIQUE INDEX "SHIPPING". "IX_BILL" ON "SHIPPING". "BILL" ( "BILL_GK" ASC) ALLOW REVERSE SCANS! CREATE TABLE "SHIPPING". "CHARGE_BILL" ( "BILL_GK" INTEGER NOT NULL, "BILL_CHARGE_IND" INTEGER NOT NULL, "RATE_PRICE" DOUBLE)! ALTER TABLE "SHIPPING". "CHARGE_BILL" ADD CONSTRAINT "PK_CHARGEBILL" PRIMARY KEY ( "BILL_GK", "BILL_CHARGE_IND")!
   Цей запит створює дві таблиці (з відповідним індексуванням) для роботи з прикладом MQT. Зверніть увагу на те, що команда - # SET TERMINATOR може змінити SQL-роздільник, використовуваний в SQL-сценарії, в даному випадку знак оклику (!). Це необхідно зробити при створенні процедур або UDF в DB2. Можна також встановити цей роздільник в Command Editor внизу в поле "Statement termination character", як показано на малюнку 1.

   Малюнок 1. Символ-роздільник виразів

   
4. Встановіть курсор в самий початок SQL-запиту в командному вікні Command Editor і натисніть зелену стрілку для його запуску. Для кожного виразу має відобразитися повідомлення "The SQL command completed successfully" (SQL-команда виконалася успішно).

   Малюнок 2. Команда запуску

   
5. Скопіюйте SQL-вираз з лістингу 3 , Яке вставляє дані в таблиці і збирає статистичну інформацію по ним.

   Створення випадкових даних в таблицях

   Зверніть увагу на вираз INSERT в даному прикладі, яке вставляє випадкові дані в кожну таблицю. При уважному розгляді можна побачити, що це - один вислів INSERT, вставляють 25000 рядків за допомогою тимчасової таблиці з конструкцією WITH. Цей тип рекурсивного SQL-запиту можна використовувати в DB2 для створення прикладів даних.

   Примітки:
   • Для очищення попередньої команди клацніть правою кнопкою миші де-небудь в редакторі Command Editor, виберіть Select all. За допомогою кнопок зі delete для очищення всього обраного.
   • Для очищення панелі результатів клацніть правою кнопкою миші де-небудь в редакторі Command Editor і виберіть Clear results.
   
   Виконайте наступне SQL-вираз.

   Лістинг 3. Вставка даних в базові таблиці прикладу MQT

   - # SET TERMINATOR! INSERT INTO SHIPPING.CHARGE_BILL (BILL_GK, BILL_CHARGE_IND, RATE_PRICE) WITH TEMP1 (R1, R2, R3) AS (VALUES (0, RAND (2), RAND () + (RAND () / 1E5)) UNION ALL SELECT R1 + 1 , RAND (2), RAND () + (RAND () / 1E5) FROM TEMP1 WHERE R1 <25000) SELECT R1, R2 * 23 + 1, DECIMAL (R3 * 99999,7,2) FROM TEMP1! INSERT INTO SHIPPING.BILL (BILL_GK, TD_IND, CREATION_TS) WITH TEMP1 (R1, R2, R3) AS (VALUES (0, RAND (), CURRENT TIMESTAMP) UNION ALL SELECT R1 + 1, RAND (), CURRENT TIMESTAMP FROM TEMP1 WHERE R1 <25000) SELECT R1, R2 * 23 + 1, CURRENT TIMESTAMP FROM TEMP1! RUNSTATS ON TABLE SHIPPING.BILL ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND DETAILED INDEXES ALL! RUNSTATS ON TABLE SHIPPING.CHARGE_BILL ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND DETAILED INDEXES ALL!
6. У Control Center можна перевірити, як виглядають ці таблиці і дані. Клацніть лівою кнопкою миші на каталозі Tables, а потім на стовпці schema для сортування за схемою. Ви повинні знайти дві нові таблиці BILL і CHARGE_BILL під схемою SHIPPING.

   Малюнок 3. Як виглядають таблиці

   
7. Виконайте подвійне клацання лівою кнопкою миші на будь-якій таблиці, щоб побачити дані, що знаходяться в ній.

   Малюнок 4. Відкриття таблиці "Bill"

   
8. Потім ви повинні створити пояснюють таблиці (explain tables) в схемі, для того щоб використовувати функціональні можливості DB2 explain. Знайдіть файл C: \ Program Files \ IBM \ SQLLIB \ MISC \ EXPLAIN.DDL.

   Малюнок 5. Створення пояснюють таблиць

   
9. Скопіюйте вміст файлу EXPLAIN.DDL в Command Editor і виконайте його. Тепер у вашій схемі є що пояснюють таблиці, готові для використання.
10. Скопіюйте SQL-вираз з лістингу 4 і виконайте його.

    Лістинг 4. Створення збереженої процедури для тестування таблиць

    - # SET TERMINATOR! CALL SYSPROC.SET_ROUTINE_OPTS ( 'EXPLAIN YES EXPLSNAP YES')! DROP PROCEDURE SHIPPING.GET_CHARGE_COUNT! CREATE PROCEDURE SHIPPING.GET_CHARGE_COUNT (OUT v_count INTEGER) LANGUAGE SQL BEGIN SET v_COUNT = (SELECT COUNT (*) FROM (SELECT DISTINCT B.RATE_PRICE FROM SHIPPING.CHARGE_BILL B, SHIPPING.BILL C WHERE B.BILL_GK = C.BILL_GK) AS TEMP ); END!
11. Зверніть увагу на те, що ця процедура, що зберігається підраховує всі неоднакові значення RATE_PRICE, загальні для двох таблиць. Протестуйте збережену процедуру за допомогою наступної SQL-команди:
    CALL SHIPPING.GET_CHARGE_COUNT (?)
12. Отже, збережена процедура SHIPPING.GET_CHARGE_COUNT тепер використовує ваші таблиці і має план доступу, збережений в DB2 в так званому "пакеті" DB2 (package). Існує два способи знайти, як виглядає в DB2 цей план доступу, використовуючи різні засоби explain. Першим засобом explain є програма командного рядка db2exfmt, а другим - візуальна програма explain.

Засіб explain в командному рядку:

1. Введіть нижченаведену команду DB2 в вікні команд Windows з будь-якого каталогу диска C :.
   db2exfmt -D SAMPLE -O MQT_EXFMT_BEFORE.TXT -1 Примітка: Це не команда редактора Command Editor, а окрема допоміжна програма DB2, виконувана в операційній системі.
2. Ця команда генерує текстовий файл Windows під назвою beforemqt_exfmt.txt. Ви можете переглянути інформацію, записану в цьому файлі, і побачити, як DB2 звертається до даних в запиті. на малюнку 6 наведено фрагмент цього файлу, який показує, що збережена процедура використовує дві окремі таблиці з запиту.
   Запам'ятайте саме верхнє число в збереженій процедурі, яке позначає загально час виконання запиту (або DB2-витрати). Ми зменшимо це число нижче за допомогою MQT.

   Малюнок 6. Текстова пояснює інформація про план

   

Візуальна програма explain:

1. Тепер перейдемо до візуальної програми explain, в якій ми побачимо ті ж результати, що і при використанні текстової програми. В DB2 Control Center знайдіть і розгорніть дерево каталогів Application Objects. Потім знайдіть і розгорніть Packages.
2. Тепер ми бачимо все пакети в DB2, які зв'язали плани доступу з базою даних SAMPLE. Ми хочемо знайти пакет для щойно створеної збереженої процедури. В даному випадку, оскільки вона є єдиною створеної власником "SHIPPING", її можна легко знайти. Тому перейдіть в єдиний пакет в схемі власника "SHIPPING", як показано на малюнку 7.
   Примітка: Назва пакета генерується DB2 при створенні процедури, що, тому воно в більшості випадків не збігається з наявними у вашій базі даних.
3. Клацніть правою кнопкою миші на цьому пакеті і виберіть Show Explainable Statements.

   Малюнок 7. Відображення плану доступу

   
4. В даному пакеті є тільки одне зрозуміле вираз. Клацніть по ньому правою кнопкою миші і виберіть Show Explained Statement History:

   Малюнок 8. Відображення історії виразів explain

   
5. У пакеті є тільки одна версія цього виразу. Клацніть на ній правою кнопкою миші і виберіть Show Access Plan.

   Малюнок 9. Відображення плану доступу

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

   Малюнок 10. Схема плану доступу

   

Як працюють MQT

Причому тут MQT? Давайте розберемося.

1. Скопіюйте SQL-вирази з лістінгу 5 в вікно Command Editor и запустіть его. При цьому створиться MQT для ваших двох таблиць, показаних в прикладі вище.
   Зверніть увагу на оператор FROM в MQT DDL. Ви вже знаєте, що означає кожна частина цього DDL. Тепер подивимося на його роботу.

   Лістинг 5. Створення MQT

   - # SET TERMINATOR! DROP TABLE SHIPPING.BILL_MQT! CREATE TABLE SHIPPING.BILL_MQT AS (SELECT B.RATE_PRICE, COUNT (*) CNT FROM SHIPPING.CHARGE_BILL B, SHIPPING.BILL C WHERE B.BILL_GK = C.BILL_GK GROUP BY B.RATE_PRICE) DATA INITIALLY DEFERRED REFRESH IMMEDIATE ENABLE QUERY OPTIMIZATION MAINTAINED BY SYSTEM! REFRESH TABLE SHIPPING.BILL_MQT! RUNSTATS ON TABLE SHIPPING.BILL_MQT ON ALL COLUMNS WITH DISTRIBUTION ON ALL COLUMNS AND DETAILED INDEXES ALL!
2. Тепер у нас є три таблиці: дві базові і одна MQT для з'єднання їх обох в підсумкову таблицю. На малюнку 11 показано, як ці три таблиці виглядають в Control Center.

   Малюнок 11. MQT

   
   Зверніть увагу на те, що MQT має тип DB2 "S". Це означає, що це - підсумкова таблиця (summary table). Якщо хочете, можете виконати подвійне клацання лівою кнопкою миші на ній, щоб побачити дані.
3. DB2-оптимізатор тепер буде використовувати цю MQT завжди, коли може її використовувати, замість автоматичного використання базових таблиць. Ваш запит не потрібно міняти для використання MQT.
   Щоб довести це, давайте просто виконаємо перекомпонування пакета для вже створеної збереженої процедури. Ми не будемо міняти SQL-вираз в цьому пакеті, а просто вкажемо DB2 вибрати інший план доступу, оскільки маємо MQT, засновану на двох наших базових таблицях.
   Виконайте наведену нижче команду з Command Editor для очищення пояснюють таблиць:
   - # SET TERMINATOR! DELETE FROM EXPLAIN_INSTANCE! COMMIT! Примітка: Це не обов'язковий крок. Якщо ви цього не зробите, DB2 збереже обидві версії вашого плану доступу в пакеті, але буде використовувати найостанніший після останньої перекомпонування.
4. Тепер виконаємо перекомпонування пакета для збереженої процедури. Виконайте наступну команду в Command Editor:
   CALL REBIND_ROUTINE_PACKAGE ( 'P', 'SHIPPING.GET_CHARGE_COUNT', 'ANY')
5. Якщо код повернення дорівнює 0, перекомпонування пройшла успішно. DB2 тепер змінив SQL в пакеті для використання MQT.
6. Як же це перевірити? Можна виконати наступну команду в командному рядку Windows (не в Command Editor) і згенерувати ще один текстовий файл з новим планом доступу: db2exfmt -D SAMPLE -O MQT_EXFMT_AFTER.TXT -1
7. На малюнку 12 зображено фрагмент цього файлу. Зверніть увагу на те, що тепер MQT використовується пакетом, в свою чергу використовуються збереженої процедурою.

   Малюнок 12. MQT, використовувана оптимізатором

   
8. Можна також використовувати візуальну програму explain, як описано вище (як ви пам'ятаєте, це пакет в дереві Application Objects в Control Center). На малюнку 13 показано, як виглядає план доступу в цій програмі.

   Малюнок 13. Відображення плану доступу

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

Висновок

Таблиця матеріалізованих запитів DB2 аналогічна концепції матеріалізованих уявлень Oracle. У даній статті ви дізналися про практичні відмінності між цими концепціями, а також про роботу MQT в DB2. Тепер ви можете створювати нову базу даних DB2 і впевнено використовувати таблиці DB2 MQT. Більш детальна інформація про таблиці матеріалізованих запитів і про всі темах, розглянутих в даній статті, наведена в DB2 Information Center.

Ресурси для скачування

Схожі теми

• Оригінал статті " Comparing DB2 materialized query tables and Oracle materialized views "(EN).
• " Використання таблиць матеріалізованих запитів для прискорення запитів в DB2 "(EN) (developerWorks, серпень 2002): інформація про те, як використовувати MQT для прискорення запитів.
• " Введення в таблиці матеріалізованих запитів "(EN) (developerWorks, вересень 2005): інформація про MQT, підсумкових таблицях і коригуючих таблицях. За допомогою працюючих прикладів дізнайтеся, як створювати таблиці матеріалізованих запитів і працювати з ними.
• " Підвищення продуктивності WebSphere Information Integrator за допомогою таблиць матеріалізованих запитів "(EN) (developerWorks, травень 2006): дізнайтеся про те, як використання MQT-запитів може підвищити продуктивність інтегрованих систем.
• " Підвищення продуктивності запитів DB2 в корпоративних інтелектуальних середовищах "(DeveloperWorks, травень 2006): підвищення продуктивності запитів в корпоративних інтелектуальних середовищах. Покрокове опис різних методів, експериментування з вашою власною системою.
• DB2 Information Center : Інформація, необхідна для використання сімейства продуктів і функціональних можливостей DB2, а також інформація про продукти та можливості WebSphere Information Integration.
• db2ude: блог Викрама Катрі : Поради та методики роботи з DB2 9.
• розділ Information Management сайту developerWorks: додаткова інформація про управління інформаційними ресурсами. Технічна документація, статті how-to, навчальні матеріали, файли для завантаження і багато іншого.
• DB2 9 Enterprise Edition : Завантажте пробну версію.
• DB2 9 Express-C : Завантажте безкоштовну ліцензію.
• Розробіть ваш наступний проект, використовуючи пробне програмне забезпечення IBM , Доступне для завантаження безпосередньо на сайті developerWorks.

Підпишіть мене на повідомлення до коментарів