Обзор важнейших фич Postgres 9.3: материализованные представления
PostgreSQL 9.3 выйдет с довольно-таки крутой фичей, называющейся материализованные представления. Фича была разработан Кевином Гриттнером и не так давно закоммичена:
commit 3bf3ab8c563699138be02f9dc305b7b77a724307
Дата: Воскресенье 4 Марта 18:23:31 2013 -0600
Автор: Кевин Гриттнер
Добавлены материализованные представления
У материализованного представления есть правило, так же как и у обычного представления, и куча, а также другие физические свойства, как у таблицы. Правило используется только для наполнения таблицы, ссылки в запросах указывают на материализованные данные.
Реализована минимальная функциональность, но и она может быть полезной во многих случаях. В настоящее время данные загружаются только “по требованию” инструкциями CREATE MATERIALIZED VIEW и REFRESH MATERIALIZED VIEW. Ожидается, что в будущих релизах будут добавлены инкрементальные обновления данных с различными настройками времени обновления, и будет дано более четкое определение самому понятию “свежие” данные. В какой-то момент даже запросы смогут использовать материализованные данные вместо данных самих таблиц, но это требует реализации описанного выше функционала в первую очередь.
Большая часть работы по составлению документации проделал Robert Haas. Ревью: Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja. Ревью по вопросам безопасности, включающее решение о том, как лучше реализовать sepgsql, ожидается от KaiGai Kohei.
Что такое материализованное представление? Если коротко, то это мутант таблицы и обычного представления. Представление это проекция данных с помощью заданного отношения, не имеющее хранилища. Таблица это… таблица!
Материализованное представление лежит где-то посредине – это проекция табличных данных, имеющее собственное хранилище. Оно использует запрос для получения своих данных, как представление, но данные хранятся как в обычной таблице. Материализованное представление может быть обновлено свежими данными с помощью повторного выполнения запроса, использованного на этапе его создания. Кроме того, оно может быть очищено (truncated). В последнем случае оно остается в состоянии, не допускающем сканирования. Также, так как материализованное представление имеет свое собственное полноценное хранилище, оно может использовать табличные пространства (tablespace) и свои собственные индексы. Обратите внимание, на то, что оно может быть беспротокольным (unlogged) (прим. перев.: то есть данные не пишутся в write-ahead log).
Вместе с данной фичей вводятся 4 новые SQL-команды:
CREATE, ALTER и DROP – в данном случае это привычные DDL-команды для манипулирования определением представления. Наиболее же интересна команда REFRESH (по поводу ее названия были долгие споры внутри комьюнити). Эта команда может быть использована для обновления материализованного представления свежими данными повторным запуском сканирующего запроса. Обратите внимание на то, что REFRESH также может быть использован для очистки данных (truncate), хотя и не настоящей, с помощью запуска с опцией WITH NO DATA.
Материализованные представления имеют множество преимуществ в различных ситуациях: быстрый доступ к данным, которые должны быть получены с удаленного сервера (чтение файла на сервере postgres через file_fdw, и т.д.), использование периодически обновляемых данных (система кеширования), проекция данных с ORDER BY из больших таблиц, периодическое выполнение дорогих “JOIN”-ов в фоне и т.д.
Я уже могу представить себе несколько замечательных комбинаций из процедур обновления данных и фоновых воркеров. Кто вообще сказал, что автоматическое обновление данных в материализованных представлениях невозможно?
А теперь, давайте посмотрим как это работает:
Размеры по каждому из отношений:
Материализованное представление использует хранилище (в данном случае, 18Мб) в объеме, необходимом для хранения данных, выбранных из родительской таблицы (размером 36Мб) во время выполнения запроса на создание представления.
Обновление полученного представления осуществляется очень легко.
Изменения в родительской таблицы отразились на материализованном представлении только после выполнения команды REFRESH. Обратите внимание, что на момент написания этой статьи, REFRESH использовал эксклюзивную блокировку (эх…).
Материализованное представление может быть переведено в несканируемое состояние с помощь опции WITH NO DATA команды REFRESH.
Появилась новая системная таблица matviews, которая содержи информацию о текущем состоянии материализованных представлений.
Над материализованным представлением нельзя осуществлять DML-запросы, поскольку данные представления могут не соответствовать текущему значению родительской таблицы. Обычные представления же, наоборот, выполняют соответствующий им запрос каждый раз, когда это необходимо, поэтому через них возможна модификация родительских таблиц (updatable views).
Сейчас несколько слов об улучшении и ухудшении производительности, которое вы можете получить с использованием материализованных представлений (с учетом того, что вы можете манипулировать и их индексами). Например, можно очень легко улучшить производительность запросов на выборку в материализованных представлениях, совершенно не беспокоясь о схеме данных в родительской таблице:
Обратите внимание на то, что индексы и ограничения (материализованные представления могут иметь constraints!) родительской таблицы не копируются в материализованные представления. Например, быстрый запрос сканирующий первичный ключ таблицы может закончиться смертельно долгим последовательным перебором, будучи запущенным на материализованном представлении.
Materialized views with PostgreSQL for beginners
I was asked to speak at the Postgresql User Group in Paris recently, and I chose to talk about materialized view (aka MatView), as they saved our production a few months ago.
I’ll present the materialized view usage with a problem we had at JobTeaser.
Our use case
My team and I are responsible for (out of many) providing an API to display stats on our back office reporting tools about job offer performance :
- number of views,
- number of unique views
- number of candidacies
These reports are used all day long by companies posting job offers.
Our workflow looks pretty much like this :
We had two problems:
1. we receive near real-time data, but the database is refreshed on a daily basis, this can be deceptive for our users.
2. we also faced performance issues on these API endpoints (>1sec response time). Although this response time is normal considering the table structure below, we do not want to make our users unhappy:
With this table (
30millions rows), retrieving the unique view count, means computing a distinct on student_id per job_offer_id. This table is also very generic, as it wants to fit all our needs about job offers’ performance: for example, shool_id and created_at are useless in the current use case, but useful for another one.
Our first (naive) idea was to build an agregation table, storing performance data for each job offer (target :<1 million rows):
We thought about refreshing this table by deleting rows that have been updated, and inserting new versions each 2 hours. Bad idea.
The aggregate table is used by the API, which means that there are read access locks on this table. If lock, then wait for insertion… and in this case, wait for a while. Plus this lock accumulation generates some performance issues.
Being stuck there, we dig in the whole internet and in the PG documentation, and found those materialized view
What’s a materialized view ?
Creation of Materialized View is an extension, available since Postgresql 9.3.
MatViews are widely available in other RDBMS such as Oracle, or SQL Server since longtime.
A MatView is in between a view and a table. Basically it’s built with a query refering to one or more tables, and the results are stored physically, making it acting like a cache.
This is the main difference with a simple view, which queries it’s source each time you call it. This means that you may wait for a while before getting your result.
A MatView can be used like a regular table, for example, you can add indexes or primary key on it, it supports VACUUM and ANALYZE commands (useful when you refresh it often), you can even create it without data, just with the definition query.
Bonus point: you can mess up your source table, your end-user won’t notice it before the refresh.
Our MatView-oriented solution:
Creating the materialized view
A materialized view creation looks like the creation of a view or a CREATE TABLE AS instruction:
Refreshing the materialized view
Now, if the source table views is updated and you want your materialized view to take those updates in account, you’ll must refresh it manually:
REFRESH MATERIALIZE VIEW job_offer_views_mv;
Well, that’s really sad ! Other RDBMS can do this automatically, and with simple view, the results would have been up to date (but if your query is heavy, you don’t want a simple view).
So it’s either you accept some decrepencies in your data or, you can use a trigger to refresh your MatView when the source is updated (not detailed here, maybe in a future post).
We were happy, this works well in staging, but …
The trick: refresh materialized view CONCURRENTLY
There’s not a lot of users in our staging environment, because of that, we missed two things:
- users generates read locks, so refreshing the MatView can take a while,
- refreshing the MatView locks any new read from users, making our API pretty slow
Actually, the ‘basic’ refresh is useful, and fast if the table is not used often (like several times a day). Otherwise, use refresh concurrently.
But beware! To use the refresh concurrently, you must define at least one unique index on your materialized view.
This is obvious regarding the way the refresh concurrently works. It refreshes the rows without locking concurrent select, so it needs to identify ‘free’ rows. It may take longer than the simple refresh, but it won’t bother your users.
That’s it ! Production is now safe, refresh every 2hours and these endpoints are pretty fast (< 100 ms).
Conclusion
MatViews are great. Use them if you :
- want to cache results of a heavy query
- don’t have ‘real’ real time (<200 ms) constraints
Don’t forget to use the concurrently option during your refresh.
And you dear reader, have you worked with MatView ? Any experience or best practice to share?
Какой командой можно обновить материализованное представление
REFRESH MATERIALIZED VIEW — replace the contents of a materialized view
Synopsis
Description
REFRESH MATERIALIZED VIEW completely replaces the contents of a materialized view. To execute this command you must be the owner of the materialized view. The old contents are discarded. If WITH DATA is specified (or defaults) the backing query is executed to provide the new data, and the materialized view is left in a scannable state. If WITH NO DATA is specified no new data is generated and the materialized view is left in an unscannable state.
CONCURRENTLY and WITH NO DATA may not be specified together.
Parameters
Refresh the materialized view without locking out concurrent selects on the materialized view. Without this option a refresh which affects a lot of rows will tend to use fewer resources and complete more quickly, but could block other connections which are trying to read from the materialized view. This option may be faster in cases where a small number of rows are affected.
This option is only allowed if there is at least one UNIQUE index on the materialized view which uses only column names and includes all rows; that is, it must not be an expression index or include a WHERE clause.
This option may not be used when the materialized view is not already populated.
Even with this option only one REFRESH at a time may run against any one materialized view.
The name (optionally schema-qualified) of the materialized view to refresh.
Notes
If there is an ORDER BY clause in the materialized view’s defining query, the original contents of the materialized view will be ordered that way; but REFRESH MATERIALIZED VIEW does not guarantee to preserve that ordering.
Examples
This command will replace the contents of the materialized view called order_summary using the query from the materialized view’s definition, and leave it in a scannable state:
This command will free storage associated with the materialized view annual_statistics_basis and leave it in an unscannable state:
Compatibility
REFRESH MATERIALIZED VIEW is a PostgreSQL extension.
See Also
| Prev | Up | Next |
| REASSIGN OWNED | Home | REINDEX |
Submit correction
If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.
Русские Блоги
Один, Материализованный вид Общее использование Материализованное представление представляет собой специальную физическую таблицу, и представление «Материализованное» относится к обычному представлению. Обычное представление — это виртуальная таблица, которая имеет большие ограничения для приложений. Любой запрос к представлению, Oracle Оба запроса фактически преобразуются для просмотра операторов SQL. Это не имеет существенного преимущества для общей производительности запросов.
1. Типы материализованных представлений ПО ТРЕБОВАНИЮ, ПО КОМИТЕТУ. Разница между ними заключается в методе обновления: как следует из названия, ON DEMAND обновляет только тогда, когда материализованное представление «нуждается» в обновлении (REFRESH), то есть обновляет материализованное представление, чтобы обеспечить согласованность данных с базовой таблицей, и ON COMMIT означает, что как только базовая таблица имеет COMMIT, то есть транзакция фиксируется, она будет немедленно обновлена, а материализованное представление будет обновлено немедленно, чтобы привести данные в соответствие с базовой таблицей.
Материализованные представления можно разделить на следующие три типа: материализованные представления, содержащие агрегаты, материализованные представления, которые содержат только соединения, и вложенные материализованные представления. Ограничения на быстрое обновление трех материализованных представлений сильно различаются, но не сильно отличаются для других аспектов. При создании материализованного представления вы можете указать множество опций, ниже приводится краткое описание нескольких основных опций:
Как создать ( Build Methods ） : Включая СТРОИТЬ НЕМЕДЛЕННО и СТРОИТЬ ОТЛОЖЕННЫЕ. BUILD IMMEDIATE генерирует данные при создании материализованного представления, тогда как BUILD DEFERRED не генерирует данные при его создании, а затем генерирует данные по мере необходимости. Значением по умолчанию является BUILD IMMEDIATE.
Переписывание запросов (Query Rewrite) : Включая ENABLE QUERY REWRITE и DISABLE QUERY REWRITE. Соответственно укажите, поддерживает ли созданное материализованное представление переписывание запросов. Переписывание запросов означает, что при запросе базовой таблицы материализованного представления Oracle автоматически определит, можно ли получить результат, запросив материализованное представление. Если это возможно, то оно избегает операций агрегирования или объединения и непосредственно из вычисленного материализованного представления. Прочитайте данные. По умолчанию установлено значение ОТКЛЮЧИТЬ ЗАПИСЬ.
При создании материализованного представления вы можете указать инструкцию ORDER BY, чтобы сохранить сгенерированные данные в определенном порядке. Однако это утверждение не будет записано в определении материализованного представления и не будет эффективно для будущих обновлений.
2. ПО ТРЕБОВАНИЮ материализованный вид Создание материализованных представлений само по себе очень сложно и требует оптимизированных настроек параметров, особенно для больших производственных систем баз данных. Но Oracle позволяет сделать это самым простым способом, аналогичным обычным представлениям, поэтому неизбежно будет задействовано значение по умолчанию. Другими словами, Oracle необходимо уделить особое внимание обработке значений по умолчанию важных параметров определения для материализованных представлений. Особенности материализованного вида:
(1) В каком-то смысле материализованное представление — это физическая таблица (а не просто физическая таблица), что подтверждается его способностью запрашивать user_tables;
(2) Материализованное представление также является сегментом, поэтому оно имеет свои собственные физические свойства хранения;
(3) Материализованное представление будет занимать дисковое пространство базы данных, что может быть подтверждено результатами запроса user_segment;
Создать заявление:
SQL> create materialized view mv_name as select * from table_name;
По умолчанию, если вы не укажете метод обновления и режим обновления, Oracle по умолчанию использует FORCE и DEMAND.
Как данные материализованного представления обновляются с помощью базовой таблицы?
Oracle предоставляет два метода: ручное обновление и автоматическое обновление, по умолчанию используется ручное обновление. Другими словами, мы вручную выполняем хранимую процедуру или пакет системного уровня, предоставляемые Oracle, чтобы обеспечить согласованность данных между материализованным представлением и базовой таблицей. Это самый основной метод обновления. Автоматическое обновление, по сути, Oracle создаст задание, с помощью этого задания вызовет ту же хранимую процедуру или пакет для достижения.
Характеристики материализованного представления ON DEMAND и его отличие от материализованного представления ON COMMIT, то есть первое не обновляет материализованное представление без обновления (вручную или автоматически), а второе не обновляет материализованное представление, пока происходит базовая таблица COMMIT.
Создайте регулярно обновляемое материализованное представление (укажите материализованное представление для обновления один раз в день):
SQL> create materialized view mv_name refresh force on demand start with sysdate next sysdate+1;
Материализованное представление, созданное выше, обновляется каждый день, но время обновления не указывается. Если вы хотите указать время обновления (например, обновление в 10:00 каждую ночь):
SQL> create materialized view mv_name refresh force on demand start with sysdate next to_date( concat( to_char( sysdate+1,’dd-mm-yyyy’),’ 22:00:00′),’dd-mm-yyyy hh24:mi:ss’);
3. На коммит материализованный вид Создание материализованного представления ON COMMIT мало чем отличается от материализованного представления ON DEMAND, созданного выше. Поскольку ON DEMAND является значением по умолчанию для материализованного представления ON COMMIT, вам необходимо добавить еще один параметр.
Следует отметить, что во время определения невозможно указать ON COMMIT, но он должен сопровождаться параметром. Создать ON COMMIT материализованное представление:
SQL> create materialized view mv_name refresh force on commit as select * from table_name;
Примечания. В реальном процессе создания базовая таблица должна иметь ограничение первичного ключа, в противном случае будет сообщено об ошибке (ORA-12014).
4. Обновление материализованного представления Обновить (Refresh): когда в базовой таблице есть операция DML, когда и как материализованное представление синхронизируется с базовой таблицей.
Есть два режима обновления: ON DEMAND с участием ON COMMIT 。
Существует четыре метода обновления: FAST, COMPLETE, FORCE и NEVER. Обновление FAST использует инкрементное обновление, обновляя только те изменения, которые были внесены с момента последнего обновления. Полное обновление полностью обновляет весь материализованный вид. Если вы выберете метод FORCE, Oracle определит, можно ли его быстро обновить при обновлении, если это возможно, затем используйте метод FAST, в противном случае используйте метод COMPLETE. НИКОГДА не означает, что материализованное представление не обновляется.
Для материализованного представления, которое было создано, вы можете изменить его метод обновления, например, изменить метод обновления материализованного представления mv_name, которое будет обновляться в 10 часов каждую ночь:
SQL> alter materialized view mv_name refresh force on demand start with sysdate next to_date(concat(to_char(sysdate+1,’dd-mm-yyyy’),’ 22:00:00′),’dd-mm-yyyy hh24:mi:ss’);
5. Материализованный вид журнала Если вам нужно быстро обновить, вам нужно создать материализованный журнал просмотра. Журнал материализованного представления может быть создан как тип ROWID или PRIMARY KEY в соответствии с потребностями быстрого обновления различных материализованных представлений. Вы также можете выбрать, следует ли включать ПОСЛЕДОВАТЕЛЬНОСТЬ, ВКЛЮЧАЯ НОВЫЕ ЗНАЧЕНИЯ и список указанных столбцов.
Вы можете указать оператор ON PREBUILD TABLE, чтобы построить материализованное представление на существующей таблице. В этом случае материализованное представление и таблица должны иметь одинаковые имена. При удалении материализованного представления таблица с тем же именем не будет удалена. Перезапись запроса этого материализованного представления требует, чтобы для параметра QUERY_REWRITE_INTEGERITY было установлено значение trust или stale_tolerated.
6. Материализованный вид раздела И материализованное представление на основе разделов может поддерживать отслеживание изменений разделов (PCT). С этим видом материализованного представления после того, как базовая таблица будет разделена и сохранена, она все еще может быть быстро обновлена. Для агрегированных материализованных представлений вы можете использовать CUBE или ROLLUP в списке GROUP BY для создания различных уровней агрегированных материализованных представлений.
Во-вторых, материализованное представление и миграция данных Материализованное представление Oracle предоставляет мощные функции, которые можно использовать для предварительного вычисления и сохранения результатов трудоемких операций, таких как объединение таблиц или агрегации. Таким образом, этих трудоемких операций можно избежать при выполнении запросов. Получите результаты быстро. Материализованные представления во многом похожи на индексы: цель использования материализованных представлений состоит в повышении производительности запросов, материализованные представления прозрачны для приложения, а добавление и удаление материализованных представлений не повлияет на точность и эффективность операторов SQL в приложении; материализованные представления требуют Занимайте место для хранения: при изменении базовой таблицы материализованное представление также должно обновляться.
Например, как построить на определенном табличном пространстве, они почти ничего не вводят в другие материализованные представления. Операция в основном основана на примере, который я сделал.Если базовая концепция материализованного представления ясна, то будет понятнее записать конкретное хранилище табличного пространства.
1. Простой тест в master site Создать таблицу и mview log
SQL> create table stu (id varchar2(10) primary key ,name varchar2(20));
Table created.
SQL> create materialized view log on stu;
Materialized view log created.
в mv site Создать на mview
SQL> create materialized view stu_mv refresh fast start with sysdate next sysdate+1/1440 with primary key as select * from [email protected]_vm9;
Materialized view created.
SQL> select job,log_user,last_date,last_sec,next_date,next_sec,interval,what from user_jobs;
JOB LOG_USER LAST_DATE LAST_SEC NEXT_DATE NEXT_SEC INTERVAL WHAT
— ——— ———— ——— ———— ———- ————— ——————————————
21 SEAGULL 2008-2-18 1 14:41:43 2008-2-18 1 14:42:43 sysdate+1/1440 dbms_refresh.refresh(‘"SEAGULL"."STU_MV"’);
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
—————————— ——- ———-
STU_MV TABLE
в master site Правильно master table Обновить:
SQL> INSERT INTO STU(ID,NAME) VALUES(’56’,’555555555555′);
1 row created.
SQL> commit;
Подождите 1 В минутах mv site Проверка
SQL> select * from stu_mv;
ID NAME
———- ———————
56 555555555555
2. Кросс-версия миграции данных Используйте prebuilt mv для кросс-платформенной, кросс-версии миграции данных. Принцип реализации этого метода заключается в том, что для переноса объектов таблицы необходим первичный ключ для обновления mv. Для таблиц, удовлетворяющих этому требованию, создайте журнал mv в исходной таблице, а затем создайте таблицу с такой же структурой в целевой базе данных. Затем используйте метод prebuilt для создания mv на целевой таблице, сначала используйте полное обновление, а затем используйте инкрементное обновление. Если вы действительно хотите переключиться, вам нужно только обновить инкрементный журнал, удалить mv и сохранить целевую таблицу. Примеры основных идей:
Создать таблицу и mview log
SQL> create table big_t1 as select * from dba_objects;
Table created.
SQL> select count(1) from big_t1;
COUNT(1)
———-
6170
SQL> create materialized view log on big_t1;
Materialized view log created.
Создайте ту же таблицу в целевой базе данных и создайте в таблице prebuilt mv:
SQL> create table big_t1 as select * from [email protected]_vm9 where 1=2;
Table created.
SQL> select count(1) from big_t1;
COUNT(1)
———-
0
SQL> create materialized view big_t1 on prebuilt table refresh fast as select * from [email protected]_vm9;
Materialized view created.
Делать полное обновление и постепенное обновление
SQL> exec dbms_mview.refresh(‘BIG_T1′,’Complete’);
PL/SQL procedure successfully completed.
SQL> select count(1) from big_t1;
COUNT(1)
———-
6170
В это время в процессе полного обновления таблица исходной библиотеки снова изменилась
SQL> insert into big_t1(object_id,owner) values(99991,’test’);
1 row created.
SQL> commit;
Commit complete.
Сделать инкрементное обновление снова
SQL> select count(1) from big_t1;
COUNT(1)
———-
6170
SQL> exec dbms_mview.refresh(‘BIG_T1’);
PL/SQL procedure successfully completed.
SQL> select count(1) from big_t1;
COUNT(1)
———-
6171
Выключение , Сделайте последнее обновление, затем удалите исходную библиотеку mview log И целевая библиотека mview ：
SQL> exec dbms_mview.refresh(‘BIG_T1’);
PL/SQL procedure successfully completed.
SQL> drop materialized view big_t1;
Materialized view dropped.
SQL> select count(1) from big_t1;
COUNT(1)
———-
6171
Удаленное здесь mview (big_t1) является предварительно встроенным mv, поэтому удаление mview не удаляет соответствующую таблицу. Если вы удалите mvnew (stu_mv), потому что это обычный mv, то удалите mview, соответствующей таблицы нет.
SQL> drop materialized view stu_mv;
Materialized view dropped.
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
—————————— ——- ———-
BIG_T1 TABLE
3. Создать место для хранения журнала SQL> CREATE MATERIALIZED VIEW LOG ON mv_lvy_levytaxbgtdiv
tablespace ZGMV_DATA — Журнал сохраняется в определенном табличном пространстве
WITH ROWID ;
SQL> CREATE MATERIALIZED VIEW LOG ON tb_lvy_levydetaildata
tablespace ZGMV_DATA — Журнал сохраняется в определенном табличном пространстве
WITH ROWID,sequence(LEVYDETAILDATAID);
SQL> CREATE MATERIALIZED VIEW LOG ON tb_lvy_levydata
tablespace ZGMV_DATA — Журнал сохраняется в определенном табличном пространстве
WITH rowid,sequence(LEVYDATAID);
4. Затем создайте материализованное представление SQL> create materialized view MV_LVY_LEVYDETAILDATA
TABLESPACE ZGMV_DATA — Сохранить табличное пространство
BUILD DEFERRED — Задержка обновления не обновляется сразу
refresh force — Если его можно быстро обновить, то быстро обновите, иначе полностью обновите
on demand — Обновить как указано
начать с to_date (’24 -11-2005 18:00:10 ‘,’ дд-мм-гггг чч24: ми: сс ‘) — время первого обновления
next TRUNC(SYSDATE+1)+18/24 — Интервал обновления
as
SELECT levydetaildataid, detaildatano, taxtermbegin, taxtermend,
.
ROUND(taxdeduct * taxpercent1, 2) — ROUND(taxdeduct * taxpercent2, 2) —
ROUND(taxdeduct * taxpercent3, 2) — ROUND(taxdeduct * taxpercent4, 2) —
ROUND(taxdeduct * taxpercent5, 2) taxdeduct, ROUND(taxfinal * taxpercent1, 2) —
ROUND(taxfinal * taxpercent2, 2) — ROUND(taxfinal * taxpercent3, 2) —
ROUND(taxfinal * taxpercent4, 2) — ROUND(taxfinal * taxpercent5, 2) taxfinal,
a.levydataid, a.budgetitemcode, taxtypecode,
.
FROM tb_lvy_levydetaildata a, tb_lvy_levydata c, MV_LVY_LEVYTAXBGTDIV b
WHERE a.levydataid = c.levydataid
AND a.budgetdistrscalecode = b.budgetdistrscalecode
AND a.budgetitemcode = b.budgetitemcode
AND c.incomeresidecode = b.rcvfisccode
AND C.TAXSTATUSCODE=’08’
AND C.NEGATIVEFLAG!=’9′
5. Удалите материализованный журнал просмотра Журнал материализованного представления часто становится очень большим, потому что материализованное представление не обновлялось в течение длительного времени, или пакет данных изменяется в базовой таблице, что будет влиять на производительность обновления материализованного представления. Поэтому в этом случае должен быть обработан журнал материализованного представления, чтобы уменьшить Верхняя отметка материализованной таблицы журнала.
Журнал материализованного представления будет записывать все операции добавления, удаления и изменения базовой таблицы, и после того, как материализованное представление выполнит операцию быстрого обновления, материализованное представление будет обновлено из журнала материализованного представления, и другим материализованным представлениям не нужно обновлять удаленные записи. Выкл. Если одно из материализованных представлений не было обновлено, журнал материализованных представлений будет становиться все больше и больше.
Существует также ситуация, такая как вставка большого количества данных в таблицу, удаление большого объема данных или равномерное обновление столбца в таблице до значения.Эта операция создаст большое количество записей в журнале материализованного представления.
Увеличение журнала материализованного представления неизбежно повлияет на частоту обновления материализованного представления. С одной стороны, материализованное представление должно сканировать журнал материализованного представления при обновлении. С другой стороны, после обновления введения материализованного представления запись в журнале материализованного представления также должна быть очищена. Журнал материализованного представления все равно должен сканироваться, поэтому размер журнала материализованного представления непосредственно Повлияет на скорость быстрого обновления материализованного представления. Что еще более важно, когда высокий уровень воды в материализованном журнале представлений поднимается до очень высокого положения, даже если в журнале материализованных представлений мало записей или нет записей, материализованному представлению все равно потребуется много времени для обновления.
SQL> DROP materialized view log on mv_lvy_levytaxbgtdiv;
SQL> DROP materialized view log on tb_lvy_levydetaildata;
SQL> DROP materialized view log on tb_lvy_levydata;
6. Удалить материализованный вид SQL> drop materialized view MV_LVY_LEVYDETAILDATA;
По сути, это то же самое, что и операция с таблицей, поскольку материализованное представление существует физически, оно может создавать индекс так же, как и обычная таблица.
три, ORACLE Материализованное представление резюме Материализованное представление — это объект базы данных, содержащий результат запроса, который является локальной копией удаленных данных или используется для создания сводной таблицы на основе суммирования таблицы данных. Материализованные представления хранят данные на основе удаленных таблиц, которые также можно называть моментальными снимками. Материализованные представления могут запрашивать таблицы, представления и другие материализованные представления. В основном используется в хранилищах данных и системах поддержки принятия решений.
Как правило, материализованные представления называются основными таблицами (во время репликации) или списками деталей (в хранилище данных). Для репликации материализованные представления позволяют вам сохранять копии удаленных данных локально, и эти копии доступны только для чтения. Если вы хотите изменить локальную копию, вы должны использовать расширенную функцию копирования. Если вы хотите извлечь данные из таблицы или представления, вы можете использовать извлечение из материализованного представления. Для хранилища данных созданными материализованными представлениями обычно являются сводные представления, сводные представления для одной таблицы и представления соединений.
Материализованное представление хранит его физическую структуру в своем собственном сегменте, который может быть проиндексирован и разделен. Запрос не обязательно должен точно соответствовать выражению SQL, используемому для создания материализованного представления. Оптимизатор может динамически переписать запрос, близкий к исходному определению, чтобы материализованное представление использовалось для замены фактической таблицы. Это переписывание запроса происходит автоматически и прозрачно для пользователя. ,
1. Несколько шагов настройки перед использованием материализованного представления (1) Определите эти утверждения для создания материализованных представлений.
(2) Решите, хотите ли вы синхронизировать данные представления и базовой таблицы.
Если не синхронизированы, вы можете выбрать следующие три метода обновления:
ЗАВЕРШЕНИЕ: Когда начнется обновление, сначала обрежьте материализованное представление, а затем повторно вставьте данные заполнения из базовой таблицы.
FAST: обновлять только те данные, которые были изменены с момента последнего обновления базовой таблицы. Используйте данные журнала представления или ROWID для завершения.
СИЛА: метод по умолчанию. Сначала используйте FAST или используйте COMPLETE, если не можете.
(3) Установите параметры init.ora:
JOB_QUEUE_PROCESSES должно быть больше 1.
Значение QUERY_REWRITE_ENABLED, если установлено значение TRUE, позволяет динамически переписывать запросы.
QUERY_REWRITE_INTEGRITY, чтобы определить степень согласованности данных, которая будет соблюдаться при доступе к материализованным представлениям.
OPTIMIZER_MODE должен быть установлен на некоторый путь CBO.
Используя материализованное представление, пользователи должны иметь только разрешения для базовой таблицы.
2. Создать материализованное представление SQL>create materialized view emp_by_district
Tablespace mview_data
Build immediate
Refresh fast
Enable query rewrite
As
Select d.id,count(e.last_name) from distributor dist,district d,employee e
Where e.id = dist.manager_id
And d.id dist.district_id
Group by d.id;
Ниже приведен общий синтаксис, используемый Oracle при создании материализованных представлений. Значение каждого параметра таково:
1. refresh [fast | complete | force] Способ обновить представление
fast: инкрементное обновление. Предполагая, что время предыдущего обновления равно t1, при использовании быстрого режима для обновления материализованного представления добавьте только t1 к представлению к данным, измененным в основной таблице за текущий период времени. Чтобы записать это изменение, создайте Для постепенного обновления материализованных представлений также требуется таблица журнала материализованных представлений. создать материализованный вид входа в систему (имя основной таблицы).
завершить: обновить все. Это эквивалентно повторному выполнению оператора запроса, который создал представление один раз.
force: это метод обновления данных по умолчанию. Если можно использовать быстрый режим, для обновления данных будет использоваться быстрый режим, в противном случае используется полный режим.
2. MV время обновления данных
по требованию: обновлять, когда пользователю необходимо обновить, здесь требуется, чтобы пользователь обновлял данные вручную (вы также можете использовать задание для регулярного обновления)
при фиксации: если данные представлены в основной таблице, немедленно обновите данные в MV;
start ……: начиная с указанного времени, обновляя время от времени (определяется следующим);
3. Существует три варианта немедленной сборки
(1) Немедленное построение: создайте материализованное представление и немедленно заполните данные представления данными, выполненными текущей командой.
(2) Построить отложенное: создавать только материализованные представления и не заполнять данные между первым обновлением.
(3) Нет предварительно созданной таблицы, вместо создания новой структуры для сохранения данных используйте уже существующую таблицу, которая уже содержит существующие данные в определении представления.
Если он создается путем быстрого обновления при фиксации или обновления при фиксации, он будет обновляться при отправке базовой таблицы. Включение или отключение материализованных представлений требует разрешения на переписывание запросов или глобальных запросов на перезапись.
3. Обновить материализованный вид Автообновление ：
(1) Используйте опцию фиксации.
(2) Используйте dbms_mview, чтобы запланировать время автоматического обновления.
Обновление вручную ：
SQL>execute dbms_mview.refresh(‘EMP_BY_DISTRICT’); Обновить указанный материализованный вид
SQL>execute dbms_mview.refresh_defresh_dependent(‘EMPLOYEE’); —— Обновить все материализованные представления, используя таблицу
SQL>execute dbms_mview.refresh_all_mviews; Ef Обновить все материализованные представления, которые не обновлялись с момента последнего обновления в этом режиме.
4. Отключить материализованное представление — Измените параметр query_rewrite_enabled параметра init.ora, чтобы он сработал, и перезапустите экземпляр.
— Используйте alter system set query_rewrite_enabled = flase; динамическое изменение.
— Используйте alter session set query_rewrite_enabled = flash; измените сеанс.
— Используйте подсказку norewrite.
5. Удалить материализованный вид SQL>drop materialized view emp_by_district;
Интеллектуальная рекомендация
Проект Scramboot и реализация Vue проекта Передние и задние концы и взаимодействия баз данных
Vue Project (вовлечение междоменных проблем) Перекрестный 1, первая установка Axios с Vue-Axios 2, настроить Axios в Main.js 3. Настройте междоменную информацию в index.js в папке конфигурации.
29.java- анонимный внутренний класс
Анонимный внутренний класс — это частичный внутренний класс без имени, который подходит только для одного класса. В разработке часто есть такой класс, только один раз, используйте его один раз, вы мож.
Летучий скрипт
Boot Чтобы открыть различные среды, IDE, каждый раз, когда вы щелкнули на значок настольных компьютеров, ощущается очень неприятно. Использование языка сценариев BAT под окном, напишите чрезвычайно пр.
Самоорганизующаяся нейронная сеть SOM
Самоорганизующаяся нейронная сеть SOM Создавайте красивые картинки .
CodeForces-136A представляет 【Практические вопросы по C ++】
A. Presents time limit per test2 seconds memory limit per test256 megabytes inputstandard input outputstandard output Little Petya very much likes gifts. Recently he has received a new laptop as a New.