РЕЗЮМЕ
Сегодня базы данных, независимо от того, являются ли они хранилищами или витринами данных или же системами OLTP, содержат огромное количество информации, которая ждет, чтобы ее обнаружили и поняли. Однако своевременное нахождение и представление этой информации может стать главной проблемой, особенно, когда для этого необходимо просмотреть огромное количество данных. Материализованные представления помогают решить эту проблему, предлагая средства для доступа к таким данным и очень быстрого получения отчета по ним.
ВВЕДЕНИЕ
Материализованные представления были впервые введены в Oracle8i. Они являются частью компонента, известного как Summary Management (управление итогами). Вполне вероятно, что у вас материализованные представления уже используются, но известны они под другим названием, например, как итоговые (или сводные) таблицы. Ниже мы обсудим, как создавать и управлять материализованными представлениями, и как функциональность переписывания запросов прозрачно перезаписывает SQL-запрос, чтобы в нем были использованы материализованные представления для улучшения времени ответа на запрос. Это позволяет пользователям базы данных даже не знать о том, какие именно материализованные представления существуют.
Материализованное представление следует представлять себе как специальный вид представления, которое физически существует в базе данных. В это представление могут быть включены соединения и/или составные значения (агрегаты). Можно сказать, что оно существует для улучшения времени выполнения запроса путем предварительного вычисления дорогостоящих соединений и операций агрегирования еще до их выполнения в реальном запросе.
Сегодня организации, получающие свои результаты, тратят впустую значительное время, создавая итоги вручную, определяя, какие представления создавать, индексируя итоги, обновляя их и советуя пользователям, какие из них использовать.
Теперь же АБД должен всего лишь первоначально создать материализованное представление, после чего оно может автоматически обновляться всякий раз, когда с его источниками данных происходят изменения. Кроме того, имеется компонент SQL Access Advisor, который рекомендует АБД, какие материализованные представления следует создать, удалить или сохранить.
Одно из самых больших преимуществ от использования материализованных представлений заслуженно замечено пользователями хранилищ и баз данных. Больше им не придется задавать АБД вопросы о том, какие материализованные представления существуют. Вместо этого они могут писать свои запросы к таблицам или представлениям из базы данных. А потом механизм перезаписи запросов в сервере Oracle автоматически перезапишет SQL-запрос таким образом, чтобы в нем использовались материализованные представления, существенно улучшая тем самым время ответа на запрос и устраняя потребность конечного пользователя в знании о существовании итоговых данных.
КАК ИСПОЛЬЗОВАТЬ УПРАВЛЕНИЕ ИТОГАМИ
Спросите любого конечного пользователя, что он хочет получить от хранилища данных и, наиболее вероятно, что он ответит - быструю и точную информацию. Это представляет острую проблему для проектировщиков хранилищ данных, потому что для того, чтобы ответить на вопрос: 'какое количество продукта x мы продаем в местоположении y ' , требуется обеспечить быстрый доступ к данным, если, конечно, мы не желаем читать каждую строку таблицы.
Одно из наиболее распространенных решений, используемых для решения этой проблемы, состоит в том, чтобы создать итоговые таблицы, или как их называют в Oracle, материализованные представления. Для этого требуется сначала оценить типичную рабочую нагрузку, а затем создать намного меньшие по размеру материализованные представления, которые могут содержать соединения и/или агрегаты с требуемой информацией. Например, материализованное представление для ответа на предыдущий вопрос могло бы содержать всего по одной строке для каждого продукта с разбивкой по регионам и объемам продаж. Следовательно, если компания продала 2000 продуктов в 5 местах, то максимальное количество строк, которые необходимо прочесть для получения ответа на запрос, всегда будет равно 10 000, независимо от того, сколько именно предметов было продано.
Очевидно, материализованное представление должно оставаться точным, и эта методика обеспечивает, что конечному пользователю теперь нужно прочесть так немного строк, что результаты будут всегда получаться очень быстро. Поскольку объемы баз данных уже приближаются к терабайтам данных, для улучшения времени ответа на запрос все более и более важно становится использовать такие методы, как этот.
Сегодня во многих вычислительных центрах создаются свои собственные итоговые таблицы, поэтому среди дополнительных выгод, которые можно получить, благодаря использованию Oracle Summary Management, можно назвать следующие:
- механизм переписывания запросов в сервере Oracle прозрачен, он использует материализованное представление, даже если материализованное представление всего лишь частично соответствует требованиям запроса;
- переписывание усложненных запросов, когда одно материализованное представление может использоваться для отчетов на различных уровнях агрегирования, например, для отчетов за неделю, месяц и год;
- автоматический механизм обновления материализованных представлений, причем одним запросом могут быть обновлены все материализованные представления;
- АБД не придется расходовать время на то, чтобы узнать, какое следует создать материализованное представление. Вместо этого им предоставлена информация о необходимых итогах, полученная на основании предыдущих запросов к базе или хранилищу данных
КОМПОНЕНТЫ УПРАВЛЕНИЯ ИТОГАМИ
Управление итогами (Summary Management) состоит из пяти компонентов, а именно:
- Dimensions (измерения)
- Materialized Views (материализованные представления)
- Refresh (обновление)
- Query Rewrite (переписывание запросов)
- SQL Access Advisor
Не требуется, чтобы все они были использованы одновременно, но максимальное преимущество будет достигнуто при выборе для использования как можно большего числа компонентов. Рассмотрим эти компоненты более подробно.
Требования к схеме
Не существует никаких ограничений на тип или дизайн схемы, которая может быть использована для материализованных представлений. Следовательно, в средах хранилищ данных схема может иметь дизайн типа Snowflake (снежинка), но это не является требованием.
Для проектировщика базы данных, который знаком с методиками проектирования баз данных в промышленных системах, может оказаться неожиданным, что для хранилищ данных должны использоваться другие правила и методики. Например, промышленные базы данных обычно нормализуются, следовательно, в этом случае наиболее вероятно, что представление измерения времени приведет к появлению трех таблиц - для даты ( date), месяца ( month) и года ( year). Должны быть условия соединения, которые соединяют каждую строку даты с одной, и только одной строкой месяца , а каждую строку месяца с одной, и только одной строкой года . Реализация же хранилища данных, как правило, приводит к полностью денормализованной таблице для измерения времени ( time) , где столбцы даты, месяца и года находятся в одной и той же таблице. Однако вы можете использовать материализованные представления вне зависимости от того, используются ли в дизайне проекта нормализованные или денормализованные таблицы.
Измерения
Первый шаг перед созданием материализованных представлений состоит в обзоре схемы и определении измерений. Измерение ( dimension) является объектом Oracle, который определяет иерархические (родитель/потомок) отношения между столбцами, где все столбцы не обязаны быть столбцами одной и той же таблицы. Настоятельно рекомендуется, чтобы для данных были определены измерения, потому что они помогают при переписывании запросов, и консультант по итогам (summary advisor) может принять более обоснованные решения.
Другая проблема проектировщика базы данных состоит в том, что часто запросы не включают непосредственно столбец измерения, но ссылаются на связанные с измерением столбцы, например, запрос ссылается на вторник, а не на определенную дату. Поэтому в том случае, если определены измерения, также должны быть описаны отношения между столбцами измерения и другими столбцами в таблице.
На рис. 1 приведен пример измерения Time (Время), содержащего две иерархии. При заданной дате одна из иерархий сообщает нам, на какую финансовую неделю (или месяц или год) ссылается эта дата, а другая иерархия определяет отношения между днем, месяцем, кварталом и годом.
Для описания иерархии при ее определении может быть идентифицировано много столбцов. Например, если столбец City ( город) уникален в пределах каждого State (штат) , но не уникален для различных States, то иерархия Geography (география), возможно, должна быть определена как ( City, State, < City, State>) , чтобы удовлетворить жестким иерархическим отношениям 1:n от уровня City до уровня State .
Для создания измерение может быть использован один из двух методов:
Изображение измерения согласно рис.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 также возможно при определении измерения специфицировать, что уровень в иерархии должен быть проигнорирован.
Использование подсказок при определении измерений
Ниже приводится несколько простых шагов, помогающих при создании измерений.
- Идентифицируйте в схеме все измерения и таблицы измерений. Если измерения нормализованы, то есть, хранятся в нескольких таблицах, то следует проверить, чтобы соединение между таблицами измерения гарантировало, что каждая строка с дочерней стороны соединяется с одной и только с одной строкой с родительской стороны. В случае денормализованных измерений проверьте, чтобы столбцы на дочерней стороне уникально определяли столбцы (или атрибуты) на родительской стороне. Отказ от соблюдения этих правил может привести к возвращению из запроса неправильных результатов. Например, иерархия типа calendar_week CHILD_OF calendar_month может возвратить неправильные результаты, потому что calendar_week (календарная неделя) может включать два календарных месяца.
- Идентифицируйте иерархии внутри каждого измерения. Например , day (день ) является потомком month (месяца) (мы можем агрегировать данные уровня day до month), а quarter (квартал) является потомком year (года).
- Идентифицируйте зависимости атрибутов в пределах каждого уровня иерархии. Например, идентифицируйте, что calendar_month_name является атрибутом месяца.
- Идентифицируйте соединения таблицы фактов в хранилище данных 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.
Поскольку материализованное представление является объектом базы данных, во многих отношениях оно ведет себя как индекс, потому что:
- поставленная перед материализованным представлением задача состоит в том, чтобы увеличить производительность выполнения запроса;
- существование материализованного представления прозрачно для прикладных SQL-запросов, и АБД может в любое время создавать или удалять материализованные представления, не затрагивая прикладных SQL;
- материализованное представление занимает (дисковую) память и должно обновляться после каждого изменения основообразующих таблиц фактов.
Во многих вычислительных центрах уже имеются хранилища данных, где были определены свои собственные итоги. Поэтому вместо того, чтобы в обязательном порядке заставлять пользователей восстанавливать итоговые таблицы с чистого листа, существующие итоги можно зафиксировать для использования при переписывании запросов.
Создание материализованного представления
Для создания материализованного представления используется оператор 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 предлагаются следующие методы обновления:
Эти операции могут быть выполнены:
- конкретных материализованных представлений (DBMS_MVIEW.REFRESH)
- материализованных представлений, зависящих от таблицы (DBMS_MVIEW.REFRESH_DEPENDENT)
- всех материализованных представлений (DBMS_MVIEW.REFRESH_ALL_MVIEWS)
Обновление ON DEMAND (по требованию) достигается путем вызова одной из упомянутых выше процедур; при этом АБД передается полный контроль над тем, когда следует обновлять материализованное представление.
Если будет выбран метод обновления ON COMMIT, то всякий раз, когда материализованное представление будет затронуто изменениями, произведенными над исходными данными, материализованное представление будет автоматически обновлено, чтобы отразить эти изменения. Однако нужно помнить, что такое обновление материализованного представления происходит как часть обработки фиксации транзакции, в рамках которой производились изменения базовой таблицы. Поэтому фиксация транзакции займет немного больше времени, потому что изменения делаются и в оригинальной таблице, и в каждом материализованном представлении, в определение которого включена эта таблица.
Полное обновление
Когда происходит полное обновление материализованного представления, все данные из него удаляются, а затем перезагружаются. Трудоёмкость операции существенно зависит от размера материализованного представления. Полное обновление материализованного представления может считаться хорошей методикой для использования в тех случаях, когда:
Быстрое обновление
Некоторые материализованные представления могут быть настолько большими, что требующееся для регулярного выполнения полного обновления время может оказаться недопустимо большим. Альтернативой полному обновлению является так называемое быстрое обновление, при котором к материализованному представлению применяются только изменения в таблице фактов. Определяются новые данные, которые были загружены в любую таблицу хранилища, и любое материализованное представление, ссылающееся на эту таблицу, будет автоматически обновлено новыми данными.
Чтобы выполнить операцию быстрого обновления, изменения, сделанные над данными, должны быть зарегистрированы. Достигнуть этого можно одним из двух способов. Если данные когда-либо были вставлены в базу данных с использованием прямого режима загрузки 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
- ENFORCED (значение по умолчанию)
Режим STALE_TOLERATED является наименее ограничивающим. В этом режиме оптимизатор использует те же самые доверительные отношения, что и для режима TRUSTED, а, кроме того, будет использовать даже те материализованные представления, про которые известно, что они являются устаревшими.
В режиме TRUSTED оптимизатор полагает, что добровольные (то есть, не введенные в принудительном порядке - прим. пер . ) отношения, типа объявленных в измерениях и ограничениях RELY, являются корректными. В этом режиме оптимизатор использует также предварительно подготовленные материализованные представления, даже если оптимизатор не может подтвердить, что содержимое материализованного представления фактически совпадает с результатами, возвращенными определяющим запросом материализованного представления.
В режиме ENFORCED, который является значением по умолчанию, оптимизатор, использует только те материализованные представления, про которые известно, что в них содержатся свежие данные; кроме того, оптимизатор использует только подтвержденные отношения. Поэтому можно обнаружить, что переписывание запросов не происходит с использованием этого метода, но вместо этого используются в меньшей степени ограничивающие режимы TRUSTED или STALE_TOLERATED.
Являются ли результаты правильными?
Всякий раз, когда в SQL-запросе используются материализованные представления, а не действительный источник данных, встречаются случаи, когда возвращаемые результаты запросов могут быть разными.
- Материализованное представление может быть не синхронизировано с детальными данными. Обычно это происходит потому, что процедура обновления ожидает завершения обработки и был выбран режим целостности STALE_TOLERATED.
- Для столбцов соединения может нарушаться ссылочная целостность. В этом случае некоторые строки уровня потомков не свертываются точно в одну строку родительского уровня. Чтобы избежать подобной ситуации используйте введенное на системном уровне принудительное поддержание целостности, накладные расходы на обеспечение которой незначительны, а преимущества весьма существенны.
- Если создано скользящее материализованное представление , в котором содержится информация о строках, более неприсутствующих в детальных данных. Например, материализованное представление может содержать данные за 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 могут быть предложены в одной из форм:
- Определенная пользователем (DBMS_ADVISOR.IMPORT_SQLWKLD_USER)
- Набор настройки SQL (DBMS_ADVISOR.IMPORT_SQLWKLD_STS)
- Текущее содержимое кэша SQL (DBMS_ADVISOR.IMPORT_SQLWKLD_SQLCACHE)
- Рабочая нагрузка Summary Advisor 9i (DBMS_ADVISOR.IMPORT_SQLWKLD_SUMADV)
Использование определенной пользователем рабочей нагрузки подразумевает сохранение запросов в таблице базы данных. Затем эти данные будут прочитаны 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.
ЗАКЛЮЧЕНИЕ