I created a materialized view with the following information.
CREATE MATERIALIZED VIEW EMPLOYEE_INFO
AS
SELECT * FROM EMPLOYEE_TABLE WHERE LOCATION = 'Brazil'
I did not add any refresh interval to this MV initially. Now, I need to refresh this MV everyday at 0000HRS.
Will the following command help me to alter it for everyday at 0000HRS?
ALTER MATERIALIZED VIEW EMPLOYEE_INFO
REFRESH COMPLETE
START WITH SYSDATE
In case, I need to refresh it for every 6 hours, how do I perform it? Is it possible?
For periodic refresh you must use NEXT clause. To refresh everyday at 00:00:
ALTER MATERIALIZED VIEW EMPLOYEE_INFO
REFRESH COMPLETE
NEXT TRUNC(SYSDATE) + 1
To refresh every 6 hours:
ALTER MATERIALIZED VIEW EMPLOYEE_INFO
REFRESH COMPLETE
NEXT SYSDATE + 6/24
From documentation (ALTER MATERIALIZED VIEW):
START WITH Clause
Specify START WITH date to indicate a date for the first automatic refresh time.
NEXT Clause
Specify NEXT to indicate a date expression for calculating the interval between automatic refreshes.
Both the START WITH and NEXT values must evaluate to a time in the future. If you omit the START WITH value, then Oracle Database determines the first automatic refresh time by evaluating the NEXT expression with respect to the creation time of the materialized view. If you specify a START WITH value but omit the NEXT value, then Oracle Database refreshes the materialized view only once. If you omit both the START WITH and NEXT values, or if you omit the alter_mv_refresh entirely, then Oracle Database does not automatically refresh the materialized view.
At the time of the next automatic refresh, Oracle Database refreshes the materialized view, evaluates the NEXT expression to determine the next automatic refresh time, and continues to refresh automatically.
Related
I have a requirement in which I need to build a materialized view on a transaction table, though it has about 671348 records, it takes more than 15 mins for executing the underlying materialized query.
The base table is refreshed every Tuesday
Please let me know what type of refresh I can use for materialized view(full or fast)
Also please let me know the syntax for refreshing the materialized view every tuesday.
Say I have a below query which is constructing materialized view(MV)
select * from employee, department where employee.id = department.id and name like '%Andy%'
I have two related questions on How incremental update on MV works internally
1) Say I insert or update any entry either in employee or department table, can I configure increment refresh on MV to be asynchronous of insert/update transaction
or it is mandatory to be synchronous process ?
2)While insert or update , Does oracle evaluate(through transactionl logs) each updated/inserted row and apply the MV query criteria , see if satisfies it . If yes, update or insert the row in MV ?
1) Say I insert or update any entry either in employee or department table, can I configure increment refresh on MV to be asynchronous of insert/update transaction or it is mandatory to be synchronous process ?
If you want to have data available on a materialized view as soon as changes are committed on the base table then you can use ON COMMIT refresh method.
Or if you want to refresh by incrementally applying changes to the materialized view then you can use FAST refresh method. You can do this asynchronously.
2)While insert or update , Does oracle evaluate(through transactionl logas) each updated/inserted row and apply the MV query criteria , see if satisfies it . If yes, update or insert the row in MV ?
It depends upon what kind of refresh method you are using. If you are using FAST or ON COMMIT refresh method then yes, it only applies the changes to the MV which satisfy the criteria defined in the query used to create the MV.
For FAST REFRESH you have to create MATERIALIZED VIEW LOG on base tables you select for the MV. In these materialized view logs Oracle stores updated/inserted/deleted row information. i.e. Oracle does not use the REDO logs as you presumed.
Once all MViews based on your table are refreshed (either by ON COMMIT or manual REFRESH) content of according materialized view logs are truncated.
Is the computational cost of updating a stored procedure materialized view, in Oracle, based on the query execution or the result set? More specifically, does Oracle store the results of the query in such a way that contributes significantly to the time required to refresh the view?
Of course, queries which take very long to execute as well as incredibly large or small result sets make this impossible to answer ubiquitously.
The question is more about how the view actually stores the result set (in memory, on disk) so I can think about how frequently to rebuild materialized views.
Materialized view is basically a table combined with an algorithm to update it.
01:37:23 HR#sandbox> create materialized view mv_dual as select dummy from dual;
Materialized view created.
Elapsed: 00:00:00.52
01:37:56 HR#sandbox> select object_name, object_type from user_objects where object_name = 'MV_DUAL';
OBJECT_NAME OBJECT_TYPE
--------------- -------------------
MV_DUAL TABLE
MV_DUAL MATERIALIZED VIEW
Elapsed: 00:00:00.01
You can also create materialized views on prebuilt tables.
If we talk about refresh - there are two options: fast refresh and complete refresh.
Complete refresh just re-executes MV query, while fast refresh performs incremental updates.
http://docs.oracle.com/cd/E16338_01/server.112/e10706/repmview.htm#i29858
there are two types of mviews
Complete refresh mview - the entier mview will be rebuild every refresh. similar to delete and insert (notice: if you specify atomic = F or have version < 9 it will be truncate / insert append).
Fast refresh mview - oracle will create a table to store incremental changes. when refreshing, the changes stored in the side table will be applied to the mview.
fast refresh is faster on refresh but slows down dml operations on the base table.
when you consider your refresh strategy you should consider how much changes are applied to the base table and how often you need to refresh the mview.
ALTER TABLE RECORDINGS ADD PRIMARY KEY (ID);
CREATE MATERIALIZED VIEW LOG ON RECORDINGS TABLESPACE USERS NOLOGGING;
DROP MATERIALIZED VIEW REC_SEARCH_TEST;
CREATE MATERIALIZED VIEW REC_SEARCH_TEST
REFRESH COMPLETE ON COMMIT
AS (
SELECT DISTINCT ID, TITLE FROM RECORDINGS
);
ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
Cannot understand what is wrong here, I know that if I take out the DISTINCT clause it works, but why can I not use 'DISTINCT' if I specify 'REFRESH COMPLETE ON COMMIT' which is required.
If I use DISTINCT and REFRESH on demand there is no problem, but these are not the requirements.
Seems like with the addition of the DISTINCT, you've made your view's underlying SQL ineligible for fast refresh, and therefore not able to be used with ON COMMIT (even tho you specify refresh complete instead of refresh fast). From Oracle docs:
The two refresh execution modes are ON COMMIT and ON DEMAND. Depending
on the materialized view you create, some of the options may not be
available. Table 8-4 describes the refresh modes.
Table 8-4 Refresh Modes
ON COMMIT
Refresh occurs automatically when a transaction that modified one of
the materialized view's detail tables commits. This can be specified
as long as the materialized view is fast refreshable (in other words,
not complex). The ON COMMIT privilege is necessary to use this mode.
ON DEMAND
Refresh occurs when a user manually executes one of the available
refresh procedures contained in the DBMS_MVIEW package (REFRESH,
REFRESH_ALL_MVIEWS, REFRESH_DEPENDENT).
The same document link has a list of restrictions for fast refresh as well.
"Perhaps the example isn't the best, because I want to expand the view
to a more complicated query that will require a distinct keyword,
right now I am just trying to get it working on a basic level. "
The DISTINCT is the cause of the ORA-12054.
SQL> CREATE MATERIALIZED VIEW REC_SEARCH_TEST
REFRESH COMPLETE ON COMMIT
AS (
SELECT DISTINCT empno, ename FROM emp
)
/
2 3 4 5 6
SELECT DISTINCT empno, ename FROM emp
*
ERROR at line 4:
ORA-12054: cannot set the ON COMMIT refresh attribute for the materialized view
Elapsed: 00:00:01.14
SQL> SQL>
SQL> CREATE MATERIALIZED VIEW REC_SEARCH_TEST
REFRESH COMPLETE ON COMMIT
AS (
SELECT empno, ename FROM emp
)
/
2 3 4 5 6
Materialized view created.
Elapsed: 00:00:02.33
SQL>
Why not start with a something that works? Remove the DISTINCT. Get your MView working. Then complicate it later when it becomes necessary.
Although, as you already know you cannot use a DISTINCT you will have to revise either your query's logic or your refresh strategy.
The important thing to note about the question is that it is not about fast refresh, but complete refresh. Thus, there is no logical reason that the usual restrictions for fast refresh on commit should apply, except the one that all referenced objects must be local.
The "refresh complete on commit is a relatively new feature, so the best answer to the "why" question is probably "Oracle has not yet implemented this fully, please check future versions of Oracle Database". Not very useful, but true...
I have created materialized view (MV) on a table which is updated once in a month..
Do we have any automatic way to refresh my MV...
I mean how refresh of MV is done is it manual or
Automatic how frequent we can do????
like can i use Trigger for it..??
I am using Oracle9i on PL/SQL developer
Thanks
You can refresh the view manually if you want
execute DBMS_SNAPSHOT.REFRESH( 'MAT_VIEW','OPTION');
Where the OPTION parameter could be
F, f Fast Refresh
C, c Complete Refresh
A Always perform complete refresh
? Use the default option
The automatic refresh rate are supplied when you create the materialized view
CREATE MATERIALIZED VIEW MAT_VIEW
REFRESH FAST START WITH SYSDATE
NEXT SYSDATE + TIME_INTERVAL --
WITH PRIMARY KEY
AS SELECT * FROM TABLE;
Remember to create a log for the table if FAST START are used.
I recomend you the following link about Materialized View. It has a lot of info about this topic: http://www.dba-oracle.com/art_9i_mv.htm