Materialized view is a unique feature of oracle. Since oracle9i, it has been widely used. Unlike mysql, it does not support original materialized view. It needs to be implemented with flexviews. What is the use of materialized views? To answer this question, we must first understand the difference between a materialized view and a normal view:
A materialized view has a corresponding container table. The container table is a "rule" table with the same name as the materialized view, which is used to store the result set returned by the query. This is the fundamental difference between a materialized view and a normal view. It has a "physical presence" to store the result set, while a normal view does not have this physical presence, but is just a virtual table. Every time it is accessed, the query must perform a base table access. (regardless of cache).
There are two application scenarios for materialized views: 1. For query optimization; 2. For advanced replication. The following are some practical cases to illustrate.
1. Query optimization.
For a telecom value-added service, when the process starts, it needs to load some important service initialization data (such as the networkid, cc, ndc and other basic data of global operators). These service initialization data need to be queried from four tables. In order to improve the access performance of this part of the data and speed up the process startup, the data of these four tables can be combined into a materialized view, which is defined as follows:
CREATE MATERIALIZED VIEW IRDB_NETWORKLIST
REFRESH FORCE ON COMMIT
AS
SELECT
A.NETWORKID AS NETWORKID,
A.NETWORKNAME AS NAME,
C.CC AS CC,
C.NDC AS NDC,
B.MCC AS MCC,
B.MNC AS MNC,
A.NEWVISITINTERVAL AS NEWVISITINTERVAL,
A.OUTNEWVISITINTERVAL AS OUTNEWVISITINTERVAL,
D.MNP_ENABLED AS HASMNP,
A.BRANDNAME AS BRANDNAME,
A.LANGUAGECODE AS DEFAULTLANGUAGECODE,
C.TIMEZONE AS TIMEZONE,
A.NDD AS NDD,
A.ZONEID AS ZONEID
FROM
IRDB_NETWORK_MASTER A, IRDB_NETWORK_GSM_DETAIL B, IRDB_NETWORK_CODES C, IRDB_COUNTRY_MASTER D
WHERE
A.NETWORKID = B.NETWORKID AND A.NETWORKID = C.NETWORKID AND A.COUNTRYID = D.COUNTRYID AND A.STATUS = '1' AND C.STATUS = '1'
Subsequently, when we DML commit any one or more of the four business base tables, IRDB_NETWORK_MASTER, IRDB_NETWORK_GSM_DETAIL, IRDB_NETWORK_CODES, and IRDB_COUNTRY_MASTER, the materialized view IRDB_NETWORKLIST can be automatically updated . Of course, the synchronization between the base table and the materialized view also has a certain cost, but if the materialized view is not established, then every external call will query the base table, and the materialized view will disperse this pressure. The table connection is staggered from the external business interface access, which is beneficial to reduce the peak value of the database load, which is also one of the core ideas of database performance optimization.
2. Advanced Copy
In many business scenarios, we do not need to synchronize the entire database, but only need to synchronize some fields of some tables. At this time, materialized views can come in handy. The following is the structure diagram of the mobile CRBT service database of a municipality directly under the Central Government:
Here, one P650 minicomputer is used as a management node, responsible for data processing such as service billing and service bills, and the other five P650 minicomputers are used as call nodes and only provide user data query function. There is no need to use a full-database synchronization technology such as DG here, because the calling node only needs to synchronize part of the data related to the calling service. The management node establishes a materialized view. Here is an example of the t_userinfo user table:
CREATE MATERIALIZED VIEW
usdptemp.T_USERINFO_MV
REFRESH FAST
AS
selectPHONENUMBER,LOCALID,BRANDID,PAYKIND from usdp604.T_USERINFO@admin_node
Create a synonym at the calling node:
create or replace synonym T_USERINFO
for T_USERINFO_mv;
This way you can keep the exact same object name as the management node.
Then set up a refresh group to refresh the materialized view every 10 seconds:
--create a refresh group
BEGIN
DBMS_REFRESH.MAKE(
name => 'usdpsync',
list => 'T_USERINFO_mv',
next_date=> sysdate,
interval => 'sysdate + 10/86400'
);
END;
/
When initializing synchronization, first use a temporary user to export data from the management node, pay attention to the table followed by the global_name of the management node (consistent with the dblink name built on the calling node), and then impdp the data on the calling node, that is, the calling node The materialized view T_USERINFO_mv above is created based on the materialized view log of the base table on the management node, so that it can be updated with the base table of the management node.
In the process of using materialized views, there are still a few points to pay attention to, which are listed here:
1. The materialized view has two refresh modes: ON DEMAND and ON COMMIT. The former needs to be refreshed manually by calling dbms_mview, and the latter will be refreshed automatically when the base table is submitted. If you do not specify the refresh method when creating a materialized view, the default is ON DEMAND. At this time, you generally need to create a job, and call dbms_mview to refresh it according to a fixed cycle in the job.
2. The materialized view log has a variety of options when it is created: it can be specified as ROWID, PRIMARY KEY and OBJECT ID types, and can also specify SEQUENCE or explicitly specify the column name. The structure of the materialized view log generated by the above situations is different.
3. There are four refresh methods: fast, complete, force and never.
fast is an incremental refresh, which only refreshes the modifications made since the last refresh.
complete is a complete refresh of the entire materialized view.
force, oracle will determine whether fast refresh can be performed when refreshing, if fast, otherwise complete
never, the materialized view will not perform any refresh.
If you want to refresh quickly, you must build a materialized view log. The materialized view log naming rule is mlog$_+base table name.
View the materialized view log table of the current system:
select * from dba_mview_logs;
The force mode refresh does not need to create a materialized view log.
4. If the materialized view encounters synchronization problems, in an emergency, you can perform manual refresh:
SQL> exec dbms_mview.refresh('IRDB_NETWORKLIST');
PL/SQL procedure successfully completed
At this point, the IRDB_NETWORKLIST materialized view is refreshed according to the base table.
5. Materialized view log optimization:
For materialized view logs, we can build indexes to improve performance. At the same time, when troubleshooting performance problems such as slow synchronization, it is also necessary to check whether there is a high water level. The high water level of the materialized view log table will affect the refresh performance. The method of dealing with the high water level is omitted here.