Существует вопрос, почему мы создаем материализованный вид. У меня есть таблица и обновить таблицу постепенно. У меня есть работа dbms, которая объединяет данные из другой таблицы в это. Таким образом, это эквивалентно материализованному представлению с быстрым обновлением. Есть ли разница? Какая реализация лучше в двух случаях?Разница между материализованным видом и таблицей, которая обновляется инкрементно
Материализованного вид можно обновлять по требованию или по частоте обновления. Он может состоять из объединения двух или более таблиц.
При создании материализованного представления у вас есть возможность указать, происходит ли обновление в режиме ВКЛ. Или ВКЛ. КОМИТЕТ. В случае ON COMMIT материализованное представление изменяется каждый раз, когда совершается транзакция, тем самым гарантируя, что материализованное представление всегда содержит последние данные. Кроме того, вы можете контролировать время, когда происходит обновление материализованных представлений, указав ON DEMAND. В случае ПО ТРЕБОВАНИЮ материализованные представления, то обновление может быть выполнено с помощью методов регенерации, предусмотренных либо DBMS_SYNC_REFRESH или DBMS_MVIEW пакетов:
Вот в документации по link
материализовался Также представления могут быть обновлены постепенно.
Ваш заказ Решение
займет много кода и не масштабируется.
Согласен об этом, но это можно сделать и с таблицей. Я могу запустить работу dbms по расписанию, а также вручную. Или в случае вручную я могу выполнить блок pl/sql в задании dbms, чтобы обновить таблицу. Таким образом, ручная работа аналогична по требованию в материализованном виде. В другом случае ON COMMIT я могу запланировать выполнение задания dbms при фиксации через dbms_scheduler. –
Причина в том, почему вы хотите написать собственное решение, если есть встроенная/проверенная функциональность, которая хорошо работает –
Хорошо, но мы не можем создать материализованное представление во всех случаях. Если я говорю о производительности, я не знаю, что будет лучше работать в этом случае. –
Материализованные виды, следующие certain conventions могут быть быстро обновляется, используя материализованный вид журнала. Это означает, что Oracle будет только обрабатывать фактические изменения, чтобы обновить материализованное представление, где операция слияния должна будет сравнивать все строки каждый раз. Поэтому материализованный вид позволит значительно быстрее и чаще обновлять, особенно с большими таблицами.
ОК Это одно отличие, но «определенные соглашения» или я могу сказать «ограничения» слишком много. Добавляя к вашей точке при обновлении через материализованный журнал представлений, обновление выполняется путем копирования блоков базы данных из журналов в блоки таблиц. В то время как merge - это DML, он создает пространство отмены, а затем после выполнения операций блокировки блокировки выполняются операции.В случае быстрого обновления, материализованное представление лучше, чем о полном обновлении? В полном обновлении. Это тот же случай для материализованного представления и таблицы усечения нагрузки? –
После многих поисков я получил что-то на материализованном представлении, которое мы не можем сделать на обычной таблице, и это запрос переписать. Ниже мой вывод.
SQL> GRANT GLOBAL QUERY REWRITE to mydbdba;
SQL> CREATE MATERIALIZED VIEW customers_mw ENABLE QUERY REWRITE
AS
SELECT COUNT(*) c,state_id FROM sg.customers GROUP BY state_id;
SQL> alter session set QUERY_REWRITE_ENABLED=TRUE;
Session altered.
SQL> SELECT COUNT(*) c,state_id FROM sg.customers GROUP BY state_id;
Execution Plan
Plan hash value: 799451518
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 52 | 364 | 3 (0)| 00:00:01 |
| 1 | MAT_VIEW REWRITE ACCESS FULL| CUSTOMERS_MW | 52 | 364 | 3 (0)| 00:00:01 |
SQL> alter session set QUERY_REWRITE_ENABLED=FALSE;
Session altered.
SQL> SELECT COUNT(*) c,state_id FROM sg.customers GROUP BY state_id;
Execution Plan
Plan hash value: 1577413243
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 52 | 156 | 327 (1)| 00:00:01 |
| 1 | HASH GROUP BY | | 52 | 156 | 327 (1)| 00:00:01 |
| 2 | TABLE ACCESS FULL| CUSTOMERS | 50000 | 146K| 326 (1)| 00:00:01 |
В приведенном выше примере вы можете увидеть, как материализованный вид используется вместо сканирования всей таблицы.
Что лучше? Используя встроенную функцию вашей системы баз данных (которая была тщательно протестирована и отлажена) или написания кода (который вы должны отлаживать), чтобы приблизиться к одной и той же функции? –
Лучше использовать встроенную функцию. –